MIXation Sensation

This past week was Microsoft's MIX conference. I almost went to it, and I would have gone if it was not the same week as my oldest son's birthday. You gotta have priorities. Anyways, the reason I almost went was not because I have suddenly embraced ASP.NET development (even though I must admit my admiration for Scott Gu). No, my interest is all browser related and MIX was browser heavy this year.

On the browser front, the big news was the early preview of IE9. For web enthusiasts, it's fun to wax poetic about the mind blowing speed of V8 or the brilliance of TraceMonkey, but these technologies will always be secondary at best. If you are a web developer the most important browsers are the ones from Microsoft, because they dominate the market. They form the baseline that you develop against. If you want to do something that these browser do not support, you have got to get creative or be willing to live with your work simply being a toy. Simply put, IE9 news is more important than all of the Firefox, Safari, Chrome, and Opera news combined.

Luckily, Microsoft did not disappoint with IE9. It is obviously a far from finished product, and Microsoft was a little too dodgy on sharing its roadmap for my taste, but I can empathize with their position. Still they showed a browser with significant speed improvements and with support for a lot of standards based, visual eye candy. I'm talking about a lot of CSS3 features and most surprisingly, an amazing SVG implementation. They whipped out some classic Microsoft tricks, i.e. using their intimate relationship with their operating system to tap into GPU acceleration. You might think it's not a fair trick for them to do, but who cares? The boys at Mozilla, Apple, and Google have to accept this challenge, even if it will be super painful to pull of across platforms -- and Linux will surely suffer here once again.

I was a little disappointed in some of the other JavaScript features. In particular, I was really hoping that Web Workers would be included with IE9, and I was cautiously optimistic that geolocation would also be included. Neither is included in the IE9 preview that Microsoft made available to developers.

Of course that definitely does not mean that these features are out of IE9. I think there is a lot more to come. Microsoft has done some amazing work to give IE9 a lot of graphics features, but they have left out Canvas. Further intense graphics programming would benefit from the multi-threaded programming model supplied by Web Workers. So it would make a lot of sense for both of these to be added. I'm even optimistic that Microsoft will implement these standards directly, and not offer some proprietary alternative.

All of this makes you wonder about IE9 as a compelling graphics/gaming platform. I think that some serious tooling will be needed to make this viable. That's an area that Microsoft excels at. However, would this not put Microsoft in conflict with their own efforts around Silverlight? It's like the HTML 5 vs. Flash war could be played out in miniature within Microsoft's walls, only it would be IE9 vs. Silveright. Speaking of Silverlight...

The other big news, from my perspective at least, that came out of MIX was a lot more information about the Windows Phone platform. As a mobile developer, I have very mixed feelings about Windows Phone. On one hand, I really like the idea of using Silverlight as the application platform. This is a mature application platform, with fantastic tooling. You get to use a beautiful programming language -- C# (oh an maybe other .NET langs, like F#?) that has a decent runtime that includes garbage collection. However, Microsoft looks like they are copying Apple's approach. A lot of the restrictions being placed on non-Microsoft applications are very similar to the restrictions placed on iPhone applications.

Back to the browsers... Microsoft shipped a preview of tools for building Windows Phone applications. Again, major props to Microsoft for getting this software ready out at MIX, even if it is a little rough in places. I don't like companies using end users as a substitute for QA, but this is different. Getting tools into the hands of developers is critical. In this case, the tools include a Windows Phone emulator, which includes *drumroll please* the Windows Phone browser! As a mobile developer, this is the most important thing that can be included. I'll have to support your browser before I have to support your application platform.

However, the Windows Phone browser is not very promising. It seems to be based on IE7. It does not seem to support many HTML 5 features at all. No geolocation. No local storage. No application cache. No web workers.

Maybe some of these things will be added by this fall, but I'm not as optimistic about this. Even the documentation that is included emphasizes building web applications that are designed to work on legacy browsers. They seem to be saying, don't go looking for coolness in the browser!

