An Overview - Server Siding Javascript

07/02/09

Lately, I have gotten interested in server-side JavaScript. Since I have been on a rather intense hyper-focused learning course, that my girlfriend really doesn’t care about, I decided to abuse my blog with the meandered lessons, I have gathered. A lot of the information has been hard to find and hard to process because the people who are invested in this world are so deeply ingrained in it that haven’t popped out to introduce a simple stranger. This article aims to be an overview of the state of server-side javascript today.

What is server-side JavaScript?

It is server applications developed using Javascript instead of a language like PHP or Ruby or Java. JavaScript swoops in to replace these languages. In fact it could even be used to write cron jobs or other shell scripts, once a server-side language is in place.

Why server-side?

I wondered about this too, mainly because I started working on the web around the birth of JavaScript and it has been hard to put away my distaste over its early obsession with popup windows and other disruptive marketing scams. I also grew an early prejudice in a land without FireBug or JavaScript testing.

Happily, JavaScript has changed. After years of unwillingly dabbling with it via client-side frameworks, I spent a good amount of time last night figuring out what an object is. An object is essentially a hash-like thing that can contain either data or functions. It sounds pretty simple, but that ability to save a function in a hash has some interesting possibilities. It is the reason that frameworks like jQuery have been able to transform a language with only 5 basic data types into an easy to use DOM navigation tool. It is also why a project like Red can make javascript write like Ruby. It is a very flexible language, maybe too flexible. We all need a little structure and JavaScript provides almost none. I want to note here that the thing that super-productive frameworks like Ruby on Rails give us is not ultimate freedom, but the opposite, a well-structured and well-conventioned to do common tasks super fast.

So, to sum it up, JavaScript is more powerful than I have ever given it credit for, and also without very much structure or convention on which to leap into high-productivity mode. The thing it has going for it, as a server-side language, is that it is well known and accessible. People have been using it in browsers since 1995. That won’t mean that javascript experts will be able to jump in and program the server once the groundwork has been set. The fact is that the server is a different place that the browser with different concerns. The bulk of what a server-side developer learns is not a specific language, but the various mechanisms for make server processes and applications. So, this strikes me as a false reason.

I do have to admit though that I am driven by a utopic surge when I encounter a project like CouchDB that glimmers at the possibility of ‘One language to rule them all’. I really wish that language were Ruby. I am not going to hold my breath waiting for every browser manufacturer to get on board with that. With new eyes on javascript though, it is easy to imagine it becoming a friendly and expressive language with lots of metaprogramming possibilities.

Hurdles & Possibilities

There is a lot of difficulty making server-side javascript easy. The most pressing problem is that the language is really minimal. As I already alluded, Javascript was made to be contained, with most standard language features dependent on the JavaScript container.

Embedding

Lots of languages have made the leap to embed javascript. The most notable case in Rhino, JavaScript inside the Java Virtual Machine. Many other languages have made that leap with varying degrees of success. John Resig sums it up really well in this article. These attempts fail though to capture the essence of server-side javascript desire: simplicity and the lack of dependence on other languages.

Engines

Browser developers have been forward thinking to a land where server-side javascript is possible. As such, they have been making their JavaScript engines open source and embeddable in C++, the lingua franca of the server. That means an easier time going straight into language interpreter land. In some places that is happening. Here are details on a few of the front-runners:

Right now Chrome’s V8 provides the standalone usage that has people most excited. That excitement of course means greater community investment in a server-side eco-system.

Standardization, Standardization, Standardization!

The group ServerJS has started the hard work of trying to wrangle these efforts for a broader JavaScript. Since the javascript core doesn’t specify any expectations for I/O or anything else server related, the same free-for-all spirit that invaded the browsers. Hopefully they enforce some reason.

An attempt at middleware standardization has also been made with the project Jack. It is created by, Tom Robinson the man behind Capuccino. It was inspired by Ruby’s and Python’s Rack and Twisted middleware implementations.

More …

It only just becoming possible to think about javascript on the server side in a serious way. I expect to write several more articles on this, so visit my server-side index for details.