Server-Side Javascript & EJScript

06/30/09

This weekend I woke up from an all night dream-in about server-side javascript interpreters. It wasn’t a nightmare. It was really a dream.

I have been playing around with CouchDB and CouchApp. While I see so much potential in CouchApp, it is so different from traditional web development that it doesn’t fit well into our flexible frameworks, let alone the mindsets that come along with them. CouchApp, the stand-alone, deploy-with-the-data, application framework is an excellent proof of concept product. I am spoiled, however, by real MVC frameworking. All this got me thinking about the state of server-side javascript … in my sleep.

For a long time, I will admit, that the thought of server-side Javascript made me want to heave. It would be sweet to do both client and server side scripting in the same language, but if I had to choose a language, it wouldn’t be Javascript! John Resig has changed that for me. Although javascript still doesn’t have the lovely metaprogramming that I know and love in Ruby, jQuery has made JavaScript pretty sweet.

The real issue with server-side javascript is that the language was made for browsers. It doesn’t have specs for File I/O and other basics that you could expect from a real language. Rhino, the Java Javascript interpreter, fixes that mess by attaching the whole Java language and library to the language core. Resig a couple years ago wrote a env.js script that makes Rhino play nice with jQuery by emulating the browser.

If you want to get up and running with server-side javascript, you can definitely install an entire Java stack, but that seems like a deployment nightmare, and heavy weight solution for a language whose core function have now been distilled into < 400kb!

As I imagine a CouchDB framework that uses just javascript to build the models and controllers, I have jQuery like dreams. On the other hand, I don’t want to be building server-side javascript in C in my spare time.

With all that motivation, I checked out EJScript. EJScript, has so many of the things that I would love to love about a portable javascript implementation. It has a console:

  $> ejs
  ejs-0> print('Hello World!');
  Hello World!
  ejs-0>

It has an MVC web framework, a server binary that will get you up and running on port 4000 in development, without doing an apache configuration.

This all sounds perfect, but alas, I do not like EJScript. My first issue with EJScript was that the binary made some really bad assumptions about my computer’s setup. The assumptions were probably based on a spanking new laptop, and mine is about 9 months old. So, the very latest version of ssl was not there. The binary said it was a successful installation, but alas it did not work. This was a minor annoyance since compiling from source worked great.

So, then curious to see what these models and controllers might look like, I generated an application from the command line using the installed binary: ejsweb. It indeed built an application directory just as it said it would. The directory structure was similar to a RoR application. The differences would be worth noting if I promoting this as a real solution, but I am not. The documentation pretty instantly failed me when I tried to generate a model … and then a scaffold. Although the documentation provided a way of specifying model attributes on the command line, it just didn’t work. In the end I had to generate a resource for a model without attributes. This would be fine. Except not knowing the framework, I expected to learn a lot from how these attributes were built into the model.

The trouble with the generator too is that it was a binary compiled at installation. Unlike RoR’s script/generate files, you can’t jump in to check what is going on, or do a quick bug fix. For me it is important that a framework be created in the language in uses.

At any rate, we can skip straight to the ugly, a model:

  /*
   *  User.es - User Model Class
   */

  public dynamic class User implements Record {

      setup()

      function User(fields: Object = null) {
          constructor(fields)
      }
  }

Gah! Essentially we are writing javascript inside a C++ wrapper. If I wanted to look at C++ all day, I would still be working in C++. I will admit it; I have become a total snob about beautiful code. I expect my language to not pollute the page with internal flags and indicators. I use dynamic languages because I want to skip straight to the business logic and leave setup, accessibility and garbage collection to lower places on the food chain.

The controller was just as bad, and to add insult to my injury, no tests were generated … not even empty test files just waiting for an assertion.

I know this sounds like a pointless bitch session. For the first time though I am wishing that my blog allowed comments, because we need more discussion about what a server side javascript … and its framework should look like. To be clear, people are already working on these problems. A group ServerJS has been set up to create some great language standards. A Rack like server middleware implementation has been created called Jack. John Resig continues to write and explore and amaze. I would still rather be writing in Ruby, but this javascript could be cool too.

©2008-2010 ~ Ruby Ghetto