JavaFX Performance

Recently I did a comparison of JavaFX performance vs. Scala. I did this mostly for kicks, and because some people thought that Mr. JavaFX was picking on other, non-Java languages that run on the VM. James Iry duly pointed out that JavaFX should be benchmarked against the likes of Ruby, Groovy, or Scala. It is meant to be a client-side technology, so it should go up against client-side technologies. So I re-did the little performance comparison to match JavaFX against JavaScript, ActionScript (Flash), and C# (Silverlight).

A comparison like this really becomes a comparison of Virtual Machines. For JavaScript there are a lot of choices. I decided to go with some that are supposed to be fast: Google Chrome, Firefox 3.1 (beta 2), and Safari 4 (developer preview.) Because I wanted Chrome involved, I had to go Windows. So I ran everything under Windows XP, running under Parallels on my MacBook. Here is the pretty graph:

I was just a little surprised by these results. JavaFX is indeed the fastest, but just barely. I was somewhat shocked to see Chrome's V8 JS engine right behind. In fact the difference is negligible for small iterations (shown above.) At larger iterations, JavaFX maintained 20-40% margin. As you can see from the graph, Flash and Silverlight were kneck-and-kneck as well, but was always about 7-10x slower than Chrome/JavaFX. Safari and Firefox were very underwhelming.

Of course this was just a micro-benchmark. The code just does a series of recursive calls. So what were are really measuring is the ability of the VMs to unwind these recursive calls. It is not suprising that HotSpot handles this easily. Actually, the same code in straight Java is much faster than the JavaFX version. It is surprising to see how well V8 handles this.

Now does the ability to unwind recursion translate into performance that a web application user would notice? Maybe. It certainly points to JavaFX's or V8's ability to make optimizations to application code. It is probably a more meaningful test than some raw number crunching.

AjaxWorld 2008

AjaxWorld was this week, and it was interesting. I think the down economy is having an affect on everyone, but there were still a lot of interesting things to learn about. On Monday, I did a talk on a favorite topic of mine, networked applications. The talk was a lot of fun, hopefully the audience would agree with that assessment. Overall though, I would say there were a couple of major themes at AjaxWorld this year.

1.) Comet. There were a lot of talks about some form of data push from the server to the browser. Kevin Nilson did a nice job of differentiating Ajax (infinite loop of XHR polls) vs. Comet (long poll.) The folks at ICEFaces have built some nice abstractions on top of Comet. There was also a lot of interest around WebSockets, especially the work by the folks at Kaazing. A duplexed socket connection to the server sounds great on paper. I think there will be some very interesting technologies that grow around that.

2.) Don't make me learn JavaScript! There seemed to be a lot of folks advocating the "only know one language" approach to the web. In most cases that language was NOT JavaScript (even though the Jaxer guys say it can be.) Vendors liked Oracle and ICEFaces preached abstractions that shielded the developer from JavaScript. Of course the GWT folks say do everything in Java. Microsoft says use Silverlight so you can do everything in C#. Of course one of the best sessions was by Doug Crockford who told everyone to man up and learn JavaScript. I tend to agree with Crockford, even though I prefer ActionScript...

JavaScript Faster than Flash

This is the last benchmark for awhile. Well, at least for today. I converted the JS benchmarks to ActionScript and tested them. The result were surprising, as JavaScript in Safari 4 and Firefox 3.x edged out Flash:


A few notes. I could not convert all of the tests, as two of them (the DOM and Ajax tests) were predicated on browser specific code. I could have done 'equivalent' functionality in ActionScript, but it did not appropriate for comparison. Otherwise the code was translated as is ... for the most part. I did add static type information where possible. There were also a few APIs (on Date and Array) that had be tweaked slightly. I tested similar changes to the JavaScript. The only test where there was any effect was the Date test. The JavaScript used Date.parse, which does not exist in ActionScript. The Date constructor does the same thing. If I switched to using the Date constructor in JavaScript, it was just slightly slower.

