NodeJS is the new Java
I’ve been getting a kick out of the thrashing NodeJS has been taking recently. The whole situation reminds me of a similar world about 15 years ago. At the time, I was working at a consulting company in France with this newfangled language called Java. Me and three guys (Remy, Laurent and Jacques) were working on an embedded Java operating system for a smartcard terminal. We were the company’s only Java developers. At the time, everyone was either doing client-server development in PowerBuilder and Visual Basic, or hard-core C and C++.
Java was a paradigm shift. But it also had a lot of warts. It was slow. Dog-ass slow. AWT was a nightmare. But everyone was attracted to it because of the cross-platform promise and the simple API. In the JDK 1.1.6 days, here is what the documentation looked like:
The API was pretty basic. It provided the essentials for network IO, file handling, collections and the object hierarchy. While others saw limitations, my team saw a unconquered world of possibilities. If was fun finding solutions to problems learning Java. But Java was a disruptive technology for a lot of people. As Ghandi said, “first they ignore you, then they laugh at you, then they fight you, then you win.” I went through every stage of it over the span of a decade with Java.
Now, fast forward to Java 7. Java is now the establishment. But Java picked up a lot of baggage along the way to earning that crown. Here’s what the current API documentation looks like:
A new developer does not see a world of possibilities, they see a world of hurt. Hell, even the old timers see a world of hurt. Nothing about this gives you the feel of Java’s original, nimble roots. Which is a shame, because what made Java great is all still there, just wrapped in a crap sandwich.
Which brings us to NodeJS. To the uninitiated, NodeJS is server-side javascript. It is on the tipping point between the “ignore you” and “laugh at you” phases, and it is progressing along faster than Java. So why would anyone be interested in a limited, single-threaded language? The documentation tells the story:
Compare this to the original JDK 1.1.6 API documentation at the top. One would dare say it’s a pretty close clone. And that is why people like it. They see a world of possibilities in that basic API, warts and all. I see in NodeJS the same spark I saw in Java a decade ago. Everyone jokes Java (and .NET) are the new Cobol — NodeJS makes them both look like the new PowerBuilder.
So I believe the original JDK perfectly nailed the API hackers want. It provided the essentials, but no more. It ran pretty much everywhere. And it was fast enough. NodeJS has perfectly replicated that, and there is no reason it won’t become as big a success. The only challenge will be keeping it lean. NodeJS has a higher chance of success than Java because Sun wanted to court the enterprise market, whereas as the NodeJS crowd, to steal a DHH-ism, doesn’t give a shit what the enterprise thinks about their language.
Beastly Browsing
Just a few short weeks ago I did some benchmarking of the then-RC IE9 and Chrome 10. I discovered that IE9 did well on Sunspider, even beating out Chrome 10, but Chrome turned around and ate IE9′s lunch on the V8 Benchmark Suite.
Now that IE9 is final, and Chrome 10 has bumped a few revisions, I reran the V8 suite. Here is how the final version of IE9 did on my Windows 7 machine:
This was about a 200 point improvement over the RC, which scored 2567. Now, for Chrome, here’s how the lastest revision performed:
I was blown away. This was a full 3000 point improvement over what I tested just a month ago. Google is definitely working overtime on V8. Apparently, Google has some of the former Sun employees who worked on the Hotspot JVM working on V8 now. This is going to have very interesting implications for NodeJS. Server-side JavaScript could conceivably be in the running to replace Java. I’m going to try to find some benchmarks that compare the Java 6 JVM to NodeJS just to how close it is getting.
For giggles, I also ran the benchmark on my new MacBook Pro with the same version of Chrome. Being a laptop, I was expecting decent, but not stellar, performance. I was really, really wrong. Here’s how Chrome 10 did on my MBP:
This is a nearly 2000 point improvement over the Windows version. I don’t know what Google is doing under the covers, but whatever it is, it really likes Mac OS X. I was shocked too because my Windows 7 machine is a downright beastly AMD 6-core box:
The MBP is actually running a bit slower:
So the lessons learned are that a MacBook Pro very much is a desktop replacement machine, and that Chrome 10 totally rocks on Mac OS X.
Revenge of the Browser
Last weekend I attended the awesome Texas Javascript conference down in Austin, TX. This was probably the best geek conference I’ve been too. It made the early Rails conference look downright corporate. TXJS had awesome parties sponsored by Google and Facebook, the top names in JavaScript for speakers, and an open bar with mimosas for breakfast. This sets the bar pretty high on the geek awesomeness scale.
One of the most interesting discussions at the conference revolved around server-side JavaScript. Some very clever programmers have taken the V8 JavaScript runtime from Chrome, wrapped it with a library and pushed it out as a runtime for executing JS scripts on the server. The project is called NodeJS and it already has a pretty rich plugin environment around it. The implication is you can actually write a high-performance server-side application in JavaScript.
The trend for the past several years has been for the server-side programming languages to hide the JavaScript from developers. Both Rails and GWT approach things with a “use our language to do it all”. There is obviously value in this approach for people who don’t know JavaScript, but NodeJS suddenly flips that model on its ear.
The NodeJS story is “you use JavaScript already in the browser, so why not use the same skills on the server”. We now have a programming paradigm established at the browser that is pushing in to the lower tiers, rather than the lower tiers pushing out to the web. NodeJS has potential to obsolete a lot of what we think of as server-side development. Both Yahoo and ExtJS have projects in the works that use NodeJS as the backend, and I bet Google must have something going too.
NodeJS is basically the new Ruby. Keep an eye on what the cool kids start doing with it, and give it a try yourself. We’ll be seeing a lot more of it in the future.
Rounding Error
A few months ago, I ran some performance comparisons of various JavaScript selector engines using Slickspeed. My intent was to validate claims made by the ExtJS team as to why they didn’t use the Sizzle selector engine in Ext Core.
Ext Core has now gone final, so I wanted to re-run my tests. But there was also some news on the browser front: Apple released Safari 4 and Google dropped Chrome 2. Being the geek I am, I had to try them out. My Slickspeed test was the perfect candidate for seeing what Safari 4 and Chrome 2 could do.
In my prior post, I said developers should be bowing at the throne of Google for Chrome and its pack-leading JavaScript performance. That crown has now been abdicated. Safari 4 and Chrome 2 are leaps and bounds ahead of everything else on Slickspeed.
Here are the details on Safari 4:
- Prototype: – 9ms
- Dojo: – 3ms
- JQuery: – 4ms
- ExtCore: – 19ms
- Sizzle: – 2ms
Safari 4 didn’t get along well with SnagIt, so I was only able to capture the bottom of the results output. Here are the results for Chrome 2:
- Prototype: – 13ms
- Dojo: – 4ms
- JQuery: – 2ms
- ExtCore: – 41ms
- Sizzle: – 1ms
This is simply stupendous. The performance of JQuery turns into a rounding error in both these browsers. As a basis of comparison, here are the prior results for Chrome 1:
- Prototype: – 13ms
- Dojo: – 7ms
- JQuery: – 8ms
- ExtCore: – 13ms
- Sizzle: – 8ms
So what conclusions can we draw?
- Choice of JavaScript engine becomes irrelevant with any of these two WebKit based browsers. They all fly, even lowly Prototype.
- Ext, LLC, screwed the pooch in not using Sizzle for the selector engine in ExtCore. It would have been a better investment in them adopting Sizzle and working to improve it rather than blazing their own trail. The difference in Chrome 2 between Sizzle and ExtCore is staggering: 1ms in Sizzle vs 41ms for ExtCore.
- The latest and greatest from Microsoft (IE8) starts to look absolutely pathetic compared to the competition. Microsoft should be ashamed of themselves for having their asses so soundly handed to them on such a critical piece of infrastructure as the browser. Whether it is due to their outdated opinions on open source, or that they can no longer attract top talent, Microsoft is proving to not even be a contender in the JavaScript performance race.
- Both Apple and Google use WebKit as the basis for their mobile offerings (iPhone and Android). The sheer power of WebKit is going to offer both these platforms outstanding opportunities for rich browser-based applications. It is clear why neither platform cares much about Flash or Silverlight: the don’t need them.
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.