What Server Side JavaScript needs
A few of use are convinced that SSJS is the way of the future, in terms of elegance and simplicity (using just one language for both client and server), etc. However, if we wish that one day JS beat PHP1, there are several conditions.
First of all, I think the main drawback is inertia. PHP is currently the way to go in web development (even though a few still use ASP, CGI, etc.). In order to counter the inertia, any new server side language has to be as good as PHP (not so difficult to do), as easy to learn and have exciting new features.
Python and Perl have been around for quite some time, without becoming dominant, so I guess that they won't in the future.
Some said that RoR was that alternative, and let's face it : it's trendy among Mac geeks using textmate… Not that I have anything against this, but those developers live in another world: RoR has basically several flaws which can't be overcome. First, it doesn't scale2. Second, it doesn't have a C-like syntax3, and this has a psychological impact on devs coming from the PHP world. Third, it's yet another language to learn. Fourth, it didn't play well under Apache until recently. The reason why some guys switched to RoR could be summed up to three points: the MVC model, the Active Record pattern and scaffolding.
All those ideas are nice, but it's not enough for RoR to be the Next Big Language. SSJS is exploding right now, with quite a number of solutions being developed. However, most of those are bloated and are either ports of PHP or RoR to JS. The only one which takes it to another level is Jaxer, which is a nice concept, but is intrinsically unscalable: how can one imagine having hundred thousands instances of DOM trees being manipulated at the same time on the server and being delivered quickly ?
I believe that the JS strength resides not only in the fact that it's usable on the client, but also because it's prototype based. For example, Active Record is something nice for class based object orientation, but I believe that there are much simpler approaches using prototypes.
Nevertheless, unless someone comes up with some revolutionnary features for SSJS, I'm afraid that it'll stay a niche language (on the server).
- This is not a joke [↩]
- For example, Twitter is abandonning RoR, for that reason [↩]
- no curly braces, no semi-colons [↩]
One Response to "What Server Side JavaScript needs"
@ Aptana Jaxer… "how can one imagine having hundred thousands instances of DOM trees being manipulated at the same time on the server and being delivered quickly ?"
… I wanted to clarify, that Jaxer's architecture is not what's perhaps described above. By default Jaxer processes a DOM tree when a page is first served through Jaxer, but Jaxer does not persist the DOM state for that page on the server. DOM state is client-side.
This architecure lets you either natively use Jaxer to generate DOMs to be sent to the browser to be rendered, or, let's you take in a DOM or HTML page generated by another procees (e.g. PHP, RoR, JSP, ASP, CFML, .html etc… whatever…) and manipulate that DOM before it gets sent on to the browser.
-Kevin Hakman (aptana)
Leave a Reply