It certainly seems that much of the performance advantage enjoyed by Flash upon arrival of Flash Player 9 has been erased. Flash had a strong advantage still in more mathematical calculations (dates, integer and floating point arithmetic) as well as string manipulation. It did very poorly with arrays and regular expressions. I would guess that as the JITs for JavaScript get better, the string advantages will disappear. Flash will probably maintain an advantage in more mathematical computations, especially given its vector graphics features. Hopefully advances in JavaScript will spurn Flash VM progress.

Notes
1.) Tested on both Flash 9 and 10 RC2 on both OSX and Windows. Negligible performance differences in any of the permutations.
2.) Also tested with Silverlight, but only on Windows. It was slower than everything except IE7. However, that was because it was terribly slow at regular expressions and error handling. It clearly had the best JIT as it was able to reduce some of the tests to 0 after a couple of executions.

Silverlight Stocks

Ever since details of Silverlight 2.0 came out, I planned on re-doing my stocks app using it. This is an app that I first wrote for a GWT tutorial I did for IBM, and then re-wrote when I learned Flex last year. I wanted to write it in Silverlight last year, but Silverlight was not ready then. Now it is. Here's a picture of it.


This look-and-feel is all defaults. It looks like a web page! It's usually easy to spot Flex apps, but that is not as true with Silverlight. Everything works the same as with the Flex or GWT versions, except the color-coding for stocks that are up or down. I figured out how to define styles with Silverlight (more on that) but could programmatically set the style. Let's take a look at the code. First the UI code.

<UserControl x:Class="SilverStocks.Page"
    xmlns="http://schemas.microsoft.com/client/2007" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
    Width="400" Height="300">
    <StackPanel Orientation="Vertical">
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Enter Symbol "/>
            <TextBox x:Name="symbol" Width="100"  KeyDown="symbol_KeyDown"/>
            <Button Click="Button_Click" Content="Get Info" />
        </StackPanel>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Company Name: "/>
            <TextBlock x:Name="company"/>
        </StackPanel>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Price: "/>
            <TextBlock x:Name="price" Text="$"/>     
        </StackPanel>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Change: "/>
            <TextBlock x:Name="change" Text=""/>     
        </StackPanel>
    </StackPanel>
</UserControl>

Pretty similar to MXML, but distinctive. As with ASP.NET pages, Silverlight puts all code in a code-behind file:

    public partial class Page : UserControl
    {
        const string url = "http://localhost:8080/Stocks/Stocks?symbol=";
        public Page()
        {
            InitializeComponent();
        }

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            invokeStockService();
        }

        private void invokeStockService()
        {
            string symbol = this.symbol.Text;
            WebClient service = new WebClient();
            service.DownloadStringCompleted += new DownloadStringCompletedEventHandler(handler);
            service.DownloadStringAsync(new Uri(url + symbol));
        }

        private void handler(object sender, DownloadStringCompletedEventArgs args)
        {
            if (args.Error == null)
            {
                this.showInfo(args.Result);
            }
        }

        private void showInfo(string xmlContent)
        {
            XDocument root = XDocument.Parse(xmlContent);
            var stocks = from xml in root.Descendants("stock")
                        select new Stock
                        {
                            Symbol = (string) xml.Element("symbol"),
                            Company = (string) xml.Element("companyName"),
                            Price = Decimal.Parse((string)xml.Element("price")),
                            Change = Decimal.Parse((string)xml.Element("change"))
                        };
            foreach (Stock stock in stocks)
            {
                this.company.Text = stock.Company;
                this.price.Text = stock.Price.ToString();
                this.change.Text = stock.Change.ToString();
            }
        }

        private void symbol_KeyDown(object sender, KeyEventArgs e)
        {
            if (e.Key == Key.Enter)
            {
                this.invokeStockService();
            }
        }
    }

Notice that I used the LINQ-XML cleverness, as advocated by Scott Gu. Most dynamic language folks will probably favor ActionScript's E4X over using this lambda-ish query language and a statically defined class. Actually I'm sure I could refactor this to not use the class at all, and just set the text fields during the query.

