The competition

[Daniel Zwolenski]

>
> While JavaFX does have 3D support (see the Ensemble demo under
> "Highlights"),
>

As I understand it, it is limited, psuedo-3D (also called 2.5D). Full 3D is
on the roadmap:
http://www.oracle.com/technetwork/java/javafx/overview/roadmap-1446331.html


> the demos you provided to prove that HTML is better, do not work in
> Safari, the dominant browser on Mac.
>

Have you enabled webGL?
https://discussions.apple.com/thread/3300585?start=0&tstart=0


> You state that the demos only work in Internet Explorer if you install a
> plugin, but that is still way better than a JavaFX solution, because JavaFX
> requires… a plugin.
>

I state that web 3D (like most "html5" features) is new and raw and there
is a window of opportunity for JFX to get in while MS and the others still
argue over stuff like this (IE will have a built-in 3D solution soon - the
exact form has not been revealed and there is obvious vendor posturing
going on). I state that this window is closing.

Forgive me, but I think we should end the debate here.
>

No worries. Thanks for the discussion.


>
> Randahl
>
>
>
>
> On Dec 2, 2012, at 0:38 , Daniel Zwolenski <zonski at gmail.com> wrote:
>
> > 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
>>
>>
>>
>
>