By Andrew Tetlaw

Server-side JavaScript Will Be as Common as PHP

By Andrew Tetlaw

Reading through the comments on Craig Buckler’s blog post, Will Server-side JavaScript ever catch on? confirms what Douglas Crockford wrote about JavaScript: it’s been typecast. A lot of people can only see it in context of the browser. A big part of this is due to the confusion between the language and the browser DOM. The DOM interface is actually where most JavaScript programmers spend their time.

It also confirms another fact: a lot of people hate JavaScript. I’m confident though — for programmers who appreciate JavaScript’s finer features and can accept its rougher parts — that the news JavaScript is moving server-side is unsurprising and probably welcome. And I’m certain that this is only the beginning.


So where can JavaScript be found server-side right now?

Jaxer is a JavaScript web application framework and server. The server-side API is as capable as any, including access to databases, files, and network sockets. There’s a blurring of the boundary between server-side and client-side scripting; for example, server-side scripts can manipulate the web page DOM.

Scripts are embedded ASP style into your HTML:

<p id="msg"></p>
<script runat="server">
  var nme = document.createTextNode(
      "Hello my name is Jaxer.");
  var para = document.getElementById("name");

The runat attribute can be server, both, or server-proxy. If set to server, the script is evaluated before the page is sent to the browser. If not set the scripts are executed client-side. If set to server-proxy, then the functions can be called from a client-side script by name, but are proxied, via Ajax, to the server-side equivalent.

Helma is another web application framework that uses JavaScript for server-side scripting. Helma has a templating system, which means it avoids mixing server-side and client-side JavaScript code. You instead write actions in JavaScript, which then render templates, injecting data into the rendering process. Each HTTP request triggers a configured action.

Here’s an example of a template or skin in Helma jargon, named ‘hello’:

<p>Hello, my name is <% %>.</p>

And the action that renders it: = 'Helma';

There are many more examples of server-side JavaScript as the Server-Side JavaScript topic on Wikipedia shows. Almost all of them use Rhino or SpiderMonkey to execute the JavaScript.

Is server-side JavaScript a serious proposition?

While implementations of JavaScript on the server are appearing, it’s far from the ubiquity of PHP hosting. A fair comment is that server-side JavaScript is currently bound to the framework in which it resides. As such, JavaScript written in one environment is unlikely to be portable because of the lack of a standard API. It’s a need that’s already been identified and so the work of the ServerJS group has begun. Projects like jslibs also aim to solve this problem.

Lack of hosting services is also an issue, though Jaxer and AppJet provide their own hosting platforms. Helma applications can be hosted with services that support Java. Once the standard library problem is solved I’m sure we’ll see hosting support improve — you’ll be asking your host for "mod_javascript" support.

Finally, JavaScript has more than enough rough parts to make many people nervous about using it server-side. I seriously think ECMAScript 3.1 and ECMAScript Harmony will eventually have that covered.

