Eli Bendersky's website In the past few months a new meme seems to be very vibrant in the world of web-development: server-side Javascript. The idea certainly isn't new - Netscape had offered JS on the server-side sometime in the 1990s. Since then, powerful dynamic languages like PHP, Python and Ruby along with Java and ASP have taken over the server-side development scene. So what has happened recently to stir the balance?
It's hard to tell, I can only guess:
- Javascript is growing in popularity as more and more powerful applications get written in it to run in the browser. This increases the amount of programmers interested in it, as well as the total amount of Javascript code out there in the wild.
- A zoo of new and powerful implementations has appeared recently. A real arms race between Google's V8, Mozilla's TraceMonkey and WebKit's Squirrelfish boosted the performance of Javascript engines considerably in the past couple of years.
The first reason, in particular, is very important. These days a web-developer has to constantly switch between two programming languages - Javascript for the client, and his server-side language of choice for the server. Many people started feeling that this is a useless split of attention, and using a single language both for the client and the server is a good idea [1].
Why it's bad
First of all, further fragmentation of the server-side development community. Aren't there enough ways to write web-applications as it stands? Multiple languages to choose from, multiple frameworks to use once you've chosen a language. Do we need another language & platform for server-side development? What's so bad with having two tools, each suitable for its domain?
The other reason I see is more controversial. Javascript is far from being an ideal language. While it has a good core in it [2], there are also a lot of quirks and design faults. Oh, and there's a ton of horrible code out there that just gets copy-pasted from project to project. I'll stop here since I don't want to turn this post into a language flame-war, but I'll do say that I'd prefer coding in Python or Ruby over Javascript, and thus it's disturbing that Javascript starting to take a share of the server-side cake.
Why it's good
Just as the rise in popularity of JS in the browser brought us faster engines that make the internet experience more pleasant, I think that examining new approaches is generally healthy. There's a lot of excitement around this issue lately - excitement that brings talented developers in, places them in the zone for productive hacking, and overall provides a fresh perspective on things.
For example, one of the most exciting tools in this scene is Node.js. It's a Javascript interpreter built on top of V8 [3]. What's really cool about Node.js is that it's completely event-based, designed and tuned for asynchronous non-blocking I/O. Asynchronous non-blocking I/O seems to be all the rage recently, as it was found to be greatly enhancing the performance of servers, allowing to handle huge loads of concurrent connections within a single process, without using threads.
This approach isn't new. Twisted is a venerable and powerful event I/O library for Python, for example. However, when you code with Twisted you have to be careful to use only very specific Python modules - use one that is blocking and you've ruined the whole model. Node.js, on the other hand, comes with its own standard library that was designed from the ground-up to be 100% non-blocking.
It's only fair to note that in this area of event-based programming, Javascript actually has an advantage. The language's simple built-in way of creating anonymous functions is very helpful in this aspect. As a matter of fact, everyone who's written AJAX code and has used a library like jQuery (which these days covers a high percentage of serious JS developers), is already used to the event model of programming. AJAX is all about asynchronous events for which you register an anonymous callback function to handle the result when it arrives.
Node.js isn't the only general-purpose implementation of Javascript suitable for server-side development. Mozilla's Java-based Rhino is an alternative, and there are many others. As expected, we can see a lot of fragmentation between the communities since Javascript doesn't even have a commonly accepted standard library. Recent projects like CommonJS come to fix this situation, however.
On yet another hand, making one process run as fast as possible is a lofty goal, but what about true parallel programming? Event loops such as the ones offered by Node.js don't scale to multi-CPU machines, so I wonder how this situation will be handled. My bet would be on relatively independent processes communicating via message-passing and talking to mutual data stores via TCP.
Conclusion
These are exciting times. The vibrancy reminds me of the Rails hype of a few years ago. As I've mentioned, from my point of view this situation has its pros and cons, but the pros outweigh the cons. Being locked in narrow directions hasn't been historically fruitful. Mutual enrichment between communities and arms races are a much more viable way to progress.
It will be interesting to see where we'll be a year from now - I wager that many things are yet to change. In any case, if you're looking for a spot in an exciting niche of programming where you can make a difference, it seems that server-side Javascript, especially with event-based models like Node.js, fits the bill.
| [1] | As always happens, the solutions come from several sides. Technologies like Silverlight allow running C# and Python in the client, while cool projects like Pyjamas compile Python to Javascript allowing to write client-side code in Python and running it natively in the browser. |
| [2] | If you restrain yourself to the subset described in the "Javascript, the Good Parts" book. A review is due, I know... |
| [3] | Which, by the way, was specifically designed by Google to serve as an embeddable engine. |