Finally, the other major difference between the two is the Flex framework's mx:HttpService. This component encapsulates the call to the back-end and provides dynamic binding. There is no handler code in the Flex version because of the binding. Will data source bindings and components like mx:HttpService find their way in to Silverlight?

AJAX, the REST Killer

I was at a demo today that was showing off an application that was designed to be a reference implementation / blueprint app. Of course it had some AJAX based features in it. One of the AJAX calls allowed an existing object to be edited, and another would delete said object. I noticed that the AJAX was using HTTP GET. I pointed out to the developers that since this was supposed to be a blueprint app, it should get everything right and use POST for both of these. Of course it should really use a PUT for the update and DELETE for the delete, but browsers just don't support that.

After the presentation, one of my colleagues pointed out that a lot of times we are forced into GETs because of cross-domain calls. He was right, and made me realize how the hack-that-is-AJAX is always rearing its ugly head. Cross domain calls are part of life for any large, distributed site. In an AJAX world you either have to use JSONP style calls, i.e. using a Script tag to make your call, or you have to use a server proxy. Of course going directly to the appropriate domain is much more efficient, so JSONP is going to usually win. There's no way to do an HTTP POST on a Script tag, so there you go. Forget all about respecting the REST protocol.

Of course Flash and Silverlight (gotta include it now!) both allow for declarative cross domain security. No need for JSONP hacks. Now if only they both supported HTTP PUT and DELETE...

Silverlight Slim and Fat Flex

A couple of days ago, I talked about Silverlight 2.0. One of the interesting things to me was that it was how Silverlight RIA-style apps could be a lot smaller than Flex apps. I posted a comment to Scott Guthrie and he was kind enough to post a reply to my question. His reply indicates that for Beta 1, a relatively complex application will be slightly smaller than the same thing in Flex. However, much more of the framework is going to be included with the initial Silverlight download starting in Beta 2, thus giving Siliverlight a huge advantage in terms of app size.

When Adobe announced that the Flex framework could be cached on the Flash player across domains, I wondered why the didn't just included it with the Flash player. I have even bugged Flex evangelist Ted Patrick with this question. His response to me was that they would open themselves up to "DLL hell." In other words, there could be problems with people building their app against Flex framework version X, but a user has an older version installed.

As if this doesn't already happen! Let's not forget that Adobe jumped ActionScript from version 2.0 to 3.0 and thus required Flash player 9 or higher for anything authored using 3.0. This was not just some update in framework, it was the entire programming language being overhauled. It is common to use JavaScript to detect Flash player version and require people to upgrade. It is so common and so part of Flash development, that Adobe distributes the ExpressInstall SWF for doing this as easily as possible. Heck, I usually require users to be on 9.0.28 or higher, since that is the version that fixed some bugs with ExternalInterface.

So back to the Flex framework/DLL hell issue. It would simply require people to check for a certain minimum version of the Flash player (since that would correspond to a version of the Flex framework) and prompt for an upgrade if needed. In other words, it would require something that most folks already do today.

To me the real reason is that it is more economical for Adobe to not include the Flex framework. Ted has a widget he wrote showing over 3.9 billion downloads of Flash player 9. Add an extra 200K to that and you get over 726 TB. That's a lot of bandwidth to pay for. That's a price Microsoft wants to pay, because it would indicate lots of folks with Silverlight installed. Perhaps once that happens, Adobe will reconsider.

No Silverlight for You

I attended an MSDN talk this week on Silverlight. It was given by Microsoft evangelist Anand Iyer. If you've been to any Microsoft developer centric events in the Bay Area, chances are that you've got to listen to Anand. He's an excellent speaker and this week's talks were no different. One of the things that makes his talks so good is the honesty. There's no BS, marketing spin.

