Tags: JavaScript »»»» Node.JS »»»» Server-side JavaScript
I'm reading a blog post about what Node.js is, and there's a glaring question "why in the world would anyone want to run JavaScript outside of a browser, let alone the server?" As the author of a book about Node.js it's a question I've thought about quite a bit, especially coming as I do from the Java SE team at Sun where the work of that team was highly focused on server side software (hey, it's Java) to the detriment of the client side of Java. The question comes from a belief cemented into place by 15+ years of JavaScript in the browser that it's a browser only language. However, JavaScript has a long history on server-side and is a rather cool language, and Node.js is an excellent base for developing web applications.
What is Node? BTW, if you look closely at
nodejs.org you'll see the logo reads Node.js but throughout the site it's spelled as "Node" and in the Node.js blog there is a post discussing the trademark policy stating that the official name for it is Node. Anyway, Node is a platform for developing applications in JavaScript. It can be used for general purpose programming meaning you can write any sort of shell script or whatnot with Node. There aren't any GUI libraries for Node so it's not useful for building a desktop GUI and I think the argument would be that building a user interface in JavaScript is best done in a browser anyway. It has an excellent network I/O stack based around an asynchronous programming model and completely eschews thread-based programming. It means you're writing event driven I/O on an engine that's blazingly fast. Part of the speed is the V8 JavaScript engine borrowed from Chrome (the web browser), and part of it is the I/O stack.
Why? Isn't Apache+PHP good enough? The website you're reading this on is an Apache+PHP application (Drupal) in the LAMP model. The LAMP model has served us pretty well for over 10 years, but maybe it's time is ending, or maybe not. There is a heck of a lot of excitement about Node but that isn't always the right reason to adopt a new thing just because its exciting. Is there a real and practical benefit?
COMET as a justification for using Node.js? was my attempt to go over one of the reasons. COMET is a name for a web development strategy of maintaining a long running connection between each web browser and the server. The purpose is to bring even more interactivity into browsing websites with for example immediate response to requests. For example Facebook has developed COMET-like capabilities to for example pop up a notification when someone else comments on something you've commented on. It helps facebook retain you on their website, because it is letting you know immediately when there's something for you to pay attention to. It's not just Facebook, because for example Twitter notifies you of new tweets, etc.
That instant notification could be done with DHTML (AJAX) techniques but that would tend to overwhelm the server with a zillion browsers polling the server. Instead COMET has the server sending a push notification to the browser, and uses the active connection to browsers as the channel.
Where Node becomes important is that it scales extremely well in this scenario where a thread based architecture would not scale. On threaded architectures you typically have one thread per open connection and that becomes a horrible bit of nonscalability. The key is event driven asynchronous programming. The blog post goes over the details ..
What does "event driven asynchronous programming" mean? Asynchronous means that code execution doesn't follow the linear order of the text of the program. Event driven means that the execution order happens because of events arriving in the program. Program execution order is based on events rather than the sequential order of statements in the program text. The programming style requires learning a different paradigm, but it's not a programming style with no precedence. Any GUI programmer has to program in an event driven manner because that's how GUI's operate.
Okay, that's cool, but why does that mean JavaScript? In fact in Java, Twitter, and asynchronous event driven architecture I summarized an article about Twitter's rearchitecting that helped them implement an asynchronous event driven infrastructure, without using Node or JavaScript on the server. Twitter was able to make those changes while using Ruby, Java and Scala on the server rather than adopting JavaScript on the server. They even implemented an event driven asynchronous server of their own design, but implemented in Java.
Event driven asynchronous programming isn't unique to JavaScript and one supposes a server platform like Node.js could be implemented in nearly any programming language. JavaScript however appears to be extremely well-suited to this.
JavaScript's grew up in the web browser and as a result its features were focused on event driven asynchronous programming. UI events happen when UI events happen, making event driven asynchronous programming the natural normal way to develop GUI applications. If you think about it, handling the I/O of network protocol and handling the requests inside a web application also maps well to event driven asynchronous programming.
JavaScript comes with closures (a feature Java is still lacking), light-weight anonymous functions, anonymous classes, and plenty of other features useful in event driven asynchronous programming. Closures (a.k.a. anonymous functions) are great for passing around bits of code to execute as an event handler function.
I think we can now begin to answer the question at the top of the article.
Why JavaScript? It's an excellent language for event driven asynchronous programming.
Why Node? It's an excellent platform for running JavaScript code in a server environment, and it has excellent I/O capabilities.
Why would you do it? If your web application needs more scalability especially with the "real time web" coming to the fore. The real time web (as currently implemented) is requiring more interactivity and perhaps the COMET approach is the best way to get there. Node.js seems to have been designed explicitly to handle the real time web.
Books by David Herron
(Sponsored)
