Skip to main content

JavaFX eats HTML UIs for breakfast

Posted by randahl on September 18, 2011 at 10:15 AM PDT

These are the days to be a Java UI developer! For so many years I have dreamt of Java’s return to the client side, and now – at long last – the developers at Oracle are making this dream come true. 

Since the late nineties I have been developing a large number of both web based and swing based UIs, and it has always felt like a hard choice between two imperfect sets of technologies. But now – thanks to JavaFX – the days of technological compromise are over.

JavaScript – the slow productivity killer

While my web-based applications would work on more devices, require no installation, and integrate perfectly with the web, too much time was spent debugging the UI and fighting off all those perpetual cross-browser differences. Countless hours were spent trying to make the UI perform and deliver a user experience which ultimately only seemed like the real thing; and as the feature requests from end-users got more demanding in each consecutive project, so got the debugging. “Hey, can we have drag-and-drop? Hey, can we load these data from the desktop? Hey, could we have multi-tasking support?” – Indeed, end-users know the benefits of real native applications – they just do not realize that building a feature-rich UI experience with JavaScript is like building a space shuttle out of papier-mâché... and why should they?

Swing – trusty but overweight

Swing-based Java clients had many benefits over web clients, but at the same time introduced a whole range of new problems. Yes, ditching JavaScript in favor of using real Java all the way from the data access layer to the UI had a sublime impact on code reuse, debug-ability, test-ability, stability, experienced performance, and – most importantly – cost. Still, requiring end-users to download and install applications which were humongous considering the download speeds at the time and Swing’s ever delayed support for HTML beyond HTML 3.0, really put a limit to the kinds of projects which the technology could be applied to. And when customers saw all the luscious visual tricks Adobe pulled out of the hat with Flash, the non-animated, two-dimensional Swing UIs just looked like a steam engine in the space age.

JavaFX – even better than the real thing

JavaFX 1.0 came off to a slow start, mainly because of the surprising decision by Sun – the Java company – to require all Java developers to use a different language than Java when developing the UI, JavaFX Script. I think, Oracle’s most brave and insightful decision after the acquisition of Sun, was to take all the promising, cool features of JavaFX and unleash them in Java with JavaFX 2.0. Gone is JavaFX Script, and now everything Java is also JavaFX and vise-versa. Every single line of code you write can be reused – in all layers of your application. Just imagine the productivity increase your company will harvest from that!

And feature-wise the days of hard compromises are over. Now your compiled, type checked,  automatically unit tested, truly object oriented, highly reusable, component-oriented program is fully capable of rendering real-time, ultra-smooth, CSS styled, vector based 2D and 3D animated contents mixed with video, sound, and (to top it off) HTML contents. – That’s right... all the things you could do in a web client with HTML, you can now do with just a single component in JavaFX (the WebView). And there are hundreds of other rich components in the feature set – if you can conceive it, JavaFX can deliver it.

Getting Started

My company, ROCK IT, is developing an innovative security product for the private sector, and being an Oracle Java partner, I have been using JavaFX since the early access version was released in January. It really is a completely new UI paradigm and it takes a bit of getting used to,  but it is refreshingly innovative and powerful. It truly feels like taking Flash, Swing, and the traditional web technologies, and merging everything into a single, clean, well thought out technology, that matches the needs of the UI layer with perfection.

I am absolutely convinced the developers at Oracle have hit bull’s eye with this technology, and now – at long last – Java lets us creative developers deliver the powerful, rich user interface experience customers want.

If you still have not tried JavaFX, I warmly recommend you get started. The main starting point is http://javafx.com. The JavaFX community forum at http://forums.oracle.com is a great help, and also Jonathan Giles’ blog at http://fxexperience.com/ is a great source of inspiration.

 

Related Topics >>

Comments

Not only is there no ETA for the Mac and Linux versions but ...

Not only is there no ETA for the Mac and Linux versions but now I see that the delivery of the web component has been delayed, too. So, no, this is not ready for prime time. Sorry. Maybe in a few months.

I want JavaFX to succeed, too, but it's not there yet: rich text, web page rendering and platform neutrality are all must-haves, not nice-to-haves.

i agree.. swing is cross platform while javaFX isn't ...