My chief interest in Silverlight is as an "RIA" technology. I put RIA in quotes because there are different interpretations of that acronym. I was used to a definition similar to the one in Wikipedia: Rich Internet Application. The key in this definition is bringing a desktop-like experience to web applications.

Microsoft's definition is different. They call RIAs: Rich Interactive Applications. To them it is not about web applications with a desktop-like experience. It's about media. This may seem like a minor point, but actually it's the only point worth mentioning to me. It was the most important thing I took away from Anand's speech: Microsoft is only interested in rich media when it comes to Silverlight.

This seemed contradictory to me. After all, they've made a big deal about bringing the CLR to Silverlight 1.1. But Anand was crystal clear on this. If you want to build web applications, then you should be using ASP.NET and all of its great AJAX goodness. You can use Silverlight, but it's going to be very difficult as this is not the focus of Silverlight.

Indeed this message is consistent with the use of Silverlight. You can create a Silverlight application in Visual Studio 8, but you're going to be editing XAML, i.e. XML. Essentially you're creating low-level vector graphics commands wrapped in XML. One of the other attendees at the MSDN talk asked Anand if there is any kind of nice designer that was going to be built in to Visual Studio to make this easier and the answer was "Yes there will be a design view, but it is awful. You need to use Expression Blend."

And there it is. If you want to do Silverlight work, you need Blend. This is a tool made for designers and is not even available to MSDN subscribers. This tool is not meant for developers, and thus Silverlight is not meant for developers.

It's only meant for designers. It's only meant for creating animations or embedding video, etc. That's all Microsoft is going for. Imagine if Adobe got rid of Flex and said "you have to use Flash CS3." That's Microsoft's position.

Again with CLR support built into Silverlight, you might think that it's just a matter of time before it becomes a developer platform. But from what Anand had to say, it's going to be a long itme. There's not going to be developer support in Silverlight 1.1 and Visual Studio 8. VS8 won't be shipping until February and Silverlight 1.1 won't be shipping until next summer. Given that, I would have to guess that it will be at least two years before Silverlight becomes something that can be used by developers. That's truly disappointing.

The Pain of Silverlight

I'm starting to write the Stocks application with Silverlight. I installed Visual Studio Orcas. That took forever. I installed the Silverlight extension to VS and the Silverlight 1.1 runtime. That was a lot to install! But that's the hard part, right? Microsoft development tools are great, right?

Uhh, no. Creating a Silverlight project was easy enough. I was surprised to see that VS did not provide any kind of visual designer for Silverlight. It was basically just an XML text editor for creating XAML. I was able to quickly throw together Hello World. I hit the Run/Debug button, and hit my first problem. VS had a problem passing the URL for my Hello World page to Firefox (the default browser on my system.) So I changed my default browser to IE, and tried again. Hey that worked.

I played around with the IntelliSense in the Silverlight/XAML editor. I only saw graphical options. No form elements. I needed a way for a user to input a Stock symbol for my Stock app! So what to do?

There is a visual designer for Silverlight, Expression Blend. So I downloaded that (yet another download) and cranked it up. I created Silverlight project in it. I looked for a text input box in the palette, but didn't see anything I consulted the Help. It indicated that there should be something in the palette for this:


Further exploring Help reinforced this:



The icon I see there sure looks like the Icon in the first screen, near the blue circled 4. But when I use Expression, I only get the TextBlock option. That's also the only option I got when I used IntelliSense in Visual Studio. I'm getting the impression that Silverlight does not currently support any kind of text input!

It appears that I am not alone in this frustration. Luckily that led me to some text controls that somebody else made...

Flex Stocks

As planned, I re-implemented the Stocks application from the first GWT tutorial using Adobe Flex. Here is a link to a short document I put together outlining the code and the interesting parts. It also has links for downloading the code I wrote.

It was really pretty easy to do this. Of course this was a pretty simple application. I might try to re-implement the advanced version of the Stocks application from part of the GWT tutorial. First, I'll do the easy one in Silverlight.

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.

JavaFX

