WARNING: This page is archived and not updated. Please bear in mind any information may be incorrect and any code may not work. Use at your own risk.
James Gardner: Home > Blog > 2009 > Initial Thoughts on Server-Side...

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:

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.

(view source)

James Gardner: Home > Blog > 2009 > Initial Thoughts on Server-Side...