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.
Thoughts on Node
I’ve been watching NodeJS for a while now. I thought that I wanted to get into Ruby on Rails for personal projects, since it is a cleaner version of the OO paradigm I’m used to with Java. But I’ve also been doing a lot of client-side JavaScript, using both JQuery UI and ExtJS.
After several false starts, Rails was just not sticking. It’s not the fault of either the language or framework, both of which are exceptional. It’s more a case of the whole “OO MVC” web stack is just feeling old. So I decided to update my Node and NPM installs and take a look at web development through a different lens.
Node stuck. I haven’t had this much fun coding in a long time. Node feels like what Java felt like in the JDK 1.1.x days. It has a lean API and begs to do anything you can throw at it. And like early Java, it is moving at the speed of light. The number of new projects popping up on GitHub around NodeJS is staggering.
Since I’m playing with web stuff, I’ve mostly been looking at the Express stack. It’s a lot like Sinatra for Ruby, but with JavaScript syntax instead of Ruby. It’s also very quick to code with. I’m using NodeJS and Express with Redis, and it’s a blast. I’m working on a sample project using JQuery Mobile just to get the hang of it.
The biggest surprise with NodeJS is how quickly the ecosystem is growing. GitHub and NodeJS projects were made for each other. You can now host Node applications on Heroku and Cloud Foundry. The package management system (NPM) is tight and easy to learn. The biggest shock was that Microsoft is even getting on board with helping to port NodeJS to Windows.
JavaScript is now the place to be playing and NodeJS really does make it possible to do it end to end. I’m having a lot of fun digging in to it, and we’ll see where it carries me.
Looping Out
Yes, I confess, I follow @DHH on Twitter. He can be rather opinionated, but he has an interesting point of view on things. Plus, it is a good way to keep up on the thinking behind Ruby on Rails. Just this evening he put a shot across the bow of JQuery with this tweet:
Since JavaScript library performance is something that interests me, I took a look at the benchmark he linked to. It is a pretty straightforward test of JQuery’s each() method compared to a custom function called quickEach(). On my MBP, the results look like this:
First, kudos to jamespadolsey for coming up with this. The speed difference is pretty shocking. But even more interesting, the test harness is extensible, so I decided to see how the latest Ext-Core stacks up.
First, I had to tweak the setup code a bit. It was creating a JQuery object which wrapped an array:
var a = $('<div/>').append(Array(100).join('<a></a>')).find('a');
I kept it simple and turned this in to:
var a = $('<div/>').append(Array(100).join('<a></a>')).find('a'); var b = a.toArray();
This gave me a real JavaScript array to work with. Then, I added a new test case which looked this:
Ext.each(b, function(item) { Ext.get(item); // Ext.Element });
Running the jsPerf test with this snippet gave these results:
My first reaction to this was along the lines of WTF! My faithful Ext-Core was getting its ass handed to it by JQuery. But then I spotted the error in my ways. Using Ext.get() is very expensive for operations where you plan on discarding the Ext.Element afterwards. It adds an id to the DOM element, then puts the wrapped DOM element into a cache to speed up subsequent operations. For cases like this, where we’re going to throw the Ext.Element away, the Ext.fly() method is what should be used.
Here are the results using Ext.fly() instead:
Now we’re talking! Using Ext.fly() gave some pretty good results, although there are probably some ideas to be borrowed from the hand-rolled JQuery quickEach() method.
Not being satisfied with a contrived example which was just discarding the wrapped DOM element, I then tweaked the test. I changed each of the test cases to add a class to the wrapped element inside the loops. For giggles, I added two additional tests. One using JQuery’s addClass() method against the set of elements, and one doing the same thing using Ext.select().
Here are the results:
Suddenly that speed difference in the first test cases starts to look a lot less significant when it actually comes time to do something in the loop. Adding the class to the DOM node wrapped in an Ext.Element using Ext-Core turns the first results upside-down.
Even more interesting was JQuery’s performance using addClass() on the JQuery element and not using the each iterator. It looks like JQuery is soundly implemented for set operations. So the lesson is treat JQuery more like SQL than code — if you’re trying to do each(), you might be thinking about the problem wrong.
I won’t even attempt to address the whole “beauty” angle. I’ve learned from the ExtJS-JQuery flame wars that beauty is definitely in the eye of the beholder. And if you want to dork with this yourselves, my playground is Revision 15.
Sencha Touch Initialization
I’ve finally had the chance to dig in to Sencha Touch. I was really impressed with the framework from what I saw at SenchaCon last year, but I had been too busy with regular web development to get very far with it. That all changed now that I’m working on a mobile website for work.
Sencha Touch is very well documented, and has a boatload of examples. Unfortunately, some of the examples don’t necessarily promote best practices. The first place I ran in to problems was on setting up an Application.
If you look at the documentation and the examples, there are three ways to initialize a new Touch application:
Ext.setup({...})Ext.ApplicationManager.registerApplication({...})new Ext.Application({...})
Most all the examples use the first method, including the more complicated GeoCongress app. Unfortunately, this isn’t the best method for real-world applications. It is designed for quickly setting up a Viewport and rendering a container. Yes, some of the more complicated samples use this technique, but doing so costs you a lot of the free stuff that come with using one of the other two approaches.
The second approach is used in the Kiva and Twitter examples. The end result will do the same as option #1, except you’ll have an Ext.Application object to work with. Ext.Application is one of those secret sauce objects that take care of a lot of the common setup tasks for you. When you initialize an Ext.Application, the object automatically creates a set of namespaces for your views, stores, models and controllers, prefixed by the application name. It also provides support for a load mask and sets up an Ext.History object for the application. Finally, it integrates with the Ext.Dispatcher object for handling custom routing of requests and registers the application with the ApplicationManager.
The third approach is nearly exactly the same as the second option, except you are directly instantiating an Ext.Application versus delegating to the Ext.ApplicationManager to create that application. This means that the Application will not be registered with the ApplicationManager. In practical terms, this really doesn’t matter. The Ext.ApplicationManager permits you to register multiple logical applications for a single physical Sencha Touch site, which is not something I see as being necessary.
While trying to sort this all out the first time through, I put out a query on Twitter to see what others thought. I was pretty much between options #1 and #2, but the awesome James Pierce (@jamespierce) from the Sencha team chimed in and recommended option #3 as the best going-forward approach.
The Contender
I got around to installing the IE9 RC this weekend. Kudos to Microsoft. At SenchCon, Ed Spencer commented that IE9 was “just like a modern browser”. Since JavaScript performance has been one if IE’s greatest weaknesses, I ran it against a couple benchmarks to see how it compared to the reigning champion, Google Chrome.
First, I triedSunSpider. To my total amazement, IE9 actually bested Chrome on the SunSpider benchmark.
Next, I tried Google’s V8 Benchmark Suite. On this suite, I saw the results I have typically seen before. Chrome posted these results:
And IE9 RC came in with these:
So on V8, Chrome destroys IE9, but on SunSpider, IE9 eeks out a slight lead. I could go in to endless speculation about benchmark optimization and validity, but real world results are what matter. So I’ll give IE9 a fair try as my primary browser for a week and see what happens.