Silverlight and Flex in the Browser

The web browser is one of the great equalizers of the world. It's why Microsoft feared Netscape. If something runs in the browser, it doesn't matter where it came from. HTML, JavaScript, CSS are agnostic of the technology used to generate them. Don't get me wrong, browsers have their "quirks" and certain technologies make use of these quirks more readily than others, but these things aren't coupled. I can create an XHTML compliant application using ASP.NET and C# just as easily as I can create an app that uses lots of IE-only HTML and JavaScript using PHP.

There is an exception to this uniformity and that comes from browser extensions/plug-ins. These are capable of doing more proprietary communication with back-end servers. In a world where a new rich internet application framework is being introduced by some multi-billion dollar software company each month, one could easily imagine a tight coupling between such frameworks and the server technologies that feed them.

Of course the mother of these new frameworks is Flex, Adobe's application platform built on top of Flash. One of the common companions to Flex is Flex Data Services. This is actually an Enterprise Java application for accessing enterprise resources (like databases) and serving up data to Flex clients. One would guess that you could do the same thing on your own, and not just in Java. Your Flex client makes gets/posts to a URL and parses the response for a data model. You could even use SOAP for all this, if you were a masochist.

The design behind Silverlight seems very similar. The quick start tutorials from Microsoft show a Silverlight client connecting to a web service. Thus it should not be too hard to build a Silverlight application that talks to a Java or PHP server. On a side note, I had one interesting realization from reading through some of the Silverlight tutorials. They make a big deal distinguishing between client-side Silverlight code written in managed CLR (i.e. C# or VB.NET) as opposed to code written in a scripting language such as JavaScript or Iron Python. My understanding of the CLR was that everything was compiled into Intermediate Language (IL.) It sounds like if you use C# for your Silverlight project, then this is the case, but not if you use Python. This seems ... odd. One approach I thought they might try was to compile everything into JavaScript and let IE's runtime handle it ... but then I remembered that they are providing Silverlight for Firefox and Safari.

So my plan now is to take the Stocks application I wrote for the GWT tutorial (part is out next week, by the way) and create a Flex and Silverlight version of the same thing. I might cheat and re-use the servlet that GWT creates, or I might create a REST servlet. Too bad there are JSR 311 implementations yet.

Oh yeah, and then there's JavaFX. There is a fair amount of JavaFX documentation and examples. However, I'm not really sure if JFX will use a similar mechanism as Flex and Silverlight. It seems like it has to. The example I've seen usually create all the JFX on the server and then ship it to the client for rendering. That approach seems kind of primitive and something that would be difficult for an interactive application (like the the stock application.) Maybe by the time I'm done with the Flex and Silverlight versions of things, it will be more obvious how to do the same thing with JFX.

JavaFX Tools

As I mentioned earlier, I gave the JavaFX plugin for Eclipse a try. I was not too impressed. So I went through the monstorous download of NetBeans 6.0 and installed the JFX plugin for it. I'm still not too impressed!


Again this was basically just a text editor with the JFX runtime automatically launched. No palette or even much code completion. There was a little syntax highlighting, but that was about it.
Ok, so I know this stuff is really new, and I shouldn't be too critical of it. However, I read this exerpt from an interview with Sun CEO Jonathan Schwarts from OnJava:

In response to a question about JavaFX and JavaFX Tools. Whether Sun was planning on charging for FX tools.

Schwartz: “The world is divided into two camps, those who can and will pay for technology because its expense is less than the inconvenience of not having a support contract and those who cannot and will not pay for software for whatever reason, economically, culturally or the business just doesn’t need it. Our economic motives are to go after the former camp, our technology objectives are to go after the latter camp. Because almost by definition given what Dr. Diallo(sp?) just said, they out number the former camp 50,000 to 1. So volume defines market opportunities for everybody, you need only look at the internet to have that proven to you. It’s up to us to figure out how to monetize those volume opportunities in and among the communities that are capable and interested in doing so.”

Hmm. So now I'm thinking that designer like tools for JFX will be coming, but they won't be plugins to Eclipse and NetBeans. The big advantage I thought JFX might have over Flex and Silverlight was its free-ness and open source-ness. Not only would that make it attractive to adopt but would also open up third party enhancements. What's a Java technology without at least a dozen different frameworks built for it?

Now I'm thinking that this won't be the case. Sun will try to monetize JFX in the exact same way that Adobe and Microsoft monetize Flex and Silverlight. There's nothing wrong with this, it just means that JFX won't have one potential advantage over those technologies. That doesn't mean it won't have other advantages, as mentioned in previous posts. Its architecture may make it much more suitable for designer-developer workflows and rapid development.

I still think Sun is missing a huge opportunity. They could be the disruptive technology in all this, but it sounds like they won't go that route. So much for "Open Possibilities."

JavaFX Presentation at JavaOne

The transformation of F3 into JavaFX continues. I had signed up for the Form Follows Function (F3) session, but F3 was renamed JavaFX yesterday and now even the session title has been renamed: JavaFX Script. Chris Oliver is getting ready to make his presentation. The program on the projector says "JavaFX PDF Reader." So maybe he is going to use a JavaFX app to show the slides for the presentation. One can imagine a PowerPoint -> PDF -> JavaFX workflow here. If this is the case, it's a nice touch since it's a classic "eating your own dog food" tactic. Let's see…

The JFX (as Chris Oliver started calling it) presentation was very cool. Chris talked about his motivation for JFX. The first was that developers tended to be the limiting reagent in UI development, i.e. they took much more time than designers did. Web UIs were often used for prototyping for this very reason. Java/Swing UIs are often stereotyped as being very ugly, quite unlike Flash based apps. The last (and maybe most important) factor was that event listeners became a huge mess in UI code.

To tackle the first set of problems, JFX leverages Java 2D instead of Swing. The constructs used by designers have analogies in Java 2D, not in Swing. JFX brings a lot of the techniques of Swing to Java 2D. It uses a declarative syntax for this and allows for composition a la Swing, but Java 2D powers the building block components of JFX. This is very cool. The idea here is that anything you can do with Flash (and Silverlight!) can be done with Java 2D, and now can be easily done with JFX.

The next, and maybe more crucial aspect, was the elimination of event listeners in JFX. JFX uses a bidirectional update system that makes everything seamless to the developer. If the server updates a component it is re-rendered automagically. If a user invokes an action, the server side state is synchronized effortlessly. This was pretty impressive. As somebody who has designed a UI language (at Ludi Labs) I was especially impressed. We tackled the same problem there by auto-generating the event listeners essentially. I'm curious if this is what JFX is doing. Chris mentioned his inspiration came from functional programming, so maybe he came up with a more elegant approach.

Finally, among the demos was indeed the PDF reader I mentioned at the beginning of the post. Indeed all the slides were being displayed using the JFX PDF viewer. It was a very slick PDF viewer, with nice animations, zoom, page previews, etc. Chris got a great reaction when "revealed" that his PDF reader was a JFX application.

So what do I conclude from all this? Glad you asked. JFX has a design that really sets it apart from anything out there. There's a lot more going on here than just a Flex clone. That definitely is part of it, as Chris was quick to admit. Flex looks nice. Nice looking apps is only part of the equation. Improving UI development is a bigger puzzle to solve. JFX looks like it can deliver. It just needs the tooling for the designers to go along with it. More on that later.

One final observation. It really seemed like Chris Oliver was as surprised as anyone that F3 became JavaFX and thus the "big announcement" of JavaOne. Sun seems to be pushing JFX using the mobility angle (including all this nonsense about Blue-Ray devices.) There was no mention of that by Chris.