The competition

[Randahl Fink Isaksen]

Dan,

I am certainly not oblivious to the fact that downloading and installing Java has felt burdensome to many users historically, but I think you need to acknowledge that

A. Java installation will become considerably faster with project Jigsaw. I am aware that this modularisation system has been postponed to Java 9 (2015), but nevertheless it shows where we are heading.

B. Ten years ago low bandwidth meant that downloading Java was slow and painful. With high bandwidth connections rolling out in many countries, that part of the problem is gradually disappearing. The last ten years, my own home bandwidth has increased by a factor of 60, meaning that downloading Java now takes only 7 seconds.

C. With the modern autoupdate features of most operating systems the installation is only done manually once per computer, after which point the autoupdate feature takes over. If the user reinstalls his computer once every two years, then Java is a less than a minute download every two years. I think many users consider that quite bearable.

D. Many users already have the latest installation of Java. In Denmark in Scandinavia where I live, the latest version of Java has a 100.0% penetration among all 5.6 million residents. Why? Because our nationwide common login system called NemID is based on it. In Denmark you cannot log in to your home banking system or the tax authorities' website without it. I am not saying that Denmark is a typical example in this regard, but do not forget that many users in other countries might have already installed Java for accessing their home banking system, for gaming, or for using all sorts of Java based application services. I believe this is a way better situation than what Flash had – Java is a requirement for many need-to-have applications, whereas flash often only was a requirement for accessing non-need-to-have content.

Finally, please also realise that while there are things that HTML5 does better than JavaFX, there are also things JavaFX does best. It will never be a winner-takes-all competition. If your next application is a product catalog consisting mainly of pages of content for the user to browse, who in their right mind would not choose HTML5 for this? On the other hand, if your next application is a home interior design application allowing users to visualise prefabricated kitchen cupboards in a virtual model of their own home, who would not choose JavaFX over HTML5?

Randahl.

 
On Dec 1, 2012, at 22:56 , Daniel Zwolenski <zonski at gmail.com> wrote:

> Hi Randahl,
> 
> Thanks for your comments I appreciate hearing an alternative point of view. 
> 
> One thing to keep in mind is that all of my comments are within the context of the web/consumer space (unfortunately this space doesn't have a good name so it's harder to define). 
> 
>> Richard has already asked you to provide documentation to back up your performance claims,
> 
> I responded to this. There is another thread on performance where someone (I think Michael) made the claim that jfx was slow (in some cases 2-3 times slower than awt) and my own experiences have shown problems. I'd suggest continuing that conversation on that thread if needed since the original poster of that question made a good attempt at phrasing these questions (and in my opinion leaving that thread unanswered was far worse for perception than leaving this one unanswered - surprised Richard let it unrebuked based on his stance on performance). 
> 
> I look forward to seeing Richard's documentation on benchmarks when he has a chance to release them. 
> 
> 
>> Your claim: Web is […] a deployment model that is seamless across more platforms.
>> – My input: You are right that deployment of web apps feels easy, but truly ensuring that the deployment actually works for all users on all platforms is all but a trivial task. There are literally hundreds of different web browser brands and versions out there, and the fact that you tested your latest web app on the two latest versions of a couple of browsers, gives you no guarantee that the web app works for all of the target audience. Have a look at this list, that documents the insanity of the web deployment challenge: http://www.useragentstring.com/pages/Browserlist/.
>> The truth is that some web developers close their eyes to the heterogeneous nature of the deployment environment, and simply define their target audience as "users who use the latest version of Internet Explorer on Windows". That may give you a warm and fuzzy feeling of simplicity and ease of deployment, but in reality it just means that your web app is most likely broken for everyone who falls outside your defined target audience. Knowing that all of your desktop users run Oracle's version of Java is a way better than knowing that all of your users run either Internet Explorer or Chrome or Safari or Firefox or yet another browser.
> 
> Agreed there are challenges with supporting lots of different browsers. 
> 
> My comment was that the user experience for "deployment" (ie getting a webapp running) is seamless (go to this URL). Once running, bug free cross-platform "consistency" is harder to achieve but the onus for this is on the developer (you have to test and run on every platform and tweak as needed). 
> 
> To me your argument here is that jfx having a single platform is the better "developer" experience and I totally agree. I hate debugging and fixing cross browser problems as much as the next developer but my users don't care that I hate doing it. My users would care however, if I told them that to run my app they have to first go to an oracle site and install java. 
> 
> A single platform for jfx is definitely a huge selling point for it and good that you added that to the analysis, but it is a selling point to the developers, not end users. You argue that the kick-on effect (ie developer is happy so they can do a better/quicker job) is a selling point to the user but your user would be weighing this somewhat unquantifiable benefit against the very comprehensible drawback of having to install java and the problems that come with that. 
> 
> As a side note the web space is traditionally horrid for x-browser but is improving rapidly and many frameworks like jquery and twitter bootstrap are making x-browser support much, much easier to achieve. I just released a webapp with moderate level of jscript that needed less than a week of testing/tweaking to work on IE7 - IE10, Firefox, chrome, safari, on WinXP - Win7 and Mac. I was pretty shocked myself that it worked based on my previous experiences (had braced myself for pain). IE10 still has some of the usual ms quirks but it is a far cry from the old days of ie 6 and ie 7. 
> 
> Also worth noting is that even with one platform, jfx has its own win vs mac vs Linux issues and you need to test and tweak on everyone (and build if you're using native installers). 
> 
> As a developer though the idea of one platform is one of the big selling points to me, as it sounds like it is for you. 
> 
> 
>> Your claim: [JavaFX is] based on established, type-safe java […] However there is little benefit to users [in this].
>> – My input: Everyone who has tried debugging a web application with more than 20.000 lines of JavaScript code knows that the lack of compile-time checks and type safety means JavaScript is more error prone. More errors means more time spent on debugging and less time spent on providing new features or improving the overall product quality. I hope you agree that users prefer robust, feature rich, high quality applications.
> 
> Again, this is a (big) selling point to developers. You can argue the kick on benefits of more features and less bugs but that's hard to quantify and stack up against quantifiable things like installation and even availability and cost of jfx developers in the market vs web. 
> 
> In terms of getting features out quicker web developers would argue that they can get more features out in less time than a java app and this would be the established perception out there - how do you prove you are right and they are wrong (and the proliferation of rapidly released webapps and lack of jfx apps would put the burden of proof on the jfx developer)?
> 
> It certainly is possible to build a robust, bug free webapp too. Atlassian tool suite, google analytics, Facebook, gmail, etc, etc - when we are telling our users that jfx will be less buggy than a webapp, how do we convince them of that when they are already using plenty of robust webapps in their daily lives?
> 
>> Your claim: Should [JavaFX] not gain market space before the [HTML5] era truly establishes itself then [JavaFX] is unlikely to ever make it […].
> 
> You snipped just before the important bit: "in it's current form". 
> 
> Also we're talking about the web space and competing with HTML. As I go on to say there are other areas where jfx can continue to be a contender but those areas were not the focus of my email. 
> 
> My opinion is that once the html5 era stabilizes it will be unlikely that jfx will offer much to that will allow it to break into the web space unless it innovates. Browser plugins will be dead so webstart and applets will be out, leaving no true web deployment option. 
> 
> I do not say that jfx will be dead only that it's current strategies for operating in the web will never work and new ones will be needed *if* jfx ever does want to try and compete in the web space (ie if oracle change their mind about not being interested in this space).
> 
> One way this could happen for example  is to not compete directly but to run ontop of jscript either at runtime or by precompiling the java/jfx app to jscript (ie like gwt does, in fact jfx-for-gwt would be a good avenue to look at though I suspect gwt is on the technology down curve with html5 rendering it somewhat obsolete). 
> 
> Alternatively the trend towards app stores may actually open more doors for jfx. In essence the OS vendors are potentially providing us with a deployment solution (yay!). In terms of the space I am looking at, keeping an eye on these app stores and there challenges regarding legals and technical restrictions is very high on the list. It's a good example of why I feel this sort of analysis is needed - what are the trends, opportunities, risks and what's our strategy as a result. 
> 
> Basically my analysis is that there is a small window of opportunity now to get jfx in its current form (but improving the current deployment options) to have some web market space but once html5 settles I believe it will be a case of reinvention rather than improvement to then get any web market space. 
> 
> 
>> – My input: On the one hand you are saying that HTML 5 has not truly established itself, even though it was first published 5 years ago, but still you claim HTML5 is the likely winner. Then on the other hand you move on to claiming that Java based JavaFX (meaning JavaFX 2.x) has to win the race in its first 2 years of existence in order to make it. I think it is worth noting that new software projects start every day, and many of them will choose the technology that best suits their needs. Remember when Windows was the all dominating operating system and people thought no one else had a chance? What happened? Remember when Internet Explorer was the all dominating browser and people thought no one else had a chance? What happened? Remember when Nokia was the all dominating cell phone manufacturer in Europe and Apple had not even made a phone yet? What happened? Remember when gasoline was the all dominating propellant for cars and people thought electric cars had no chance? What is happening right now?
>> 
>> All in all, I believe time will show that both HTML5 and JavaFX will have huge success. It all comes down to understanding the strengths of each technology, and knowing which technology best matches the exact requirements of the app you are building.
> 
> Yep. I'm talking about competiting in the web space. Oracle is backing html5 in this space, I'm trying to ascertain if and how javafx can compete instead.
> 
> Thanks for your comments,
> Dan 
>