I guess the big news out of JavaOne today is JavaFX. The more I heard about it, the more it sounded familiar. Sure there's the obvious comparisons to Flex and SilverLight (more on that soon) but there was something even more familiar about it. Then I realized it: F3! I had read about F3 just last week (you can see it on my del.icio.us links) and had given it a try. So it turns I've already been running JavaFX.. Here's a picture of the F3 Calculator running on my laptop:

One of the most interesting things is the white space on my desktop. The F3 Calculator is part of it actually (or vice versa really.) There's probably some bugs to be worked on here! Also notice the little F3 icon in my system tray. You have to use that to close the calculator. The whole thing launches using Java Web Start, which is a good thing.

So yeah, JavaFX has a lot in common with Flex and SilverLight. Even in name. Microsoft had WinFX which became Windows Presentation Foundation which became Windows Presentation Foundation / Everywhere which became SilverLight. I'll say some of the same things about JavaFX as I said about SilverLight. If they could actually achieve "my dream" of writing a UI once and having it render nicely as a web app, a desktop app, and (most importantly) a mobile app, then it will be a huge success. I don't think anyone is close to that, yet.

JavaFX could actually have a lot more legs to it than SilverLight. It will be completely open, unlike either of its competitors. That should give it a huge advantage. That open nature should also mean a lot of creative integrations with the huge open source Java ecosystem. That's how JavaFX could win over developers. The key will be for Sun et. al. to deliver adequate tooling for it, as it is a UI language. Adobe already provides good tooling and Microsoft is sure to do the same. Sun's doesn't have to be as good as the Flex/SilverLight tooling, but it needs to be close. If it's not as good, you can expect to see other folks in the Java community step in.

Speaking of tooling, Cedric has a good rant against JavaFX. He smelled Sun trying to get people to use NetBeans, but as you'll see in the comments, there is an Eclipse plugin. Maybe the Jigloo guys can work with it, too. The better point that he makes is that Groovy SwingBuilder does a lot of the things that JavaFX promises to do. Maybe Sun should have leveraged that. I haven't tried JavaFX out yet, so I can't say if it has any syntactical advantages over Groovy. I must agree with another commenter that Sun doesn't seem too fond of Groovy. They seem much more interested in embracing Ruby via JRuby.

Update: I tried out the JavaFX plugin for Eclipse last night. It is quite bare-bones. It basically just lets you run a .fx file from Eclipse. No visual editing. It didn't even seem like there was any extra syntax help. I will try out the NetBeans one, but it sure looks like Cedric was right on about Sun once again trying to push NetBeans on people.

Silverlight

Microsoft's announcement of Silverlight seems to have really caught a lot of attention. I'm having a hard time understanding this. What did they really announce that we didn't already know?

• Free storage for streaming video using Silverlight: That's nice I guess. In typical Microsoft fashion, they are subsidizing the switch from an existing technology (Flash) to their own version of the same thing. Don't get me wrong, there's nothing wrong with that.
• .NET CLR included with Silverlight: This is the big news, I guess. Well not really. Using the CLR as a runtime for rich content over the web is not new. It was always one of the ideas behind .NET. It's a replacement for ActiveX, which even Microsoft seems to hate now (well at least IE7 complains and warns a lot about it.) MS obviously had to include some kind of runtime with Silverlight. Adobe has its supercharged version of JavaScript, ActionScript (Microsoft has this too, it's called JScript.) The CLR that will be included will be a subset of the "full" CLR. So it just means that Silverlight devs can use a stripped down version of C# that will (just guessing here) will perform JavaScript like duties. That's nice. I guess. I'm going to conjecture that for most things you will do in Silverlight, it will be a lot easier to use a dynamic language like JScript (or Python or Ruby, as .NET versions of those were mentioned) instead of C#. Adobe experimented with making ActionScript more Java-like with ActionScript 2.0, and re-thought the decision with ActionScript 3.0.
  