xolotl wrote:
Not only is there no ETA for the Mac and Linux versions but now I see that the delivery of the web component has been delayed, too. So, no, this is not ready for prime time. Sorry. Maybe in a few months.

I want JavaFX to succeed, too, but it's not there yet: rich text, web page rendering and platform neutrality are all must-haves, not nice-to-haves.

i agree.. swing is cross platform while javaFX isn't (might be in the future but not garanteed yet)

swing was missing a webpanel.. so what's the point of switching to new architecture without web rendering?

This is good news to you then: The 2.2 version I am using ...

This is good news to you then: The 2.2 version I am using has both well working web rendering (classes WebView and WebEngine) as well as a separate HTML editor (class HTMLEditor), which you can use to present editable rich text to the end user. With regards to platform neutrality: There are currently releases available for Windows, Mac, and Linux, and although that is technically not *all* platforms, it is de facto 99% of what platforms users have. The best recent news I have come across is the fact that the next JavaFX version will be called JavaFX 8 and will be integrated with Java 8, meaning every user who has the recent Java version also has JavaFX – now that is a game changer!

 I really want to use JavaFX. I played with 1.3 a ...

I really want to use JavaFX. I played with 1.3 a little and 2.0 solves a lot of problems. However, I can't persuade anyone that it's a valid choice for apps running in a browser.

Despite the pain of HTML/JavaScript/CSS web applications, too many Product Managers insist on it as a platform because they know it will be deployed. Once you say, "How about a Java-based UI?" they just laugh. Flash may be acceptable; but HTML 5 seems to be the platform of the future. But where are the tools?

And what about tablets and phones? HTML 5 will work, but not JavaFX. If Oracle want JavaFX to be anything but a niche platform, they need to find a way to get it on devices, corporate PCs and conumser devices.

Good luck on that one!

Which really just makes JavaFX a replacement for Swing.

Now it seems to me that what browsers need is a general-purpose, language-independent, open Virtual Machine to replace JavaScript. The JVM wouldn't fit the bill (too much baggage), but Oracle now have resources and experience to be able to build Virtual Machines. Being at the centre of that and any tool chains could be highly profitable. What's more, a JavaFX-like system that ran on said VM could be very cool indeed.

Not that it'll happen; but I can dream!

 If by "too much baggage" you mean the size ...

 If by "too much baggage" you mean the size of the JRE plugin or the size of Java application UIs, I'd like to add a couple of observations:

1. Back in the late nineties when applets failed miserably, the average bandwidth here in northern Europe was 56 kbit. Today it is more than 1.000 kbit. In other words, the applet which took two minutes to download will now take 6 seconds - on average.

2. If Oracle manages to complete the modularization of Java (project Jigsaw), then the download time of the JRE itself will be dramatically reduced.

3. The major download size contributor in the games and other Applet content I made for lego.com back in the day was GIFs and JPGs. JavaFX is all vector graphics which take up virtually no space in my jars.

4. In Denmark where I am from, the JRE is already installed on nearly each and every household computer, because it is required when using the official Danish personal identification system, NemID, which is used when logging in to your home banking system, local city services, state tax services, etc.

One of the main benefits of Java is the fact that it's ...

One of the main benefits of Java is the fact that it's cross-platform. If JavaFX will only work on Windows in the initial release, what is the point of even using Java? If your app is going to be Windows-only, you may as well just use C# and WPF to make a fancy interface.

NEXT: JavaSE + JavaFX + JavaME MIDP 2.0 Compatybility layer ...

NEXT: JavaSE + JavaFX + JavaME MIDP 2.0 Compatybility layer FOR MOBILE PHONES!

So if you were starting a new project would you use JavaFX ...

So if you were starting a new project would you use JavaFX or Swing or both?

Like if you were writing NetBeans now, could you do it all in JavaFX? Or is it not approriate to do it in JavaFX because NetBeans doesn't have a lot of animations?

Although you can embed Swing components in your JavaFX code, ...

Although you can embed Swing components in your JavaFX code, I have not found a need to. Remember, JavaFX is a complete UI framework, and it has its own set of UI components (labels, text fields, etc.).

Now, NetBeans is a very untypical example, because it relies on a very complex application framework, and NetBeans has advanced requirements like dockable windows (which JavaFX does not support yet) and advanced rich text editing (also not supported yet).

