Server-Side Javascript: Back With a Vengeance
Last month was Javascript season in Europe, with two conferences dedicated to the language that powers interactive web applications, and a third, which featured it heavily. If a common theme emerged, it was the buzz about Javascript leaping out of the browser to serve other domains, and the noise has only become louder in the aftermath.
Of all the applications outside the browser, server-side Javascript is the most alluring for reasons described in this post. An idea that would have had you laughed out of the room a few years ago is edging towards reality.
Javascript outside the browser? Some of the applications are graphical user-interface platforms similar to the browser, e.g. Adobe Air, television sets. With other applications, there's not even a graphical user interface. For example, some have suggested using it as a general-purpose Unix scripting language.
This guest post was written by Michael Mahemoff, who works at Osmosoft as lead web developer and blogs regularly for Ajaxian and on his his personal blog, Software As She's Developed. You can follow him on Twitter.
The Perfect Storm
Server-side Javascript isn't a new phenomenon; Netscape stuck Javascript in the server way back in 1996, right after they introduced it to the world as a browser technology. Interest soon waned, and the language was confined to the browser for the most part. Even there, it didn't get a whole lot of respect and was frequently dismissed as a hack language capable of no more than annoying alert boxes and gratuitous ticker tape animations.
But suddenly, serious web-based applications started sprouting up. GMail, Google Maps, and JotSpot (kind of a Google Docs predecessor) were all running inside the browser. They weren't supported by Flash, nor ActiveX, but Javascript manipulating the browser's Document Object Model (DOM). The term "Ajax" was coined to describe these applications, and a community flourished. A few years on, Javascript has become the world's most popular programming language by some accounts. Not so surprising when you consider its special status as the standard language shipped with all major browsers. It's the web's lingua franca. While most web developers have a favourite, primary, language for server-side work, they converge on Javascript when it comes to the browser. Javascript today can be compared to the English language: it's arguably the most popular language as long as you count basic competency, not just outright fluency.
Given that you're already using it in the browser, why not stick it in the server too? One language all the way down makes it easier for a single programmer to work on either side of the wire; there's less of a mental shift. For project managers, the trend would make it easier to move developer resources between the front end and the back end if a common language is used on both. Many in the developer community now recognize Javascript as a respectable language, with understood patterns for effective use. In fact, many of Javascript's negatives were a case of misdiagnosis: the problem was really the browsers' DOM (Document Object Model) APIs, not the language itself. Take those out of the equation and you're left with a solid language capable of tackling diverse problems.
There's also a promising reuse story for this "dual-side Javascript" scenario. Take form validation for example. Right now, it's common to write the same logic in two different languages. In Javascript, you write a validator to give the user immediate feedback inside the browser, and in a language like PHP, you write a validator to ensure data integrity once the form data has been uploaded to the server. But once you switch to Javascript on the server, you just need to write a single validation routine at both ends. Under some styles of development, you can also arrange for a function in the browser to directly call another function inside the server; the code is smaller and simpler to write, not being bogged down in the technical details of transferring data across the network.
Javascript performance has also moved forward in leaps and bounds, thanks to browser competition. Firefox's Javascript engine, Spidermonkey, increased in speed by a factor of 20-40x. Safari's underlying engine - Squirrelfish, aka Nitro - posted similarly impressive gains (see chart below), and Google Chrome came on the scene last year along with its highly optimized V8 Javascript engine, a very real contender in the "fastest Javasript engine" stakes.
Server-side Javascript also dovetails nicely the new breed of NOSQL databases. Being web-native, these databases tend to communicate in HTTP, and in some cases JSON (JavaScript Object Notation) is the message format. Javascript libraries already include support for exactly that kind of interaction and programmers are familiar with them. Some of these NOSQL systems go beyond data persistence and into the zone of full-fledged Javascript application environments.
Next page:Towards A Mature Server-Side Ecology
Share
Facebook
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
The usage of server-side js is quite confusing to me, actually.
@kurs, it really isn't that confusing. here are two examples (two i happen to use pretty frequently)
rhino: http://www.mozilla.org/rhino/, a javascript engine on top of java to do server-side javascript (great for adding a scripting feature into java applications)
couchdb: http://couchdb.apache.org (one of the no-sql databases, uses javascript as its query language, its really awesome)
MS did have jscript and asp classic back before the .net days and it can still be used now but not sure you would want too.
The world needs one of the big players to invest in it before it gets taken seriously. Maybe Mozilla could do it.
other popular tech like PHP and ROR where made popular by their ease of use and their low cost to host.
The main problem I see for any new web dev platform is its a crowded market and developers already have the tools and communities based around them.
I'm glad no one brought up BroadVision. Oh, wait, I just did.
Agree with kurs, yeah...this hurts my head.
If they can make it as simple as using jQuery, I wouldn't fear this unknown quite so much.
It's useless to hope that this just goes away and we can use our current language/tech of choice. 10 years from now, the stuff we'll be doing will make the stuff we're doing today seem like the stuff from 10 years ago. That is, of course, if Google hasn't obviated the need for anybody else to do anything on the web except for blink a picture with their implant cam and think a message and a URL to tell the world where it can be microwaved to their frontal lobes.
Cheers,
Byron
Server-side Java Scripting, is really difficult. I was working on a project on the same and I was completely confused. Didn't work good for me.
I started following the Node and CommonJS Google Groups recently and am very impressed with the energy going on behind both efforts. There are some really smart people making sound decisions about how to structure the projects. I think server-side JavaScript has a bright future, but there is some evolution that naturally has to take place before it becomes commonplace.
Posted by: segdeha.com
|
December 17, 2009 10:50 PM
In the 21st century, application development really shouldn't require anything but the bare minimum of server-side programming: just enough to fetch, validate and save data. Most of that stuff people currently spend time programming (in whatever language) can and should be automated. eg http://www.mgateway.com/ewdDemo.html for an example of what I mean.
I think the author forgot to mention one important server-side JavaScript app - The Opera browser.
Opera Unite, which is essentially a web/application server in Opera, uses JavaScript as its scripting language. This could lead to more momentum on server-side JS, as Unite has a relatively large user-base already - most Opera users update frequently.
While it's not a solution for hosting big websites, it does do a very impressive job of allowing people to share files, stream audio, or even play online games with each other, with the server being their own PC.
Prototypal inheritance is nice. So is lambda programming. Oh - and so is evented, non-blocking I/O.
node.js === WIN!
http://blip.tv/file/2899135
Another solution for Server Side JavaScript is AppEngineJS:
www.appenginejs.org
based on Narwhal/CommonJS.
I wonder if anyone else remembers PowerDynamo?
http://www.sybase.com/detail?id=44609
Server-side JavaScript way before its time.
Nice post !
You missed the Wakanda SSJS Project presented at the Ajax Experience and the JSConf.eu 2009 ;-)
It is providing most of the technologies you quoted :
- SquirrelFish Extreme engine
- some CommonJS API (like Module),
- a native JavaScript database (NoSQL)
- a REST Data Services in JSON format,
- JSON-RPC server & client
But true that it's not yet downloadable
(coming for 1st quarter 2010... )
http://www.wakandasoftware.com
To go along with Darren... Back around 2000, I coded JScript in classic ASP to great effect. At the time, it was fun to try something 'different'. I was delighted to discover its 'prototype' object along with other dynamic and object-oriented(ish) features. We eventually had it handling a data access layer in a very generic/dynamic manner. Not sure something like that is even possible in VBScript. Pity it didn't catch on, but with very few code examples available (relative to vbscript) it's not surprising.
Arguing that Javascript on the server side is a good choice because the language is widely used in the browser, is phallic. We developers don't have the option of which language we would like to use client-side. Or we use Javascript or we use nothing [that is as available as Javascript is].
The server side, on the other hand, give us that choice. Static or dynamic, compiled or interpreted, etc etc. I once read that Javascript is Scheme done wrong. It is a language similar to many others and to no other at the same time, with a name that suggests resemblance with Java, but which only shares some keywords.
But then, there's market for everything.
I agree that a standard API is needed. Personally, I don't want to have to keep up with several different forks or we'll be back to the JavaScript vs. ECMAScript days.
As far as server-side interpreters, is Rhino pretty much the big dog or are their other alternatives worth looking into at this time?
I've been using Mozilla Rhino on top of a servlet by Java Jetty for quite a while now. It's been wonderful to work with.
* Much like the post says: We now only deal with one language for both server and client side. JavaScript isn't a bad language choice, though it does feel limited by the standards consortium (want: Implicit return values, Ruby-style "method_missing", some others)
* We originally developed our sites on Ruby on Rails. Even with a mongrel cluster on our server (we have a slice on slicehost.com), we achieved an output of 20 dynamically generated pages per second. Our Jetty+Rhino server serves 100 pages per second using the resources of 2 RoR instances. (Java's still a memory hog, yes)
* It has the "all in memory" benefit of RoR. If you have a "var adder = 0;" and every access to a page does "adder += 1;", then it'll keep going up.
* Using Rhino's "Scopes", we're able to run multiple sites in their own javascript scopes within the same Java jetty service. This means javascript running within site A can't access site B or the "parent" process (which manages all the sites). It's comparable to a JS version of Google App Engine. (I currently have 11 sites running in a single instance)
* Thanks to Rhino's Java Connector - All of Java's libraries are available. (Though we usually make JS-like interfaces for them). We have a wonderfully easy SQL API, Sockets, even an implementation of XMLHttpRequest.
Cons:
* When a code fault happens, Rhino isn't as clear with the debug as we'd like it to be. "Exception with line 0 in " - But they're working on it.
* The libraries available for java typically seem to be more annoying to use than, say, those used by RoR.
* No way to determine total memory use of a single scope. If this was doable, I'd make a JS-on-Rhino version of Google Apps and sell or give out scopes for use.
....
I've shared it with a few people outside of my small team who quite like (and now use) it, and wouldn't mind open sourcing it, but I built it to use, not to manage as an OS project :D.
One serious problem has not been mentioned (unless I missed it!): the existing JS libraries all presume a DOM .. a window element.
I think all the popular libraries will have to be refactored into two parts: a base layer w/o DOM, and a browser layer built on top of it, using the DOM. And possibly grow a third part: the server-side.
Some libraries work nicely on both sides: templates for example can work both on both sides nicely.
Anyway, w/o tricks like env.js, its not easy to run jQuery on the server. Yet.
Jaxer, although now unsupported by aptana, has serverside dom and plenty of examples showing things like building dom serverside with jquery instead of templating engine.
It'd be nice if opera picked up the 'js on the server with a DOM' as none of the commonJS environments are doing much around that (env.js is a very shallow implementation, doesn't give you a serverside canvas object to build graphics with, for example)
there is good stuff coming. for sure.
Another project your forgot to talk about is APE (http://www.ape-project.org/). A Comet server powered by SSJS with a full non-blocking I/O API ;)
Actually, WebCrossing has had server side JS since about 1998 when it embedded the actual ECMAScript source code into its base application. It is still running and available.
To reply to Owen about the DOM requirement of JS libraries, I must say that it's true lot of famous libraries where made upon the assumption they only need to work in Browser environments..
But things are changing, since the last JavaScript conference talked about SSJS, frameworks like qooxdoo, and ajax.org are working to be usabale into CommonJS server-side environments.
There is also small but very useful JavaScript libraries which doesn't need the DOM like JSON, JSONPath, XML for Script, or JavaScrypt.
Some High level frameworks like YUI, Dojo, or ExtJS, are so modularized that some of there components should be easily made Server Side compliant (date manipulation, language utils, datasources...)
It is one thing to use an inefficient language and let the client pay for it (requiring more power/performance for processing). It is quite another thing to use an inefficient language on the server and pay for it yourself (with higher CPU/RAM requirements for purchasing host, or lower efficiency for data center, or higher cost/work with cloud services). If cloud computing picks up, people will care more about efficient because they have to pay for CPU cycles. Today, they don't for client side CPU cycles.
Re: Owen and Alexandre:
Dojo has had support for non DOM based environments since Dojo 0.1.0 was released.... in fact it had support (back then -- which was early 2005 IIRC) for the adobesvg, browser, jsc, rhino, spidermonkey, svg and wsh (yes windows script host) environments.
-Karl
GLUEscript (formely known as wxJavaScript) makes it possible to use JavaScript on the server and to create desktop applications (with wxWidgets). GLUEscript tries to turn JavaScript into a general purpose language ...
Re: Mehrdad
JavaScript engines have been highly optimized last years and if you compare to other technologies used on server-side to provide web applications (like PHP, Java, or ruby), you'll see that JavaScript can potentially beat them in performances.
Here's an interesting benchmark provided by Sitepoint benchmarcking persevere (based on rhino, so with an additionnal Java layer) vs PHP :
http://www.sitepen.com/blog/2009/04/20/javascriptdb-perseveres-new-high-performance-storage-engine/
Please note also that JavaScript starts using bytecode caching and compilers (cf SFX and v8)
The server had been using PHP4 since the code update, now it's using php5. Let me know if this fixed the preferences problems some of you have been having. And everyone here at the project wishes everyone a happy holidays and new year!
I will definitely spread the word, my friends who are more into this thing would love this, thanks for the post.
Why does client and server have to use the same programming language? it is not as if they are in the same address space, why are JS on server a good thing in the first place?
I wonder if it would be possible to create an implementation of server-side JS that's similar to Python. Sort of a layer over C++ code that can plugged into a JIT.
I'm generally turned off by attempts at making one language serve every possible role but the thought of applying JS's approach to objects to server side problems is intriguing to me.