• Silverlight CLR open sourced and ported to Firefox and Macs: Oh wait, this is the big news. Actually I guess it is, but not for the reasons most people think. This is Microsoft's white flag. They are admitting that a lot of people use Firefox now and there's even a reasonable number of people using Macs. So for them to compete with Flash, they need to support Firefox and Safari.
• Silverlight CLR on Windows Mobile: This is actually the most interesting thing to me, though I am somewhat skeptical. The idea of being able to write an application that works on the web, on the desktop, and on a mobile device is very appealing to me. Heck, I basically spent a year of my life writing a language to do exactly that at Ludi Labs (RIP.) I went to one of those grandiose Microsoft launch parties earlier this year just to see what progress they had made on this front with Windows Presentation Foundation err I mean .NET 3.0 err I mean Silverlight. The stuff I saw from Mix only seemed to indicate things like video streaming (more on that soon) than real application development. That's why I'm still skeptical. I've written Windows Mobile apps and it is definitely a differentiated development experience vs. writing a Windows application. Sure a lot of things are similar and you can use some of the same languages (or a subset, does this sound familiar?)

Now part of why I'm not so impressed with Silverlight is that I mostly care about application development. It seems to me that Silverlight will basically enable developers to build Flex-like applications. I see its support for CLR languages as a minor advantage. It will be interesting to see if they give away a Visual Studio Express edition for doing Silverlight development. That would be an advantage over Flex. Otherwise, I see this playing out similar to how the introductoin of C# and .NET played out. Microsoft shops may switch to it, but it's hard to imagine Flex developers switching to it.

There's big wrinkles I've left out. The biggest is streaming video. It may very well be that Silverlight provides superior streaming video capability. If that is the case, then a Silverlight based YouTube would seem to have potential. It would be a real boon to pirated video, like HD episodes of TV shows. That would be huge. If works great on phones, even better.

The last piece of the puzzle is the desktop. Is Microsoft going to push Silverlight as a desktop application development? I did not get this impression. It seems possible, but why would they do this? Adobe is certainly going this route with Apollo, but Adobe doesn't have any presence on the desktop. Microsoft already owns it. So it seems like Silverlight would only be used as a counter, if needed. I'm not really sure it will be needed though.

Opening Up Flex

Interesting news on Adobe open sourcing some of the Flex platform. Here is a cool video from the Scoble Show on the architecture.

For the past couple of years I've thought Flex had some clever concepts behind it, but it was going to be collateral damage in the ascension of AJAX. Why? It was too closed on multiple levels. First, to take advantages of its greatest strengths (continuous, bidirectional communication between client and server) required a proprietary Adobe server. Second, the development tools were also proprietary. It's hard to quickly prototype something in Flex, unless you've already made an investment in it. That is poison for innovation. That's also why so much more innovation occurs in Java and PHP rather than .NET, but I digress.

I don't think the above equation has changed with Adobe's new open source initiatives. However, it seems like maybe they are more concerned with competing with .NET/XAML/SilverLight as browser/desktop hybrid technologies. There might be some potential in that, but I still don't think they have the right strategy for it.

Imagine if you were at a mall and you were hungry. There were several hamburger stands in the mall. The hamburgers were pretty cheap and pretty good, and there was a lot of variety. There was one place (Microsoft) that sold hamburgers and fries, but it was very expensive. Now let's say you wanted to sell hamburgers and fries as well. You could make a hamburger and fries that were in similar quality to the sole hamburger+fries vendor, and maybe charge a little less. Or you could make a hamburger that could stand on its merits to the many hamburger-only places, and charge a price similar to those guys. It's riskier, because there's so much competition, but you could still charge a nice premium for the fries. If people start buying your hamburgers, there's a good chance some will splurge on the fries too.

Adobe has chosen to charge a lot for both the hamburger and the fries, just like Microsoft. It's a safer strategy, but with a lot less upside in my opinion. They have to hope that Apollo will lead them to success, because otherwise my original thought will still hold. Flex will be a casualty of Web 2.0.