Tag Archives: javascript

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:

JDK 1.1.6 API Docs

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:

Java 7 API Docs

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

safari4

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

chrome2

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?

  1. Choice of JavaScript engine becomes irrelevant with any of these two WebKit based browsers. They all fly, even lowly Prototype.
  2. 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.
  3. 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.
  4. 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.