What Server Side JavaScript needs

Server side JavaScript technology has been around for a long time. Netscape offered server side JavaScript in their server software back in 1996, and Helma has existed for a number of years as well. But, server side development has changed a lot over the past few years.

Aptana’s Jaxer gives an innovative view of how you can leverage a JavaScript environment running on both sides of the wire (client and server). Very convenient communication and the ability to easily share code between client and server are big benefits of running JavaScript on the server.

Jaxer and Helma are interesting projects, to be sure (and there are many others!). But what I see missing from JavaScript on the server is not interesting projects, but rather a useful ecosystem. People working in Python like to talk about the fragmentation of web frameworks and whatnot, but that’s nothing compared to the fragmentation of JavaScript.

For example, JavaScript needs a cross-interpreter standard library. Thankfully, some amount of standard library exists (the part inherited from the browsers). So, you get regular expressions and dates. But, what about files and directories? Why can’t the same API be made to work in Rhino, Spidermonkey, V8 and JSCore?

A handful of standard interfaces. Connecting to a database and running queries is a well understood and common problem. In Rhino, you get to use JDBC. But, JavaScript really should have its own cross-interpreter standard like Python’s DBAPI. It should also be possible to take a webapp that was originally deployed behind an Apache module running Spidermonkey and then put it behind Jetty thanks to a standard web server/web app interface.

JavaScript needs a standard way to include other modules and for those modules to live in discreet namespaces. There are easy ways to do namespaces, but there’s no standard programmatic way to load a module (once!). This is really important, because server side apps can include a lot of code and will likely mix and match parts that meet those standard interfaces.

There needs to be a way to package up code for deployment and distribution and further to install packages. Linux people will correctly point out that they can just type “apt get” (or yum, or whatever) and their work is done. But there are a lot of people using Macs and Windows who need a convenient way to get their development environments set up and to package up the code they write for deployment and for other people to use.

Part of the distribution and installation problem is a package repository. I don’t know if JSAN is the answer there, but I do know that an easy way to install a package and its dependencies makes a huge difference in how many libraries people will likely pull together in their apps.

And, on top of all of this goodness, we’d get template engines, object relational mappers, middleware, packaged apps, etc. In fact, many of those things already exist. But, the problem is that they have no common basis to sit on. And that’s what prevents an ecosystem from growing.

If you search the Python Package Index for WSGI (the Python standard for connecting webapps with web servers), you’ll find 180 packages today… servers, middleware, full blown applications. And those are just the packages that have “WSGI” in their listings. That’s what an ecosystem looks like. And Java has one, and Ruby has one, and JavaScript needs one.

It’s also worth noting that many of those WSGI components can run unchanged on CPython, Jython and IronPython, thanks to a common standard library. JavaScript has a collection of implementations in C, as well as Java and .Net implementations and there just needs to be a little agreement on some interfaces and such. Libraries that run in all of those places can attract more users and, hopefully, more committers to help the libraries grow.

What I’m describing here is not a technical problem. It’s a matter of people getting together and making a decision to step forward and start building up something bigger and cooler together.

To that end, I’ve set up a new ServerJS group in hopes of getting the interested parties talking and maybe even to get us together face-to-face to produce some code and settle on some interfaces. There’s a tremendous collection of JavaScript code out there already, and let’s see if we can make all of that code that much more valuable.

In the web developer tools group at Mozilla, we have a wide open charter to help software developers make the best use of the open web. Doing our bit to help the server side JavaScript community grow and flourish can certainly be a part of that.

(Before someone says “why not just use Ruby/Python/Java/C#?” let me just say that that is an entirely different question and I won’t address that in this post.)

Update: The group is now called CommonJS.

19 thoughts on “What Server Side JavaScript needs”

  1. You’ve hit a lot of the key points here, though I’d just say these are really general JavaScript issues, not related to the server at all. I’m happy to see anyone talking about this stuff, for any environment though, so … see you on the group.

  2. This is basically true. One nitpick: The date and regex stuff is in the ECMAScript specification. It isn’t part of any library, and the browsers have it because it’s part of the spec. The browsers primary addition is the DOM API.

  3. Here’s a killer feature that would open the door for a lot of good things: a simple way to do a dlopen and call C functions directly in Javascript. It doesn’t have to be automagic and figure things out like argument type conversion or memory managemnt, but it should make it possible (and not even necessarily easy) to do those things directly from Javascript.
    That way, someone just has to program — in pure JS — the glue code and everything becomes possible, because the hardest part of making C extensions to a scripting language is simply linking / make’ing and so on and so forth.
    Just give me a way to dlopen, handle native C types (even though opaque objects) and call C functions, and I can start hacking w/o having to learn much about the JS interpreter’s innards.

  4. You have a good point here. Helma has always benefited from the huge quantity of java libraries out there, which can be use quite comfortably and naturally through Rhino’s LiveConnect. I still see that as a major advantage of any Java based JS engine over those written in C or C++ on the server side.

    Of course, the problem with JavaScript is that it was _conceived_ as an embedded language, and that any features that would have allowed for a ‘ecosystem’ to grow around it (such as module support) were ommitted deliberately. While this is a great feature for some (see Havoc Pennington’s blog entry, for instance), it’s a real problem for JavaScript as a fully grown language.

    In Helma NG I implemented a module system that gives each module its own scope, and it really opens the language up.

  5. You describe the needs very well.

    Ejscript is early (0.9.X) but it has many of the features you are describing. It is currently stand-alone as an interpreter, but an apache module is almost complete.

    It implements Javascript plus a well defined module scheme and extensive library with SQLite, ORM, File I/O, Sockets, HTTP, E4X/XML and other APIs in the library. It also has a Rails like web framework.

    It is early, but moving fast and will transition to 1.0 sometime late this quarter.

  6. Dear Sir:

    I am looking for a web host that supports server side javascript.
    I program in client side javascript & html. I need to use server side
    language so that I can access a data base.

    I hope that you can recommend one/several.

    Please respond at your earliest convenience.

    Thank you,

  7. What you have talked about there is indeed one of the biggest problems with JavaScript. However, there are many other problems, for example the language itself is based upon an outdated model developed almost 12 years ago and the language itself has many flaws.

    I also noticed you talked about the StandardLibrary there, indeed, Cross-Interpreter compatibility is probably the biggest issue with it, so on that note I implemented as much of the StandardLibrary as possible using JavaScript itself, that way a simple or old interpreter will have a minimum amount of problems.


    On the issue of a standard repository, I do hope that JSAN is the answer to that problem. As for a “standard way to include other modules” me and others have been working hard on that and I do not think it is going to be resolved anytime soon. One of the biggest issues is how do you deal with HTTP requests?

  8. @jhuni: The effort that I introduced here has come a long way since this posting. More announcements are pending, but CommonJS has really covered quite a bit of ground and has several implementations (running on Rhino, SpiderMonkey, v8 and JavaScriptCore) that are tracking the standard-in-progress.

Comments are closed.