Will Server-Side JavaScript ever catch on?

By Craig Buckler
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

server-side JavaScriptJavaScript is probably the most widely-used programming language on the planet – nearly every website has a few lines. However, the language is also one of the most misunderstood and often confuses experienced developers: it is not Java, it is not “script”, it does not appear to support Object Orientated Programming, and it can be problematical to get code working in one browser – never mind all of them.

Much of the pain experienced by web developers is rarely caused by JavaScript itself; DOM manipulation, browser quirks and, until recently, a lack of good development tools and debuggers are the biggest causes of complaint. However, the rise of Ajax and Web2.0 led many developers to ‘rediscover’ the language: it may not be perfect, but it is powerful and provides compelling features such as prototypes, first-class functions, closures, and object literals.

Whilst JavaScript engines are available in all but the most basic of web browsers, its use has never become widespread on the web server. There are several server implementations of JavaScript but none could claim to have become mainstream compared to PHP, ASP.NET or even Ruby.

However, server-side JavaScript does offer some tantalizing possibilities:

  • It is one less language to learn and use. Web development typically involves a range of technologies and server-side JavaScript would make the process easier (how many times have you started typing server-side code into JavaScript or vice versa?)
  • The same code could be used on both the client and the server, e.g. form fields could be validated using identical methods.
  • JavaScript libraries such as jQuery would work on the server. Features such as server-side DOM manipulation should also be possible.
  • Web service and Ajax development would be easier, e.g. JSON could be natively handled at either end.
  • Knowledge could be shared between server and client-side web development experts.

