The competition

[Daniel Zwolenski]

> 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?

Right now, how would you build such an application in JFX (putting aside
the issue of deployment, JFX doesn't yet have 3d support)? I don't believe
it would be possible, certainly not easy?

Web on the other hand does have some visually impressive 3D support, though
it is in its early stages (but much further along than JFX).

For example check out:
   http://www.ambiera.com/copperlicht/demos.html
   http://joostn.github.com/OpenJsCad/

I don't know of any existing examples of doing that sort of stuff in JFX?

You will need a webGL enabled browser (chrome, firefox work, but IE will
need a plugin, much like the one needed to run JFX). If we are saying it's
ok to demand that our users go through the hassle of installing Java/JFX to
run our rich apps, then we have to allow that its ok for a web developer to
demand that a user goes through the (smaller) hassle of upgrading or even
switching their browser to use their rich apps. I don't think there's any
denying that the process of installing Google Chrome or Firefox is
significantly more user friendly and intuitive than the process of
installing Java.

As I said there is a very small window of opportunity for JFX to compete in
the web space while this "html5" stuff is still new and unsettled. That
window is rapidly closing however, as things like webGL become more
standard and robust.

Once html5 settles, my prediction that the answer to your question of who
would choose JavaFX over HTML5 for home-modelling software would be "very
few people". Plenty of developers would rather not write the JScript code
for it, I give you that, but the deciding factor will be the fact that if
they do they can then simply send out a URL and it will all just instantly
work on their client's machines. To managers, sales people and even system
admins choosing JScript over JFX for your home modelling software will be a
no-brainer, it will be only the developer having a bit of a grumble about
"not liking" JScript and as track record has shown it's not the developer
who will be making this decision (otherwise we'd all be using linux).

Just to be clear as a developer, I am sold on JFX as the better "developer"
platform and I want to use it (or I wouldn't be spending my weekends
working on all this). The problem I have is that my users don't care about
JFX or JScript or type safe vs not, they care about being able to do their
business with minimal fuss. The platform that delivers that is the one I
will have to use whether I like it or not.

And just to clearly re-state I am talking about JFX competing in the webapp
space (i.e. the space currently dominated by web).



On Sun, Dec 2, 2012 at 9:44 AM, Randahl Fink Isaksen <randahl at rockit.dk>wrote:

> 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
>
>
>