Why JavaFX?

I guess I don't understand why we have JavaFX. What problem is JavaFX trying to address?

Is this an attempt to resurrect the Java applet? Is it an admission of the failure of JSF to provide a rich GUI environment? Is it an attempted improvement on GWT? Is it here to blow up Ajax?

What is the compelling reason to use JavaFX when so many other technologies are out there that do the same thing?

-Cameron McKenzie

I suggest reviewing the posts and replies here since Tuesday, as well as visiting www.javafx.com for detailed answers. In a nutshell, it makes it VERY EASY for Java developers to build GUI apps that run on the desktop, in the browser, and in mobile devices. If you use Flex to build rich internet apps, but wish you could leverage your Java knowledge and code, JavaFX is the answer.

Cameron Wallace McKenzie wrote:Is it here to blow up Ajax?

Personally I don't think so, but there was at least on presenter at JavaOne who said something along the lines of "With JavaFX, developers are freed from having to use AJAX anymore." The feeling I got was they say JavaFX as delivering us from the evil of AJAX.

I don't remember who it was, but I got the feeling they really hated AJAX.

Burk

Yeah, that was only Larry Ellison who made those comments!

Eric Bruno wrote:Yeah, that was only Larry Ellison who made those comments!

Ah, my mistake. I thought it was one of the presenters.

I prefer to be a little more pragmatic and use tools where they make sense. I'm very interested in JavaFX but I won't scrap an existing project that's in production just to have the opportunity to rewrite it.

Burk

I agree with you 100%. I've worked with Ajax and believe that if it's the right tool for the job, use it. No problem there. Larry was coming at it from the perspective that JavaScript can be difficult to use, and some of the tools to develop/deploy/debug Ajax are lacking. JavaFX, since it leverages Java and its existing tools (such as NetBeans), can potentially make it easier to build similar apps. It's going to come to execution on that promise, as well as personal preference by those who use it. So in short, Larry's comments don't echo my own, but I understand the point he's making about JavaScript.

Wow. I didn't even think about using JavaScript directly for AJAX, I figured people would use a library like dojo or GWT.

As an example of the right tool for the job, I was talking with a friend about JavaFX vs GWT and he pointed out that customers that don't allow active content through their firewalls can still use an app written in GWT because it converts Java to JavaScript. I had to agree that in that scenario JavaFX wouldn't work.

It makes me wonder though, do you see much of this fear of active content in your experience?

>>I didn't even think about using JavaScript directly for AJAX

Well, in the portal environment, many standard ways of doing Ajax go out the window. In my Portlet Programming book, that's exactly what I had to do, go through the JavaScript basics. When you break it down to the basics, it's really not all that bad.

-Cameron McKenzie

Cameron Wallace McKenzie wrote:Well, in the portal environment, many standard ways of doing Ajax go out the window. In my Portlet Programming book, that's exactly what I had to do, go through the JavaScript basics. When you break it down to the basics, it's really not all that bad.

-Cameron McKenzie

Interesting, do portlets abstract the browser so you don't have to deal with cross browser compatibility?

Have we hijacked this thread enough?

The portal itself abstracts the whole thing out. A good portlet can be rendered as both a wireless/wml/hdml/wap application, and it can also be rendered as an html page, with the portal itself taking care of differences between browsers and versions. It's not quite as elegant as it sounds, as a good deal of the work rests on the developers hands.

As time goes by, it appears the mashups and Facebook have killed the portal platform.

-Cameron McKenzie

Sorry, didn't mean to hijack anything.

In my view JavaFX may do similar things to other technologies but it does them on the JVM, is supported in NetBeans, and allows us to leverage the existing Java libraries, which gives any Java developer a leg up when they need to write an RIA, or something as "simple" as a snazzy looking Desktop app.

Is that enough to justify its existence? I think so. But that's just me.
Burk

As I understand, JavaFX is for client-side, therefore we cannot compare it with JSF.
About JavaFX vs AJAX, don't forget that AJAX uses only JavaScript (and any server-side) which most browsers (most computers) support, the same isn't true for JavaFX, the support is limited.

About JavaFX vs Applet, I think the main different is Applet is supposed to run only in web browsers.

I don't understand your assertion that JavaFX support is limited.

Also, any JavaFX application can run as an Applet by just creating a JNLP file for it and embedding some JavaScript in the html page.
You can even drag the Applet off the browser on to the Desktop and it will continue to run even if you quit the Brower or go on to another page.
In addition, the same exact JavaFX code can participate in JavaWeb Start by merely setting up the JNLP correctly. No code changes or recompilation required.

There is also full support for interacting with the HTML page and the JavaFX applet, bi-directional.

jim

Jim Clarke wrote:
You can even drag the Applet off the browser on to the Desktop and it will continue to run even if you quit the Brower or go on to another page.
jim

Now that sounds kewl!

-Cameron McKenzie

Jim Clarke wrote:I don't understand your assertion that JavaFX support is limited.

I mean Flash player is more popular than JRE. JRE is too big, many people don't use Hi-Speed internet, it's pain to download JRE if not using Hi-Speed internet, but it's easy to download Flash player.

Jim Clarke wrote:
You can even drag the Applet off the browser on to the Desktop and it will continue to run even if you quit the Brower or go on to another page.

I'm not so sure if that is a good feature for end-users. I mean is that a thing that users want? Or it's a thing that developers want. I think time will prove it.

It's simply an option. If a user doesn't want the JavaFX applet on their desktop, they just won't drag it there. But if they do want it, they have the option to drag it off of the browser.

Eric Bruno wrote:It's simply an option. If a user doesn't want the JavaFX applet on their desktop, they just won't drag it there. But if they do want it, they have the option to drag it off of the browser.

All right. Not so long, time will prove it that if most users want that feature.
From developer point of view, I agree that it's cool to drag JavaFX component from a browser and drop it to desktop.
But from end-user point of view, I'm not sure what is the benefit of doing that.

The purpose of using applications is to make the job done, I don't see how DnD component from web browser to desktop will help to do the job better.

It certainly makes for an easy install. I hear more people complain about applications that are difficult to install than those that are as simple as drag and drop.

EOL

Your vision is limited. I can see how not having the app tethered to the browser would be a great boon. Too bad it's not available on anything but Windows.

Bear Bibeault wrote:Too bad it's not available on anything but Windows.

What's the 'it' that is limited to just windows?

-Cameron McKenzie

Cameron Wallace McKenzie wrote:What's the 'it' that is limited to just windows?

The "tear off" capability.

Darn, I guess I will have to stop tearing it off from my OpenSolaris laptop

The tear off feature is supported in JDK 1.6 update 10+.
The only platform that did not support this was Apple, however,
this past Monday, Apple released an new version of Java that is JDK 1.6 update 13 compatible,
so the tear off should work on Windows, Mac, Linux, and Solaris.

Jim Clarke wrote:so the tear off should work on Windows, Mac, Linux, and Solaris.

Great news!

(Did not an earlier post state Windows only? I may have been confused.)