On the other hand, if your application only needs typical UI components, like the ones already found in JavaFX, choosing between Swing and JavaFX is more a question of project resources, team skill level, and timeframe. Learning a new UI framework is not trivial.

I recommend you compare your feature requirements with what is already possible with JavaFX. Have a look at download.oracle.com/javafx where you will find all the documentation you need. Also, jfxtras.org has a large set of add-on controls.

And finally, if your product is expected to be around for years, think of what you will do, when new requirements show up a year or two from now. I recall what happened to AWT once Swing came out – everyone's focus moved to Swing, meaning all the new cool UI features of Java were Swing based, and AWT practically died. The same thing will happen to Swing, as soon as JavaFX gets a foothold. Sure, Swing will be around for many years to come, just like AWT is still a part of the JDK, but my anticipation is, the evolution of Swing will die out.

I experimented with 1.3 and from what I can tell I will like ...

I experimented with 1.3 and from what I can tell I will like 2.0 but I find it hard to believe it's still, at least for the time being, Windows only.

Actually, I am developing on a Mac. The early access ...

Actually, I am developing on a Mac.

The early access release works just fine on the Mac, so if you are a Mac user, just buckle up. After the beta came out, the Mac libraries have not been updated, so at the moment I am compiling and building on the Mac, and testing all my non-UI code here; in my particular case, I needed a bug fix which was solved in the recently release JavaFX beta, so I had to upgrade, and now I am debugging my UI code using a Windows laptop. This is actually a good thing, because the PC laptop closely matches the end-user system requirements by having a much more modest graphics card than my Mac Pro. There is no official release date for JavaFX 2.0 on Mac and Linux, but I am guessing those releases cannot be far away, since the early access release was already multiplatform. From the official JavaFX FAQ:

JavaFX 2.0 will be fully supported on 32-bit and 64-bit versions of Microsoft Windows XP, Windows Vista, and Windows 7. Early Access versions of JavaFX 2.x for Mac OS and Linux will be made available at a later date, but support for these platforms will not be included as part of the JavaFX 2.0 final release.

Your guess is as good as mine, but that sounds a lot like a multiplatform commitment to me – I think the JavaFX project just realized that Rome was not built in a day. To ensure high quality on all platforms takes time, so in my opinion, their strategy to hit the most popular platform first is quite sound.

 Can you explain the last part of this ...

Can you explain the last part of this statement:

JavaFX 2.0 will be fully supported on 32-bit and 64-bit versions of Microsoft Windows XP, Windows Vista, and Windows 7. Early Access versions of JavaFX 2.x for Mac OS and Linux will be made available at a later date, but support for these platforms will not be included as part of the JavaFX 2.0 final release.

Our Java shop develops on a mix of Mac and Linux machines. My understanding from the above statement is that JavaFX 2.0 final release will not be supported on Macs and Linux. So I don't see our programmers adopting this framework.

I don't agree that this a good decision at all. To ...

randahl wrote:
Actually, I am developing on a Mac. JavaFX 2.0 will be fully supported on 32-bit and 64-bit versions of Microsoft Windows XP, Windows Vista, and Windows 7. Early Access versions of JavaFX 2.x for Mac OS and Linux will be made available at a later date, but support for these platforms will not be included as part of the JavaFX 2.0 final release. Your guess is as good as mine, but that sounds a lot like a multiplatform commitment to me - I think the JavaFX project just realized that Rome was not built in a day. To ensure high quality on all platforms takes time, so in my opinion, their strategy to hit the most popular platform first is quite sound.

I don't agree that this a good decision at all. To postpone support for the other two IMPORTANT platforms is really an odd decision. The company I work for did not consider JavaFX 2.x for a future project because we simply don't know when and how good support for the other two platforms will be. This is really unfortunately because I really like JavaFX 2.x (and we have used JavaFX 1.x before).

 I agree with you xjh. By only delivering on a subset ...

I agree with you xjh. By only delivering on a subset of platforms Java is forgetting its "Write Once, Run Anywhere" promise. I was excited to see the JavaFX 2.0 announcement and was hoping to get a jump on doing some experimentation only to find out that it wasn't supported on OS X - my dvelopment platform of choice.

Excellent and well said!

Excellent and well said!