Tags: Node.JS
There's a lot of excitement brewing around Node.js with a rapidly growing community of people and projects surrounding the platform, and at least five books either published or on their way to being published. I myself am working in a team at a company I cannot yet name on a large Node.js project that could be very significant. The team is excited about the platform but also have some real eyes on the question of whether this makes sense for the company, or what. I thought it would be interesting to run through some attributes of Node.js and ponder what might or might not contribute to the excitement about Node.js and its eventual success. I'm also interested in what others think, so consider leaving your thoughts below.
JavaScript as an excellent language: I'm pretty new to JavaScript and still haven't fully grok'd it as an "excellent language". It certainly has some advanced features. However I spent over 10 years writing Java and think it's an excellent language as well. They're both excellent in different ways.
JavaScript is certainly light years better than PHP and Perl.
However one thing I'm worried about in Node.js is it's a single language execution environment. JavaScript Only. The other languages have their value but Node.js doesn't allow one to write anything but JavaScript code. The Java ecosystem allows multiple languages on top of the JVM, so long as someone can write a compiler from the language to Java bytecodes. If Node.js had been implemented on top of Java (don't laugh, it has event driven I/O and could be the basis for the Node.js model) then for free it would have been able to use multiple languages. A particularly important language for server side is PHP (and Java) and because Node.js is JavaScript only it carries with it an unwritten question of whether one should rewrite every application in sight in Node.js. If it's so much better then why do "legacy" applications need to remain written in Perl or PHP or Python or whatever? Well, what about the embedded investment in writing and testing those existing applications?
JavaScript on the server (free'd from the browser): Hurrah, JavaScript has been freed from the browser and it can now be applied to other tasks. One of which is Node.js. This is a great thing. But ..
Same language on browser and server: This is one thing we gain from freeing JavaScript from being chained to web browsers. That an application can have browser and server components in the same language, raising the potential of dynamically shifting code from browser to server and back depending on architectural decisions, and that the front-end and back-end teams speak the same language. Lots of goodness can come from this. But my management aren't so thrilled by this attribute and don't see this as a big selling point.
Event driven I/O: As I wrote earlier (see: COMET as a justification for using Node.js?) Node.js seems perfectly architected to solve a problem we expect to be more prevalent. Long running connections between web server and every client browser that's touched the server recently. Thread-per-connection systems don't scale well for this use scenario, non-threaded event driven systems do.
This architectural decision contributes to the high performance numbers claimed for it.
It's also a simpler programming model than highly threaded thread-per-connection systems.
Closures: This is part of the JavaScript is an excellent language argument. It is a specific feature the Java community has been clamoring about for years, but with no success in getting it to be part of the Java language. If you want closures however on the Java platform, Groovy is an excellent language. JavaScript comes with closures as lightweight anonymous methods. It's really nice to write a callback function and not worry about remembering the correct class template to implement as a wrapper around a non-anonymous method, as you have to do in Java. The equivalent to a closure in Java requires a lot more typing as well as implementation overhead. Way cool.
Loosely defined objects: This I think is a mixed blessing. Yes it's way convenient to be real loosey-goosey with your objects. For example just check if it has a function named suchAndSo to give you a clue whether you can use the object for something or other. But I think this is a bit of a panacea and can lead you to hairball systems as complexity grows larger.
There's an argument circling around Java for years along these lines. That because Java is so highly rigid it was inconvenient to program in, and that the rigidity hurts programmer productivity. I'm not convinced, especially when you consider all the time saved because the Java compiler knows a heck of a lot of information about each object and can directly tell you about misuse of methods, improper type combinations, and IDE's that know exactly what you're doing and can provide a drop down list of all possible method completions as you're typing code.
On the other hand there's plenty of times you need to write a light weight class whose scope is no further than the few lines of code surrounding it. In JavaScript objects can be quickly defined in passing while you're writing other code. Further you have anonymous objects that are just fields and functions with a initialization nice syntax.
I don't think there's a clear winner between rigid type systems like Java's, or loosey-goosey ones like JavaScripts. They each have their place. I worry about the complexity as systems grow and whether loosey-goosey works in huge complex systems.
These are a few thoughts. I'm interested in hearing what others have to think.
Books by David Herron
(Sponsored)
