Abel and Ready
This is the story of Abel, a hard-working, dedicated Java developer. One night, after a hair-pulling coding session with Spring Security, Abel was visited by the Ghost of Java. “Abel, you have been extremely dedicated to me,” said the Ghost, “and for that, you will be rewarded.” “You will be visited by three ladies of the night as a reward for your years of sweat and turmoil hacking me,” the Ghost continued.
Two thoughts quickly raced through Abel’s mind. First, being a Java developer, it meant he would actually have to shave and shower for the next three days. Second, being a dedicated Java developer, three ladies in three nights might be a bigger task than he could handle. But throwing caution to the wind, he told the Ghost of Java he was up to the task, although he mentioned he would have preferred Java 7.
On the first night, a rather mature woman, slightly past her prime, showed up at his door. She was perfectly dressed in a revealing blue dress, but her exquisite makeup was not up to the task of concealing her sags and wrinkles. She said her name was IBM and that she would show Abel a good time. What she lacked in looks she made up for in conversation. She treated Abel like the center of the universe and was always ready with a supportive comment or another glass of expensive champagne. Abel was somewhat satisfied with the happy ending to the evening. It wasn’t spectacular but IBM made sure he knew it was all about him.
Abel’s second night took an abrupt turn for the worse when the next lady walked in. Looking like a crack whore in a thousand-dollar mini skirt, Abel’s new date introduced herself as Oracle. Upon seeing her, Abel’s first reaction was to put his hand on his wallet. Unlike his prior date, Oracle made clear the world revolved around her. She talked all night about the great many tricks she could do for Abel, but all for a price. Abel was thoroughly distracted from the happy ending between trying to keep an eye on his wallet and worrying he might catch something from his new date.
On the third night, Abel hid in his closet, fearing a repeat of the second night. Instead, he was pleasantly surprised when a curvaceous, girl-next-door redhead came in to his room and introduced herself as Microsoft. Although not much for conversation, Microsoft had curves in all the right places and not a wrinkle to be found. Abel got a chuckle over how she liked spinning in the flowers and talking about her MySpace page. The happy ending was very easy; so easy in fact that he wondered how he would ever be satisfied with anything more complicated again.
Abel’s plight is one that many Java developers have run through their head this past week as news made it out that Oracle had purchased Sun Microsystems. IBM, the aging monstrosity it is, would have killed Java through neglect. Oracle, the crack whore of software, will possibly kill Java through trying to monetize (read “nickel and dime”) the development community to death. And then we have Microsoft, with C# 3.5, whispering sweet nothings in developers ears.
So what is a Java developer to do? I fretted over this most the week so that I could be more rational when I put the pen to it. IBM owning Java would not be pleasant due to IBM always managing to be five years behind the technology curve. While that might be popular with large enterprises, it does nothing to please the alpha geeks that made Java what it is today. We can joke about Java being the new Cobol. IBM would have guaranteed it.
About the only worse possibility would be for Oracle to own Java, which is where we find ourselves today. Whereas Sun was an engineering company, Oracle is a sales company, and software developers strongly prefer dealing with the former. I have no doubt that Oracle will try to find a way to monetize Java, to the detriment of the community.
Finally, we have the wildcard Microsoft. C# is not much a leap for a Java developer. And having sampled their forbidden fruit, there is definitely something to be appreciated. Microsoft would be more than happy to offer disenfranchised Java developers a new home.
But ultimately, there is another option, as Rod Johnson pointed out. Through the open source community, Java has grown beyond any one vendor. Yes, Oracle may try and stifle this community through a future Java release under a restrictive license which breaks compatibility with open source Java, but that would only cement their irrelevance.
Oracle’s ownership of Java means that the fate of Java is now in the community’s hands and not a vendor’s. There will not be much love for Oracle with Java developers, so I expect the next version of Java anyone cares about to called JDK 7 and not Java 7. And it will be a true, open effort of dedicated developers and the Java ecosystem they have grown. So as tempting as it is to cave in to C#, I’m going to stick with Java for now and see where we can take this.
April: Going Direct
My ongoing saga of charitable giving stays on a humanitarian path for April. Although I strongly considered giving more to two of my favorite previous charities, I decided to try something different. So for April, my $100 goes to Direct Relief International.
DRI provides worldwide humanitarian assistance to people in need, including inside the United States. This keeps a theme going I created with a donation to MSF in January. Based on their rating with Charity Navigator, I’m confident my $100 donation to DRI will be put to good use helping people.
Slick Speed
One of the big questions that people have had about ExtCore is why didn’t it make use of the Sizzle selector engine. That was one of the questions I wanted to get answered at the Ext Conference last week, and I managed to pin down one of the core developers to get an answer. Their opinion was that Sizzle is too large and too slow. I don’t really care about the size aspect. They all tend to pack down into the 25K range, but I was interested in the speed comment. Like a lot of folks, I was led to believe that Sizzle had a lot of, well, sizzle. So in the interest of getting to the bottom of the story, I did a little unscientific testing of my own using Slickspeed, which tests selector engine performance.
I grabbed the latest of the main libraries: ExtCore (beta1), JQuery 1.3.2, Dojo Core 1.3.0, Prototype 1.6.0.3 and the Sizzle engine by itself. I ran Sizzle by itself because although JQuery uses Sizzle, the version of Sizzle in JQuery 1.3.2 is 0.93 while the current version on the Sizzle website is version 1.0. I used the latest version of Slickspeed and made three runs in IE8, Firefox 3.0.8 and Chrome 1.0.154.3. Yes, I disabled Firebug in Firefox. My dev desktop is a rather beefy Windows Vista 64-bit machine with a quad-core 2.66ghz CPU and 8GB of RAM. I did a complete page refresh between runs to start relatively clean. I was going to relaunch the browser between runs, but it ended up not making much of a difference.
First up was the latest and greatest from Microsoft, Internet Explorer 8.
- Prototype: 440ms
- Dojo: 61ms
- JQuery: 48ms
- ExtCore: 80ms
- Sizzle: 46ms
The image shows the results from the last run. I was actually surprised that IE8 did reasonably well. One thing is clear, friends don’t let friends use Prototype with Internet Explorer.
Firefox was a slightly different story. The selector engine in Prototype still got its clock cleaned, and ExtCore swapped around with JQuery and Sizzle:
- Prototype: 145ms
- Dojo: 64ms
- JQuery: 77ms
- ExtCore: 49ms
- Sizzle: 71ms
It was interesting both Sizzle implementations slow down in Firefox. I would wager that the Sizzle folks made a conscious decision to optimize the core selector engine for the most widely used browser (Internet Explorer). ExtCore leaps ahead with Firefox 3, while Dojo is still pretty consistently finishing in the middle. Oh, and friends don’t let friends use Prototype with Firefox either.
Chrome is an absolutely game-changing stunner of a browser. Based on the selector benchmarks, the developers for all these engines should be offering to have children for the Chrome developers:
- Prototype: 13ms
- Dojo: 7ms
- JQuery: 8ms
- ExtCore: 13ms
- Sizzle: 8ms
Even lowly Prototype with Chrome makes any of the other libraries running in Firefox look like they’re standing still. Chrome is simply ungodly fast with all them. ExtCore could probably still use some tweaking, but we’re talking about a 7ms delta between the fastest and slowest.
So the Ext team’s claims for Sizzle being slower are only partially true. Sizzle appears to be faster in Internet Explorer, while the story flips around in Firefox where ExtCore is faster. All of them, even Prototype, are fast in Chrome. Pray for the day when Chrome takes over the world. Until that time, It looks like all them (Dojo, JQuery/Sizzle, ExtCore) are good in IE and Firefox, with the nod going to JQuery/Sizzle for Internet Explorer, the browser market share leader. And you really, really don’t want to use Prototype until all your clients have moved to a modern browser with native selector engines, or Chrome.
One glaring omission is that I didn’t test with IE7 or IE6. Using either of those browsers is also on my “friends don’t let friends…” list. It would be safe to say that they would both be slower. As I don’t have either installed on any of my computers, I would be happy to add an update for anyone who wants to run the tests themselves.
The Ext team earns some slack in their Internet Explorer performance as they are only a beta compared to the others. I’ll rerun the test again when ExtCore goes GA. And on a final note, here is the config.ini file for Slickspeed in case anyone wants to try the benchmark themselves, or you can grab the whole Slickspeed install with the selector engines configured.
Ext Conference, Day 3
The third day of Ext Conference 2009 was only a half-day, which turned out to be a good thing given the trainwreck start. They were an inexcusable 20 minutes late in opening the door for what should have been 15 minutes of closing remarks. Instead, it turned into a 30+ minute demo of the new UI designer. Yes, the designer is awesome and will rock the ext world, but it is beyond me why they would improvise a demo on the morning of the last day. This should have been either on day one or possibly part of Jack’s keynote on day two.
With events now running 45 minutes late, the final two sessions ended up being pretty disorganized. I went to the “Mainframe to Web” presentation by Rich. I had just done a similar project and was interested in what he had to say. Turns out their showcase pretty much faked an integration with the backend by using a screen scraper on the server side which translated terminal session screens to ExtJS metadata. They didn’t change any of the backend code at all. I’ll give them credit for finding a clever solution, but I’m not convinced it is the best one. When we confronted a similar problem, we ended up wrapping backend functionality in AS/400 stored procedures we called from the middle-tier.
The positive side effect of the wheels-off schedule was that Rich rushed his presentation to try and wrap up on time. The other presentation, ExtJS deployment, was only halfway done, so I jumped in to catch the last half of it. In this case, it seemed like the heart of the presentation was in the last half, so I basically got the best of both presentations.
The deployment presentation covered a lot of the useful tools for bundling up your JavaScript. I had heard of JS Builder before, but plan on taking a deeper look now. It can create a single JavaScript file from many smaller files. YUI Compressor is the recommended tool for really putting the squeeze on your JavaScript files, but even then, Jamie still recommended ensuring you use GZip/Deflate on the web server for JavaScript files. He also talked about a tool for creating a multi-image sprite file of several small images that can also have a big impact. I came away with a lot of things to research and this should be a top presentation to check out when they put them online.
The final session for the day was Scott covering the Ext.Writer. This has got to be one of the coolest features of ExtJS 3.0 and they really should have moved this earlier rather than waiting for the last minute. The Writer addresses the problem of handling CRUD operations for Stores. It can use REST-like URLs like /app/update/1 or /app/delete/1 with the record ID as the final parameter. It pushes a JSON object back to the server containing the information that needs to be acted on. It even addresses passing a primary key back to the Store on a create operation. This is looking a whole lot cooler than Ext.Direct and I want to give it a try for my application.
I didn’t sit through the final Q&A session as I needed to bugout for the airport. Based on the tweets so far, it doesn’t look like much was discussed. Overall, the conference was excellent and I can chalk up the final day to growing pains. What will be interesting to see is what happens in the coming weeks. Ext.Direct was talked up in about every session, but there is an incredible lack of detail for how it will be implemented with mainstream enterprise technologies (Java/C#). Abe talked about the Marketplace, which sounds like the equivalent of RubyForge for ExtJS. If they can get it up, it will be cool. Finally, the UI Designer is what everyone really wants but it is slated for v3.1, and no one would talk timelines for it.
Ext Conference, Day 2
After the 100mph pace yesterday, day two of the conference settled in to a comfortable 55mph. The big news of the day was during the keynote, when they released RC1 of ExtJS 3.0. Jack was the scheduled keynote speaker, but I get the impression he doesn’t like speaking in front of large groups. His keynote lasted all of five minutes. He covered the history of ExtJS in two minutes and said ExtJS 3.0 is here. And that was it. Abe was left scrambling to fill a rather large hole in the schedule, and he called up Darrell of the GXT (Ext GWT) team to talk about their v2.0 release.
Darrell is a nice guy, but I was ready to pull my hair out listening to him. I had lunch with him yesterday and to say he is excited about GWT is a major understatement. In spite of being a Java guy, I don’t like the idea of writing my web UI in Java. It’s like the Hibernate mafia who think you can write a database application without knowing SQL. Each of the tiers has a best-in-breed language for addressing that tier’s problems. An enterprise developer better know SQL for talking to databases, Java/C# for the middle tier and HTML, CSS and JavaScript for the front end.
After the keynote, we had another smoothie break. The smoothies were good, but the general consensus would have preferred coffee in the morning and smoothies in the afternoon.
Aaron kicked off the regular sessions with a breakdown of the signature demo in ExtJS 3.0 — Image Organizer. This is the meatiest demo so far, and was interesting to see how they structured the code and where they subclassed. The application uses Ext.Direct, but the backend was only PHP. One of the first questions Aaron got asked was when they would release other backends. He really danced around the question without giving a true answer, saying that maybe there would be something released in the next week or so. Ext.Direct is starting to sound like a lot of vaporware. They talk a good game of how it will be able to use annotations/attributes server side for exporting objects and other cool stuff, but no one is producing any code. Ext.Direct is the new Duke Nukem Forever.
The next session I attended was one of the funniest. Glen Liptka talked about user experience design with ExtJS. He is at Marketo, which has done the most incredible theming of ExtJS I have ever seen. He started the talk covering general usability and then demonstrated their application. The point he made that stuck with me is that your UI should have low WTF/min. Everyone got a kick out of that.
Next up was JC Bize talking about theming ExtJS. JC is the author of the Slate theme, one of the most popular third-party themes used in ExtJS. He is now an employee of Ext, LLC, so hopefully we’ll see some more cool themes in the pipeline. He showed off a couple cool themes and then got in to a basic example of how to change the theme of a panel. When playing with themes, Firebug is your friend. Unfortunately, he got sidetracked trying to answer an audience question and the presentation fizzled out.
I couldn’t catch the last session, as I had to make a phone call, but came back for the day-ending Ask the Ext Team. Nothing major came up. I tried to ask the question of why they didn’t use Sizzle for Ext Core, but my question didn’t get voted up and they ended the session before they got to it.
The day wrapped up with a social down by the pool with a cash bar. I really started to hate the Ritz after paying $8 for a beer. They definitely need to move the conference to someplace that understands Happy Hour. I managed to corner Aaron at the social and got my Sizzle question answered. He said they didn’t use Sizzle because it was too big and too slow. He did say the DOJO guys were working on a very cool new engine called Acme that looks promising. DOJO makes me nauseous just looking at it, so I won’t be investigating it.
The day ended for me again at the bar. I had dinner with another attendee who works at the DIA. Since I have a similar background, we had a lot to talk about. $35 for two margaritas and a plate of chicken quesadillas — ouch!
Day three is only a half day, but there are still two sessions I’m interested in, so it should be fruitful.