We’re seeing JavaScript support appear in many platforms, both web and desktop, local and server. Will server-side JavaScript support offered in hosting packages be as common as PHP? I think it’s inevitable.

  • There are pure ECMAScript interpreters (such as Mozilla’s Rhino project) that can be wrapped to execute JS on the server. Rhino, for example is written in Java so any servlet environment can be used to run JavaScript code with it.

    The Cappuccino guys are already building on top of this so that you can use Objective-J on the server… already one-step ahead of the game!

    I agree that we’ll see some uptake in this area over the coming years.

  • @Chris Corbyn, yeah the majority of software on the Wikipedia list I mention above use Rhino, actually Helma does too.

  • Server-side JavaScript has a long way to go before it becomes anywhere near as popular as PHP, but opinion about the language is changing.

    Mind you, I’m always surprised at the number of people who consider JavaScript to be clunky. Arguably, PHP is no better with it’s inconsistent naming, tagged-on OOP, and version discrepancies, but you rarely hear any complaints.

    The perceived problems are mostly due to the environment. Server development uses a single platform whereas client development targets many.

  • Another sitepoint misleading, misguided article name.

  • @NetNerd85, ummm why? I thought that’s exactly what I was talking about. My wrap-up stated exactly the same thought that’s in the title: “Will server-side JavaScript support offered in hosting packages be as common as PHP? I think it’s inevitable.”

  • Shadow Caster

    Judging by what I saw in the Jaxer demo video I must say that it is the future. Currently Ajax is like tying bits of rope together – takes effort, isn’t very good and doesn’t look nice, while server-side Javascript is so easy, straightforward and feels natural.

  • phaenotyp

    Though Jaxer could be faster, we’re considering to use it on a website, that makes heavy use of javascript. So we can write the code only once, instead of doubling the functionality with jsp.
    I’d personally like to see the server-side Javascript spreading!

  • I’m with Craig on this one: It’ll be years before we see this become a serious alternative to RoR, Python, or PHP.

    Without a standard, hosting companies simply wouldn’t know which one to host. Some may go the Media Temple route (offering Django specifically), but that would mean a community as large as Django’s would have to exist.

  • The title is really misleading. There are simply no evidence that server-side JavaScript will be any popular.

    I can also write a language interpreter and make Apache support it and also ask a friend to write an article about that…

  • If it’s as embeddable as PHP, it might have a chance of catching on. Standard ruby and standard perl have not been embeddable, whereas PHP has been, and I think that was one of the early reasons it took off. Granted, the landscape has changed a lot since then, but the base ease of insertion in to pre-existing markup still makes PHP very easy to incorporate in to a project. If SSJS ever gets any traction, embeddability(?) will be one of the contributing factors.

  • Michael

    Maybe people hate it because it’s slow, lacks basic features like actual support for objects or even overflow methods and a variety of other things you would need if you didn’t want your website to suck?


  • I have to agree that the title of the post is annoyingly hyperbolic. The article proves nothing except that it’s possible to run JavaScript on the server side. That is a very weak premise to conclude that ‘JavaScript will be as common as PHP’.

  • Totally uncalled for. If you’re going to say Javascript is going to as popular as php on server deployments, you should bring arguments as to why I would want to use it on my server.

    What advantages can Javascript offer over php? I think php is much more solid and much more robust, and less error-prone.

  • I think php is much more solid and much more robust, and less error-prone

    It’s not true. The only reason it seems that way is because the server environment is more stable and less error-prone than the browser environment. On the server, you’re writing code for one system. On the client, your writing code for an infinite variety of browsers and user set-ups.

    As for the title, remember you’re reading a SitePoint blogs: many of the articles are the author’s opinion. Andrew is voicing his.

  • chrisrivera77

    I don’t believe Server-Side Javascript will take off like the other languages have. I’ve been doing web development for 12 years now, and in that time, I’ve been through Perl, PHP, XML, XSLT, SSI, Classic ASP, etc, and never once have been exposed to using Javascript on the Server-Side. I’ve heard about it in the past with LiveWire, and most recently with a friend of mine who now works for Aptana, but not much else has been made widely publicized.

    Conceptually, the abililty to build a website with just HTML, CSS and Javascript sounds great. One less language to deal with. I would like to see more real world examples, and case studies on Server-Side Javascript before I would invest serious time and energy into it.

    Dealing with one less language is a good compelling reason, but there has to be support for a number of features that many of the other languages offer for me to consider it for real work.

    As for the title, granted many have made comments on it already, but I will agree, the title is a little off. This article feels more like Linux is ready for the desktop about 5-7 years ago.

    I would recommend a follow up article with a more serious analysis as to some of the major players on the market and examples of how they work, their community size, how they address problems better than other languages, and any other compelling reason to start taking Server-Side JavaScript more seriously.

  • Wow, still a whole lot of haters out there who can’t read.

    The title says: “Server-side JavaScript Will Be as Common as PHP”. It doesn’t say anything about being popular. If you don’t like it or can’t wrap your head around what goes on, on the server comapred to what happens on the client, stick with something else.

    BTW: It was quite popular about ten years ago for writing Classic ASP code. I still have some ASP/JScript stuff archived and was part of a JScript/ASP mailing list that was focussed on XML/RSS before RSS feeds were part of the mainstream.

  • dusoft

    server javascript won’t catch up with php because it lacks any serious debugging capabilities. what are the options to immediately stop the script execution, to print anything into the page without having to use clumsy DOM access etc. compare that with exit() or echo ” and you get the point.

  • Hama-san

    I remember using server-side JavaScript years ago when Netscape provided a web server. Does anyone remember LiveWire? We wrote whole web applications – including database connections – in JavaScript. It wasn’t the most fun thing to do and required compiling everything time you made a change to the code. That part was quite painful and drove me off to Perl and PHP3.

    I’d have to try server-side JavaScript using one of the platforms mentioned but for now, I reserve judgement. After LiveWire, I didn’t think anything could get me to go back to JavaScript on the server.

  • sitehatchery

    You’ve explained how to use server-side JavaScript with ASP on a Microsoft server. What can you do with using server-side JavaScript with PHP on an Apache server?

  • David Wilhelm

    I think there are some interesting possibilities with JS server side. It will be much less of a headache not to deal with cross-browser issues. Plus there are tons of people who know it already, so they can easily get write up some server side code without learning a new language. Would be nice if say, Google Apps supported it. You can also port libraries to run on the server, eg. Dojo can work server side in Jaxer. For those who like the elegance and expressiveness of functional programming with javascript, they will not need convincing, but those who hate it – well, they will never be convinced. The main obstacle I see is hosting support, which is why an in-the-cloud solution would be cool, if it does not already exist.

  • Is it really necessary to make JavaScript server-side as a platform? I mean it already exists in classic ASP (JScript) as well as in ASP.NET as JScript.NET (can be used loosely typed or strongly typed) and perhaps in other platforms too. I’m just curious what the benefits are aside from someone saying I built an entire JavaScript server-side platform.

    I mean, you can already make chrome apps in FireFox/Mozilla without JavaScript being server-side (throw in some AJAX requests in any server-side language and you’re all good). I also heard that there is some Linux distro planning to use it to build widgets? (Maybe KDE, can’t remember)

    Anyways those are my incoherent thoughts during a two minute break at work.

    BTW, I love JavaScript. Crockford or the Crockenator as I call him rocks. Props to Mr. Reisig as well.


  • @Craig Buckler: as both a PHP and JavaScript developer I can tell you that PHP is a much more solid and well built language than JavaScript is. Take one look at how JavaScript handles OOP (if you can even call it that) and you know what I mean.

  • At first glance I really dislike the idea of server side javascript. It will just make it trickier for people to grasp the idea of server-side / client-side programming. I was liking the clear separation of front-end / back-end programming languages.

    Though I don’t dismiss the idea entirely.

  • ETbyrne, I think you’re still thinking about JavaScript on the client which does actually have fairly full albeit convoluted syntax. I haven’t quite wrapped my head around JS’ Private methods and variables or its versions of Inheritance but it’s all there if you dig right in there.

    I absolutely love coding PHP but there is no reason why JavaScript on the server can’t be as good or better than PHP. If it is, I don’t expect that I’ll stop coding PHP, ASP, .NET, CFM ROR or anything else that I might be using presently but I will look at the option if it proves a good match for project I am working on.

  • yogomozilla

    To see an excellent example of server-side Javscript in action, take a look at couchdb which combines a standard HTTP interface with Javascript views (via SpiderMonkey) to structure the unstructured data stored in a couchdb database.


  • @awasson: If you change the syntax of server side JavaScript, is it really JavaScript anymore? At that point you might as while just call it something else entirely.

  • Regarding the title: firstly, it’s just my opinion, and I meant it as an answer to the question in the title of Craig’s blog post that I referred to in the beginning.

    Also I think a discussion of the merits of servr-side JS over PHP would be pointless. For one, there’s no comparison possible because there’s no equivalent JS implementation, but also debates about how one language is better than another are often just silly. PHP, Python and Ruby support are all widely available and equally useful — you just pick the one you like the most.

    The point of the post was not to prove that server-side JS is better than PHP, just that it will be as common as PHP i.e. just as available. And to that end I thought it would be much better to show that there are people who want to make it happen, and that the elements required to make JS on the server as common as PHP and already being worked on.

  • @ETbyrne, yes the syntax is maturing, that’s what the ECMAScript standard is all about. After all OOP syntax in PHP changed significantly between v4 and v5. We use the word JavaScript but SSJS will likely be based on the ECMAScript standard.

    Also JS is entirely OOP, it’s just not class-based like the OOP you are used to.

  • colinmcc

    Personally I loathe Javascript, and find it illogical, rough, and frustrating to use. PHP however has been the opposite , to me, both logical and easy to implement and use .

    If JS is to appear in the server side world, I really hope it gets a total rewrite before being inflicted on us.

  • Server Side JavaScript has been around for many years. I myself worked with SSJS over 10 years ago. We ran a Netscape Enterprise web server on a Windows NT box. If SSJS hasn’t caught on by now I just don’t think it ever will.

  • rektide

    The day i can write Dojox.DTL and have it run client side or server side via something like env-js hosted on any javascript runtime compatible with server-js is the day I drop all non-JS web programming environments. Javascript itself is appealing, but being able to write code that can run on either side is what is really provocative. Jaxer’s runat seems very similar to the inline client/server behavior that systems like ASP.NET have, and I’ve never really seen the advantage theres to be had from blurring that line.


    have look at mod_v8

  • @colinmcc, If PHP is your preferred language then stick with it, no one’s forcing you to change. I think you’re grumpy because you don’t like JS but you have no other choice but to use it client side. If it appears server-side it’ll just be an alterative, just like you can choose between PHP, Python and Ruby today.

    Programmers choose whatever language causes the least friction between the idea in their heads and the implementations they create. JavaScript has a lot of fans with programmers who find it expressive enough to reduce the friction.

  • Wernight

    Am I the only one seriously doubting of the title? Isn’t Python, or Ruby, or even Java (not JavaScript) way more likely to be more and more popular for web development?

    There are already plenty of good and very good frameworks like RoR or Django. Both with with languages that programmers love because of their high level making nice code.

    Why isn’t it at popular as PHP? PHP is just on file and you’re already dynamic. It’s copy files and done philosophy. So easy to start that people loved it, even the language is easy (which doesn’t mean good).

    Server-side JS may be new, but it has so many drawbacks compared to all existing frameworks, and what does it have that is better? I don’t see there is progress here. At most a unified scripting language for client and server side.

  • @Wernight, actually there are a lot of grumbles about the title!

    Re: languages, you know I read the same thing when Ruby was first released years ago. People asked “Why do we need another scripting language?”. If a language has new expressive power, then people will start using it.

    It’s taken a while but people are finally starting to understand JavaScript and what it can do.

  • I think the primary reason that server-side JS is not used on the server is because many developers misunderstand and underestimate the language. (It’s fully OOP – even basic types such as strings are objects – but the lack of ‘class’ confuses everyone at first.)

    It’s only within the past few years that developers have rediscovered the power of JS. Creating a new server-side language takes time so a number of engines are only just starting to appear.

    The main benefit is syntax. Developers frequently switch between PHP and JS: I’m forever calling methods with -> in JS and . in PHP. It would also be possible to use the same code in both places.

    As for any confusion arising from using the same language in both places, it’s obvious that there’s plenty of confusion already! I don’t think it’ll make it any worse.

  • CF Junkie

    Just wondering: why is this post filed under ‘ColdFusion’?

  • HoyaSaxa93

    Funny most server-side languages, Java, C#, VB.NET, Ruby, seek (or sought) to add functionality already in Javascript… OO, Serialization, function pointers. With mature JS frameworks like JQuery on the server-side and you’d add some power with little effort on your part.

  • @Craig Buckler

    I think the primary reason that server-side JS is not used on the server is because many developers misunderstand and underestimate the language. (It’s fully OOP – even basic types such as strings are objects – but the lack of ‘class’ confuses everyone at first.)

    Nope, there are simply enough languages that do server-side job: PHP, Pyhton, Ruby, C#/VB.NET

    The main benefit is syntax. Developers frequently switch between PHP and JS: I’m forever calling methods with -> in JS and . in PHP. It would also be possible to use the same code in both places.

    Wrong. First of all, people choose languages not because of syntax, but because of its area of application, its features and its libraries. I don’t love the JavaScript syntax in terms of OOP, but I can tolerate, since there is simply no other solution for browser scripting.

    At the same time, if you port JavaScript to server-side, you still have to write a lot of libraries, for such essential tasks as:

    – Session handling
    – Database interaction
    – File system interaction
    – Image manipulations

    They are just fundamental, but I may also want to have built-in libraries for:

    – Caching
    – ORM
    – Authentication and autorization
    – Input validation

    ASP.NET has it all by default. In PHP you can Zend Framework that does also posses these features.

    But JavaScript simply lack it! One has to write it all in order to make it work on the server.

  • Nope, there are simply enough languages that do server-side job

    Well that’s just silly, are you really saying that there’s no need from now to eternity for any new languages?

    First of all, people choose languages not because of syntax

    I disagree with that too. I think people tend to favour one language over another precisely because they like the syntax; they’ll even forgive missing language features. A lot of programmers just like the syntax that they can express themselves with the best.

    One has to write it all in order to make it work on the server.

    And yet, we see products using SSJS. I already stated in the post that this is lacking from SSJS, and is already being addressed in several projects. It won’t be this way forever.

  • thatspoppycock

    There’s actually an Apache plug-in that illustrates this concept. I’m pretty sure it was just a proof of concept-type deal, but I can’t say that for sure.

  • I see some potential for this to catch on. Beginners learn HTML. Then, they learn some JavaScript. Next, they pick up a server side language (PHP, etc.) when they need to submit a form. I think many would never make that jump from JavaScript to another scripting language if they didn’t have to. I seriously think this has huge potential for that reason alone.

  • mmj

    I really like the concept of Javascript server-side, or essentially, Javascript anywhere outside of a browser. I think a lot of people have pre-conceived ideas about Javascript’s limitations, but I think these are more browser model limitations than limitations of the language itself.

    Javascript is a pretty good language in general, and I think it’s wasted as an in-browser client-side language. I’ve love to see it used for other stuff (more so than it already is). It could be the next Python.

  • Oscar

    When I started to scripting for internet (exactly 3 years ago), the key of my success was my SQL expertise because then I used to be a really good VisualFox developer. Those years were the boom of javascript frameworks and Ajax; so I grow up -as web developer- using javascript everywhere. Actually I pass more time scripting with JS than PHP (well, a great help is how easy is PHP). When I scripting with PHP I use classes only, maybe +90% that classes doing is extract and parse MySQL data. I knew about Jaxer last year, I tried it and I think it’s awesome and really practical, I’m convinced server side javascript will be the next Ajax for the web world (English is not my primary language, so excuse my faults).

  • Anonymous

    It would have been nice to see some evidance that you had done some research before writing this article.
    There have been quite a few products in the past that have used JS as the basic language on server-side, and none have done well – Hyperwave IS/6 is the only one I know of that is still used at all, (and I wish it wasn’t.)

    JavaScript was always intended and designed to be light-weight. Pretty much by definition, a server-side language needs to be really efficient, and using an Object for everything makes that impossible.

    Finally, if there is any need for a new language, it is because that language provides something new that no other language has – in terms of syntax, JS provides nothing that isn’t in Java, so what possible advantage can JS provide?

  • Bob

    I don’t think lack of JavaScript hosting is a serious problem in this day and age. What with Amazon E2, App Jet, and many other services popping up and far cheaper server hosting options than before. Old style web hosting is dying out as most casual web-site owners are flocking to blogging sites or full-fledged hosted content management systems.

    One big advantage with PHP is its absolute laziness. You simply cannot beat file_get_contents(‘bob.txt’). However the PHP.js project is working on converting all these useful PHP functions into JS and they’ve made great progress already.

    One thing Jaxer has wowed me with is the ability to use jQuery to manipulate the current page server side. Having recently discovered php-Query, this makes me very happy.

  • @Anonymous, I don’t think it’s hard to see that JavaScript today is a world away from JavaScript in the past, and the server-side JavaScript platforms that I mentioned are in use today. It’s also a totally different language to Java,so I don’t really understand your point there.

  • spVince

    Do we really need yet another server-side language??
    Why not keep improving the existing ones, so as to include the feature and functions that are needed?

  • ^ It’s not new… JS has been on the server since the first version of ASP. It’s just that as PHP has matured from a PERL script (Personal Home Page), JS hasn’t had much action in the limelight. Not it is gaining momentum and why not?

  • Server-side JS will become popular as web pages start moving offline (HTML5, Google Gears), where client-side Javascript is the only language available. Writing the database access and UI in JS in such a way that it can be run either on the client or on the server will give a nice solution for having one code base. At least in theory!

Get the latest in JavaScript, once a week, for free.