Is JavaScript the right language for the server environment? Can projects such as Jaxer succeed? Are you using it now or planning to in a future project? Should more ISPs offer server-side JavaScript within their hosting plans?

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Dean


  • Mark

    The latest version (8.5) of IBM Lotus Notes includes a new feature called XPages. This is an implementation of JSF but development is done using a combination of Server Side / Client Side Javascript.

    So potentially 40% of the top 100 companies could start to use it, once they have upgraded to the latest version.

  • You bet it will!

  • darshoo

    I hope all Hosting provider support Jaxer in their hosting planes , it will make develoeprs life easier , at least me , programme the client and the server and the desktop with JavaScript is adream should come true .

  • zomok.my

    Serious I see no reason for me to drop PHP and pick up server side Javascript, at least not now

  • To me, server side JavaScript actually creates confusion, rather than to eliminate it.

    Why? Well, as a more savvy person, I like to know in which layer I’m executing. Right now, I know that JS is always executed at the client, PHP at the web server, and SQL at the SQL server (often being on the same machine, but not always).

    If JavaScript starts to get executed on the server, I would start not to be completely sure whether the JavaScript runs at the server, the client or both. Yes, I know it can be specified with the runat attribute, but when you have large pieces of code, or many small ones, it starts to get tedious to check out how and where each one runs. When the different layers are clearly delimited, you can easily spot what runs where and when. For example, in the snippet:

    $result = $mysqli->query('SELECT * FROM members');
    while ($row = $result->fetch_assoc()) {
    echo '<li>', $row['username'], ' - ', $row['email'], ''</li>';

    I can clearly see that the client will surely receive <ul></ul>, and thus if I have a problem inside of that, it’s PHP’s fault. If I have JavaScript in a script element, my first thought will be that this is a markup that the client receives. I’d have to take a closer look at the runat attribute, just to make sure it runs at the right place, and then determine if it’s the server’s fault, or the client’s.

    Cold Fusion has a similar problem, for which I don’t find it much attractive. I mean, when I see <*>, that’s client for me. <cf*> isn’t a good enough delimiter. XML namespaces are useful in this regard. <cf:*> would’ve been a good delimiter for Cold Fusion, and more easily destinguishable. After I assign prefixes, I’d easily be able to spot the <cf:*> among the non prefixed client side HTML, and possibly, among other prefixed stuff.

    This reminds me, I’m really awaiting XProc to get implemeneted, especially at server side languages. And as far as validation of forms is concerned, I really hope the XForms module at Mozilla will mature sooner. When it is, we’ll be able to write a single schema, and use XForms to generate an XML which we’ll validate against the schema on both client and server. In combination with good XProc APIs, writing portable complex forms and form processors will become a breeze.

  • Terry

    The issue is that JavaScript isn’t really designed to do a lot of the tasks one may have to do server side like accessing files on the server or interfacing with Excel to create reports,etc. You know the typical things that a business user would want their web application to be able to do. This could be overcome I suppose but the question is at what cost.

  • PhiLho

    I agree that JavaScript isn’t Java, but it is script: it is a language to script the Web pages (at least originally), it is embedded (in the browser), and even interpreted (lot of people use “scripting language” to mean “interpreted language”…).

    While I dislike Sun’s use of “script” for JavaFX (compiled, statically typed, not really embedded, it doesn’t have much of a script language), it is quite appropriate for JS.

  • That is a good point although, generally, client-side JavaScript is best handled in separate files (to the HTML and server-side JS).

    Also, although the actual language would be the same, different server-side methods would be required to output HTML, connect to databases, handle sessions, etc.

  • Yes. Having JS in a separate file is one more edge case which will become especially complicated if you mix client side JavaScript with server side JavaScript. Suppose you need to create a variable for JavaScript on the server (for whatever reason… I’m not saying it’s a good thing to do on the first place). If you use any language other than JavaScript, you can do something like this (in PHP):
    var something = "<?php echo $something ?>";

    Contrast that with what JavaScript inside JavaScript would be:
    var something = "<script runat="server">document.write(something);</script>";
    In this small sample it’s clear in both cases, but if you have large code, you might start to put client side code into server side code or vise versa and never find out you did, leading you to wonder what went wrong. When the languages are diffent, you can at least be sure that the error will be caught by the parser.

    Different APIs are a good point, but that’s also a reason why you’ll eventually pretty much learn a new language. Also a reason why you can get confused (“Argh… this API is only for the server/client”).

  • Kris S

    Ben I agree with you 100% about CF, I did not enjoy working with it much for that reason… I prefer to have code contrast to easily distinguish between regions. On the other hand… server side js is an interesting notion. The only draw back i see with aptana it appears there is a lot of configuration work. It would be nice to see a something similar to ActiveRecord. I was never much a fan of writing sql statements, its a lot of busy work in my opinion.

  • BenyP

    Dudes, I would do anything to get Javascript OUT of the browsers and replace it with anything else! Javascript is the worst language you can use. It’s confusing, complex for nothing, limited and the syntax makes humanely no sense. THIS is the reason why it’s been so “mis-understood” and “underused”. JavaScript is the best example of a language that litteraly sucks but everyone’s stuck with it because it’s so widely spread and nobody else wanted to take of the problem (client side scripting) before.
    Bottom line; Server-side scripting using Javascript is a BIG : NO NO- for me : ) – But that’s my point of view.

  • ZenPsycho

    I’ve been coding serverside javascript for over a year now. It’s great. I highly reccomend it. I’ll never go back to PHP if I can help it.

  • You guys have got to remember that when you talk about JavaScript on the server, it is the language and not necessarily the browser DOM API that is being used. So arguments about not being able to open files are just incorrect. Also the argument about mixing server-side and client-side JavaScript is similarly a red-herring because we’re not talking about templating.

    Apart from Jaxter, JavaScript already powers AppJet, Freebase and CouchDB. And I just found a Wikipedia page with many others.

    JavaScript is wonderfully flexible and I’d love to be using it server-side.

  • Bob Carologees

    couchdb uses json as its data interchange format, completely different to saying it “runs on js”.

    personally i think the idea is laughable but whatever. next up, javascript to power a nasa space shuttle. please, let javascript do what it was intended to do, which is provide behavioural enhancements to user agents.

  • @Bob Carologees, JavaScript is central to CouchDB. Yes it uses JSON as its data storage format, but views use JavaScript functions.

  • I found another one: Persevere. I think it’s a growing trend.

  • ZenPsycho

    You wouldn’t use javascript as a templating language. That’s why I think Jaxer is entirely the wrong approach. It’s just repeating the asp.NET and PHP nonsense of mixing serverside code in with html code.

    helma (the server-side javascript framework I’m using) has a rich templating engine that works very well. There is no confusion at all between what is serverside code and what is client side code. The serverside code just shouldn’t be mixed in with your html at all, it should be in a seperate file. Simple as that, in any language.

  • ZenPsycho

    By the way, if you want to give it a try, go to http://helma.org, download the package, doubleclick “start.bat” or “start.sh”, and then have a look at http://localhost:8080. Following the built in tutorial you can be writing your own application in minutes.

  • Znupi

    I don’t think JavaScript will ever be used on the server side. For one, JavaScript was designed to run in a browser. It’s like saying running PHP on the client side might catch on. It never will. On top of that, people who are just starting to learn web developing are already having difficulties telling the difference between server-side and client-side and actually understanding how the HTTP protocol works. I see lots of forum threads in which people don’t understand why they can’t use some PHP function in a JavaScript script or vice-versa. Imagine how confused these people would be if the server-side and the client-side languages would be the same! Basically, keeping separate things separated is always a good idea.
    And the idea that you would only have to learn one language is nonsense. Only the syntax would be the same, but the language itself would be completely different because of the completely different environment it runs in.

    A bit offtopic, but I wonder why Python isn’t more popular. It may be due to the fact that it’s harder to set up on a development server.

  • Bob Carologees

    Yeh, and it’s pseudo-server side at best because almost all of these tools are powered by something else that provides the “server side” javascript api. I’m not chastising these tools, in fact we were trying to use couchdb here (but scrapped it because it doesn’t scale), just adding a touch of reality to the discussion. Javascript is powerful enough to be used outside of the web browser environment and that has already been proven, but at the same time it WAS intended as a client side language and that is what it does best. I’ve seen some of these JS libraries that let you execute SQL queries from the client side and imo that’s just a horrible and dangerous model.

  • thr

    The amount of misguided comments here is horrible, “not being able to open files” ? That has nothing to do with the language and everything to do with the platform it’s run on, for example.

  • Anonymous

    “Yeh, and it’s pseudo-server side at best because almost all of these tools are powered by something else that provides the “server side” javascript api”

    Name a popular serverside framework whose major libraries aren’t written in C or Java.

  • florin

    JavaScript, in essence, is nothing but a syntax and potentially equal to any other language for that matter. It could just well live on the serverside.

    However, what matters is the way its runtime interacts with the rest of the system.

    The mix of scripted languages within the templating engine, is absolutely horrible however – many serverside developers are shocked to see the “clear” php and html and db access example given above. It’s an absolute puke.

    You must have separation of concerns for all the possible reasons if you want something else than a hack. JavaScript could live rather well on the serverside yet not as Jaxer suggests. Sql inside an html page? You guys, as web developers are spreading bad practice through your service offerings to small business. Easy to implement, ignoring every sensible advise, exposing your customers to security issues, unmaintainable code that cannot scale, etc. but hey, one man saved the world!

    The only acceptable way is to have the html page, as the template, clean of any serverside programming. Hook up your serverside via element attributes and be done with it. Whether developed on the server or in the client, keep all UI related code (if JavaScript) strictly addressing the UI. Better off, place your unobtrusive javascript in external files and you end up with one beautiful environment.

    Now, put JavaScript on the server and let it live on its own strength? Can it?

  • err .jsp


  • i know though.. two different things..

  • Agwego

    Server side Javascript is awesome you can use good old IIS with JScript (Microsoft’s fairly reasonable interpretation of Javascript but who knows if they will keep it inline with current ECMA script standards) The hardest thing about server side javascript is wrapping your head around prototypical inheritance) after that it’s all good. All the heavy lifting for http://www.beabritdifferent.com/ is done with server side JScript.

  • I’ve seen some of these JS libraries that let you execute SQL queries from the client side and imo that’s just a horrible and dangerous model.

    The only acceptable way is to have the html page, as the template, clean of any serverside programming.

    I’ve no idea what either of these points have to do with the topic…

    And as for the argument that JavaScript was designed to run in the browser so it should stay there, I quote from the master himself:

    JavaScript was designed to run in Netscape Navigator. Its success there led to it becoming standard equipment in virtually all web browsers. This has resulted in typecasting. JavaScript is the George Reeves of programming languages. JavaScript is well suited to a large class of non-Web-related applications

    JavaScript: The World’s Most Misunderstood Programming Language

  • I don’t see any reason why Javascript should not be on the server. It’s a language; PHP is a language, Python, Ruby, ect… They are all languages. PHP runs on the desktop and if browsers had an interpreter for it, you could run PHP on the browser just like you can run VBScript in IE.

    Javascript has a lot going for it but most backend coders it seems haven’t taken the time to learn how to use it other than to validate a form or do a slide show. Doesn’t anyone remember coding ASP using Javascript instead of VBScript? I do.

    Great article… It’s something to look into.

  • To the several people who suggested having separate server side files – yes, I agree. I do that too. Still, I may sometime go “off road” for a second, and in such cases, I want some kind of an error. If the language is the same, I may not always get an error. Worse – I may accidently leak server information into the client, and never know I did.

    Also, try to see it from the point of a newbie for a second – they often use a language as an afterthought about something they need. That’s part of the reason why PHP has hit it off. Besides, as said already, newbies are already confused about how HTTP works and what goes where. Heck, I’ve been confused once upon a time myself. Having two different, non-related and non-similar languages certainly helped me understand, though truth be told, I had my “aha” moment when inspecting a page with Fiddler.

    BTW, Kris S, my name is not Ben… nor Boen for that matter. “Boen” is a Bulgarian word for “fighting” (fun fact: I’ve heared that in… I think Belgium… it means “cleaning”).

  • Anonymous

    So javascript on the serverside is a bad idea, because it means confused people, who don’t know what they’re doing, won’t be able to use it professionally?

    I’m not sure this is a great argument. And I really don’t follow the premise of your speech. In helma, it’s excruciatingly clear what code is running where. If you can’t figure that out, I doubt you’d be able to productively get anything else accomplished. That said, I have met at least 2 people- Professional developers that charge money for their work, who did not realise that Java and Javascript are two different languages, and additionally didn’t realize that javascript code runs on the client side, or that there was any difference between running client side code or serverside code. That’s with Java on the serverside.

    So essentially, Yeah I suppose it’s a valid argument. But with people that confused, it’s a valid argument against ANY language that looks remotely like C running on the server side. We should all switch over to using exclusively ruby and python, for fear of confusing the newbies!

  • @Anonymous

    So javascript on the serverside is a bad idea, because it means confused people, who don’t know what they’re doing, won’t be able to use it professionally?

    I’m not sure this is a great argument.

    It’s a valid argument when we talk about “HTML” (error recovery) vs. “XHTML” (draconian error handling), as well with “lose typing” (JavaScript, PHP) vs. “strict typing” (Java, C) and “RSS” (simple, focused) vs. “RDF+RSS” (not so simple, more general) so why not here?

    PHP is a “remotely like C” language, and even newbies know it runs on the server… though not everyone realizes what “runs on the server” implies*. The same goes for Python, Ruby, Cold Fusion, and pretty much any server side language without “Java” or “Script” in its name.

    It doesn’t hold true for Java and JavaScript though. The problem is you can’t tell people in the simplest fashion:
    this language -> this environment
    but rather, you always have to say
    Java != JavaScript
    syntaxof(Java) != syntaxof(JavaScript)
    Java -> server, desktop application
    JavaScript -> browser
    Now in this mix, change JavaScript to
    JavaScript -> server, browser
    and suddenly, the human logic asks
    how come both
    Java != JavaScript
    (Java -> server) && (JavaScript -> server)
    are true?

    You said yourself that you know such people. Does any of them have the same confusion about any other language? Any of the above mentioned ones? I doubt they do.

    *Probably the one thing that’s universally known by “runs on the server” is that “users don’t need to install anything – your host does”, though you occasionally see the “what plug-in I need for my browser to render PHP?” people too. However, they jump over that point quickly enough, i.e. telling them once “PHP runs on the server – you don’t need to install anything in your browser” helps. It won’t be as easy to explain with JavaScript.

  • Amenthes

    For your information there is a group discussing and trying to standardize an API for server side JavaScript. Otherwise… I totally agree with thr. These people are very, very misinformed.

  • ^ I don’t know if I agree with your arguments boen_robot… I coded Javascript in ASP about 10 years ago when I first started coding on the server. I was really new to the whole server-side/client-side process and after some initial stumbling similar to your “what plug-in I need for my browser to render PHP?” question, I got it and found that it was a good syntax to use.

    Also, you’re not likely to “leak server information into the client, and never know I did” because they run in different scopes.

    Server-side javascript is no different than Ruby, PHP, ASP, JSP, CFM… It’s just another language on the server. You don’t have to learn it but who knows…. You might find it’s a good thing :)

  • No. It won’t succeed.

    Moreover it’s wrong to think that if a developer already knows client-side JavaScript he’ll easily pick-up server-side JavaScript. It’s wrong. Yes, the syntax is same, but the libraries are different. There are far more things you want to have on the server that don’t currently present in the client version.

    One can argue that people use .NET and C# for everything including Windows applications, client-side web application (Silverlight) and web server-side (ASP.NET) but in the all these cases, people not only use C# but more importantly the use the standard .NET class library.

  • Dude

    Those of you who dis’ JavaScript might benefit from reading JavaScript: The Definitive Guide. You need to understand the difference between core JavaScript and in-browser JavaScript. Core JavaScript is a programming language, independent — and ignorant — of HTML tags, click events, etc., just as C, Java, Python, and Ruby do not natively have special functions and variables for web pages. But when browser makers, like Mozilla and Microsoft, implement JavaScript in their browsers they bundle it with extra functions and variables so that it’s ready to talk to web pages.

    As a full-time web developer for the computer department for several hospitals, over the years I’ve written many web applications, using HTML, CSS, SQL, PHP, LDAP, and JavaScript, including AJAX.

    JavaScript is much more fun to write than PHP. And I’m not saying “more fun” because I can make text blink. The syntax for arrays and objects is a joy, instead of a chore, and closures are handy.

    Server-side JavaScript could come with all the convenient functions that other languages have — for file I-O, database connections, etc. And I would not want to have to enclose it in script tags, like I’ve seen with Jaxer. I would rather make a file with an extension like .jss or .jsx and just put the raw JavaScript in there.

    I would even like to see it adopt PHP’s ability to go in and out of HTML. If done properly, it is basically a built-in templating language that’s very easy.

  • JavaScript is much more fun to write than PHP. And I’m not saying “more fun” because I can make text blink. The syntax for arrays and objects is a joy, instead of a chore, and closures are handy.

    Well said! I’ve written some game stuff just for fun in JavaScript and really appreciate it’s facility for arrays.

  • Anonymous

    “JavaScript, in essence, is nothing but a syntax and potentially equal to any other language for that matter. It could just well live on the serverside.f”

    That is very true. JS is a syntax, that is identical above whatever implementation of JS you use. So a JS implementation in spidermonkey is equivalent to that in helma, as far as syntax.

    So if you love the JS syntax, which many do, it would be a great choice to use JS server side. The current implementations on JS on the server are only that, implementations. There will be better choices to choose from in the future.

    Unlike a language such as PHP, or .Net, JavaScript implmentation is NOT from a central body. Many independent implementations exist, though they inherit the same syntax, they differ significantly in how you write your applications (similar to how ROR is a popular Ruby Framework, but not the language itself).

    Server side JS is very young, and thus many implementations exist, as well as your own custom implementation. This can be seen as a strength, if you may.

    JS is a syntax above the implementation, whether it be C or Java etc. So in essence you have the power of the lower level language, yet the benefits of a syntax developed for scripting, JavaScript.

  • JavaScript implmentation is NOT from a central body

    Although ECMAscript is – JavaScript and JScript are dialects of that.

    Server side JS is very young

    Well, actually, it has been around a long time; classic ASP, Netscape’s LiveScript, and Obtree have been around for 10 years or more. But the implementations were never particularly successful or widely used.

  • Dom

    I never knew…amazing!!

  • Anonymous

    “Is JavaScript the right language for the server environment? ”

    No. There’s no justification for it. It’s a lightweight, toylike language that’s not even in the same league as serious server-side languages like Java and C#. There is simply no reason not to use Java or C# – they are rich, powerful, object-oriented languages with extensive, sophisticated object libraries from third-parties. There’s nothing you can’t do with them.

  • akayani

    Boy I’ve seen some confused programmers by some of you are in a right head spin. And it’s the ones who clearly haven’t tried it and have never used and JS framework like Prototype. Jaxer isn’t just JS on the server it is JS + and JS framework. The only thing missing is a full object model like Java but that can be a pain in the arse anyway. What a great thing it is one web language. And such a nice one at that. And the Aptana application of it is first class.

  • Alex M

    This is obviously just my opinion, but JavaScript is a horrible language that people only deal with because it’s the only language web browsers understand. Now, what baffles me is why anyone in their right mind would choose to use JavaScript in a situation where they don’t have to, such as server-side programming.

    On the other hand, if someone comes up with a deviation of JavaScript, such as ActionScript 3, that may turn out to be a great alternative, but I can’t stand JavaScript as it exists in web browsers.

  • davidhall

    I have used SSJS (server-side JS) for 2 years each of 2 different apps – the old iPlanet LiveWire, and BroadVision, both totally procedural, and at least in the BV app, mixed server & client side JS in the same file – a big mess. If one were to practice the new OO style of JS for the server and practiced a strict separation of concerns then it would probably work well. There are 2 great books on OO style – JS: The Good Parts by Crockford (not sitepoint) and The Art and Science of JS (sitepoint) which make JS seem more like a real language and not just for scripting. (sorry for the late post.)