Initial Thoughts on Server-Side JavaScript
++++++++++++++++++++++++++++++++++++++++++
:Posted: 2009-08-21 16:09
:Tags: JavaScript, Hosting
:Headline: A brief survey of the current state of server side JavaScript
and how JavaScript has affected my coding style.
As many of you will know I've been very keen on JavaScript ever since reading
Dogulas Crokford's book "JavaScript The Good Parts". Aside from teaching me that
JavScript is actually a very useful language it has also taught me the huge
benefits to be gained from knowing the correct subsets of features to actually
use. In fact I've been applying that principle to much of my Python code, avoiding
decorators, the use of the ``**`` operator, anything that uses any of Python's
more clever features etc. I've also been applying the principle to library
design and have created what I hope is a new web micro-framework architecture
and supporting libraries which I think are much more promising than the others
available in the Python world today. More on that once it is finished.
This post was supposed to be about server-side JavaScript though. As a
framework developer I'm always looking for how to make it easier for other
users to write code. At the moment JavaScript is ubiquitous on the client side
so one way to make the life of a web developer easier is to make it available
on the server side too and share libraries between the two. Hence my interest.
Here are some notes on what I've learned about the Java ecosystem so far:
* `GWT `_ statically analyses Java code to
produce the JavaScript but is
effectively just a Java GUI toolkit, which in hosted mode runs a Java GUI
application for debugging and in web mode compiles to very efficient JavaScript
to run online. Not all Google services use it though. It is also no use to
people using Scala, Jython etc because it doesn't analyse Java classes, it
analyses Java itself. Also, there's a bug which means it doesn't work
properly on 64-bit dev platforms without some hacking. Dissapointed. Dismissed.
* `Rhino `_ is totally brilliant, stable, well
documented and effective, I'd encourage you to use it to see just how easy it
is. To use Java classes you just use them, no importing, no mapping to
JavaScript, they just work, brilliant. I spent the first hour trying to use
Java classes without realising you can just write ``var a = new java.whatever.you.Want()``.
This gives you full access to the entire Java infrastructure from JavaScript.
* Rhino can create ``.class`` files directly from JavaScript.
* Helma 1 and 2 are effectively Java frameworks which use Rhino to expose
JavaScript objects. `Helma NG `_ is
written mainly in JavaScript so is much more hackable. It is slightly slower
but a much nicer concept. One to keep an eye on.
* `ServerJS `_ is a group set up by
`Kevin Dangoor `_ (someone I've only met once
but have a lot of respect for) to define a standard for importing
JavaScript modules, the latest draft is implemented in Helma NG.
* `AppJet `_ is a small framework written
in Scala which uses Rhino to allow you to write JavaScript code. It looked
promising but is now not supported.
* The Java standard library is far more complex than it needs to be I needed 9
lines of Java-like code just to run an exec() command to run an external C
program from JavaScript running Rhino.
* `Jaxer `_ uses ScriptMonkey to embed the whole of Mozilla
into a server-side framework so that you can run pages server side before
they are sent client side it is open source but I get the impression its a
"we're a company, oh and we provide some source code" way, it doesn't seem
like they want to build a large open source community.
* `Env-JS `_ is a
project to create a browser environment entirely in JavaScript so that you
can do a similar thing to Jaxer but without needing to embed Mozilla. It is
slow and at the time of writing contains a bug that meant I couldn't get it
to work with Rhino.
* Alternatively, Cobra from the Lobo project looksinteresting as an HTML parser
which could be used to do just the DOM part (we don't need the other parts
server side anyway). There is also a MozillaParser Java project to use
Mozilla as of Firefox 2 to parse an HTML page, executing scripts as it goes,
and this could be used too.
* Parsing an XML file in Java to pass to a Document object for DOM manipulation
is really hard because it always tries to get the schema, but the W3C server
returns a 503. You therefore need to set up XML catalogs. I haven't done this
yet. Surely something like this should work:
::
factory = javax.xml.parsers.DocumentBuilderFactory.newInstance();
factory.setValidating(false);
factory.setExpandEntityReferences(false);
filename = new java.io.File("index.html")
doc = factory.newDocumentBuilder().parse(filename);
* I still can't get V8 to compile on 64bit Ubuntu. Still some more work needed
before that looks viable.
* `JSext `_ looked very promising but doesn't seem
to have developed much since August last year. Is it still active?
After spending some time looking at all this I turned back to Python and was
pleased to see the `python-spidermonkey
`_ bridge being actively
developed. I gave it a quick test and seems to work absolutely brilliantly. A
quick benchmark of a Python web app where the actual response is generated in
JavaScript rather than Python shows that using Python and JavaScript is about
half as fast as just using Python on its own. I suppose that is to be expected.
So far it is looking like my future interactions with server-side JavaScript
are likely to involve complex framework code being written in Python and
exposing simple objects for use from JavaScript. That way client side
developers get all of the benefits of being able to write 90% of server-side
code whilst server-side developers can still program in an accessible language
like Python.