Nearly a decade ago Netscape released Enterprise Server 2.0 with LiveWire, their name for JavaScript used as a server side web scripting language as PHP is most commonly today. LiveWire was extremely buggy, but Netscape was golden in large organizations, so I had the opportunity to develop or support development of several large web applications written in LiveWire. The world’s buggiest webmail client ever was a component of one of them.
Thankfully Netscape’s server products faded over the next few years. As far as I know LiveWire is almost completely forgotten.
The only uses of server side JavaScript that I’m aware of today are in Helma Object Publisher and as an alternative scripting language for Active Server Pages (though I understand the vast majority of ASP development uses VBScript). Some Java-based web applications may embed the Rhino JavaScript engine (that’s what the Helma framework does, prominently).
I’m mildly suprised that server side JavaScript isn’t more popular, given the opportunity for sharing skills and code with client side JavaScript. Data validation is one obvious opportunity for the same code executed on both the web browser and server, however the one that prompted me to write this post is web services. Suppose you want to offer a “web service” that can be consumed directly by browsers, i.e., a JavaScript application without a UI. You also want to offer approximately the same service as a traditional web service for consumption by non-JavaScript clients, and you don’t want to write much of the same code twice.
The only page I could find about sharing JavaScript code between client and server applications is a terse article on Shared Sides JavaScript.
So why hasn’t JavaScript seen more use on the server side? Possibilities:
- JavaScript is unfairly looked down upon by server developers. (The success of PHP is a counterexample.)
- Client side JavaScript is typically spaghetti code written by designers. The cost of sharing code between client and server applications in this context is too high.
- No obvious way to deploy JavaScript code in Apache. There was work on mod_javascript/mod_js in the late nineties, but I see no evidence it went anywhere.
- It’s easier for developers to handle different languages on the client and server. In my experience with LiveWire last decade I did encounter a few developers unclear on the concept that some JavaScript executed on the server, some on the client.
Perhaps the recent hype around AJAX will attact a critical mass of good programmers to JavaScript, some of whom will want to reuse well structured code on the server, leading to server side JavaScript’s first renaissance.
Pre-posting update: As I was about to post this Brian Heung told me about TrimJunction, which has more or less the motivation I was thinking of:
With an eye towards Don’t Repeat Yourself, spiced up with a little bit of Ajax, the grand vision of the TrimPath Junction project is to be able to write web application logic just once, in familiar languages like JavaScript.
A Junction-based web application should run, validate input, process data, generate output and do its thing on both the server AND the client. We intend to use the Rhino JavaScript runtime for the server and use your favorite, modern web browser for the client.
Check out the Tales on TrimPath blog for some interesting JavaScript ideas. The Junction announcement is here, two months old.
Update 20050716: OpenMocha is ready for a spin:
The goal of OpenMocha is to maximize the fun and productivity of Javascript development by blending the gap between browser and server based scripting.
Hi, maybe you can take a look at firecat, a server-side JavaScript Webserver:
http://firecat.nihonsoft.org
Hi,
I was just wondering now whether there was any such thing as Server-side Javascripts (besides whatever Firefox is using for its use of privileged Javascript), and for the reasons that you stated so well (I’m now trying to design my site to be mobile phone friendly)…It seems not only that code can be saved, but even possibly the requirement to learn more than one language and its syntax…If new developers can just focus only on HTML and Javascript, that would be a whole lot easier…(unless PHP will somehow acquire Javascript (including AJAX) capabilities)–anything to bring us a step closer to an integrated system anyone can program in (still a long way to go for sure). Two other advantages to writing in this mode that I can see would be that:
1) Developers can have the freedom to hide their Javascript code if they wish.
2) Users could also be given the choice as to whether they wished to have the code (where relevant) first load regular client-side (and/or including, optionally, any AJAX) code or regular server-side code. This would be a useful choice not only for scriptless browsers, but also for those who wanted to be able to choose whether to have a faster initial load by foregoing the client-side Javascript in order to let the server take care of subsequent server calls.
If I have not understood what SSJS can do correctly, then I still think such features should be somehow made possible!
Best wishes, Brett
Running the same code on both/either the server-side or the client-side isn’t that easy, because the data backends and object models are usually radically different. On the other hand, sharing lower level code such as libraries that extend the language does already work the same on the client-side and server-side.
Hiding data backends, the client-side DOM and the server-side repsonse generation related object model behind an abstraction layer could be an idea whoes time has come – and that is basically what you are describing. I am certainly very interested in this and will be working on a open-source BSD licensed implementation of that. Thoughts, ideas and suggestions regarding such an effort are welcome!
The wxJS project (http://wxjs.sourceforge.net) has a mod_wxjs module which makes it possible to write server-side applications in JavaScript on Apache servers.
By placing that at the top of an ASP page the script is then interpreted by the jscript parser server-side.
<%@LANGUAGE=”JSCRIPT”%>
It butched my comment… I hope this works.
I also am an ex-LAMP developer who is on a quest for the holy grail of Server Side Javascript. My dream implementation would be a Javascript environment tuned for *nix applications (sorry Franky/wxJS) that can actually build (sorry Whitebeam) and coordinate with a mature server such as apache (sorry firecat, Helma, Rhino, etc) to serve web requests.
Good would be having a working implementation of DBI and great would be having a CPAN like mechanism.. or even a way to utilize/wrap existing CPAN modules as a crutch to bootstrap the project.
With such a beast, one could do a lot of code reuse for specific but very irreducible tasks such as input verification and template infusing. Imagine writing just one slice of code that injects data into a template for display.. running it server-side to deliver a page with initial data, and then client side to manipulate the page in a Web2.0 application as the data changes. You could write an object which checks your form submissions client side to kindly warn the user they are being an idiot, and then re-run server side to harshly log/kline/narc the hacker who ignores all the client side warnings and attempts form smurfs manually.
Javascript/ECMAscript has an object model I can really dig, where PHP and Perl leave me wanting.. and C++ and Java leave me gagging. Ruby, while an interesting idea, will never reach the critical mass that JS has already attained. We need some real world, boots on the ground, SSJS.
Who’s with me? And, I guess, how do we do that? :)
Should there be a forum somewhere? I feel there should. We should try to crystalize a community around this.
@Jesse Thompson
I totally agree with you. Javascript is such a versatile scripting language, and mature interpreters are already implemented (SpiderMonkey), all it needs is just a chance to attract enough attention to the general public. I am also a LAMP programmer, and the object programming of PHP5 never satisfy my needs. I think there are few things that can push SSJS further:
– make sure it does not repeat the quirky nature of PHP scripting (spaghetti code in html)
– complete MySQL / other dbms interface, ActiveRecord style
– rock solid MVC framework (like Rails and CakePHP)
– easy to deploy Apache SO module
– a community
It seems to me that MVC framework is the key to push forward the whole initiative. Few years ago almost no one knew about Ruby, until The Rails framework got this funny language known to the public. An active community is also very important.
[…] the default glue and application language for the next decade on the web, desktop and the server. Where is server side JavaScript? from July 2005 continues to be one of the most viewed posts on this blog. Many people are thinking […]
I’m another one who got recently enlighted with the idea of using JavaScript on the server. It occurred to me (late, but thankfully ocurred ;) that it is a huge inefficiency to build applications with the miriads of languages (html, js, xml, your-preferred-server-side-lang,etc) and translations back and forth langs. Specially, nowadays, those ‘translations of objects’ (from, say PHP or ruby to javascript) with JSON, etc.
So, I’m urgently looking for a server-side javascript environment (ASP? no thanks) to get some great ideas going. With firefox extensions and client/server JavaScript, one can get pretty close to the vision of real distributed internet objects, and the expressiveness that this offers.
I have been looking for the same thing. It totally blows my mind that people avoid any type of server side javascript programming. As AJAX becomes more and more popular, there will be more people working with various AJAX GUI toolkits. I am currently working on a server / client side solution. As most of my clients are on windows servers I’m building everything to support jscript / JScript.NET. I really hope I can find something supporting server side javascript on Apache soon. Maybe I’ll have to start something up on SourceForge.
Interested to know what build problems you’re having with Whitebeam. We’re only a small team so we build primarily for Fedora and OpenBSD (the ones we use). Build fine on them and is intended to be *nix friendly.
If you check the Whitebeam forumns on Sourceforge (http://www.sourceforge.net/projects/whitebeam) there are some messages from others on successful builds – and feedback on the issue they had so that we could improve the build process.
RPMs will be available shortly for recent Fedora builds. They can be built now.
@Jesse Thompson: That’s an awesomely excellent idea. A *lot* of people seem to dislike js just because it’s so often misused, but it really is a full-featured language. While I’d rather run ruby in browsers, js on servers seems a bit more viable ;)
JS could definitely be used more for other things as well, such as shell scripting and embedding (game scripting, etc).
SSJavascript is suitable for being a standard (not like Visual Basic or C#).
Otherside, ASP, JSP are implementations of SSJavascript (view Wikipedia).
Nowday CGI and SCGI are too slow.
I think AJAX isn’t new compared with SSJavascript.
Could be PHP is only Server Side language ? Then I prefer two sides Javascript.
But PHP supports a lot of databases…
Fernando
Hi guys! I’m very happy to see this post which let me know so many people are interested in server-side javascript. I have been working on a SSJS MVC framework for several weeks but at the moment there are something that prevent me from moving on. One of them is performance. Here’s the situation I meet right now.
My framework uses JDK6 and Jetty as servlet container. JDK6(aka Mustang) has its own javax.scripting feature so I don’t need to embed Rhino by myself. Jetty is very easy to embeded into other application. After all basic work had been done, I tried a simple code like this:
var str = “”;
for(var i=0; i (23.493ms)
1. run action invocation(23.283ms), 99.1%
2. StringView(str: value_0value_0value_0value_0value_0value_0) execution(0.21ms), 0.1%
23:32:44,316 INFO web request “index2” —> (44.282ms)
1. run action invocation(43.585ms), 98.4%
2. StringView(str: value_0value_0value_0value_0value_0value_0) execution(0.19ms), 0%
23:32:47,178 INFO web request “index2” —> (14.699ms)
1. run action invocation(14.507ms), 98.7%
2. StringView(str: value_0value_0value_0value_0value_0value_0) execution(0.13ms), 0.1%
23:32:47,546 INFO web request “index2” —> (14.684ms)
1. run action invocation(14.497ms), 98.7%
2. StringView(str: value_0value_0value_0value_0value_0value_0) execution(0.13ms), 0.1%
23:42:24,005 INFO servlet… —> (0.915ms)
23:42:24,009 INFO servlet… —> (3.133ms)
23:42:24,012 INFO servlet… —> (0.962ms)
23:42:24,014 INFO servlet… —> (0.876ms)
23:42:24,023 INFO servlet… —> (8.026ms)
23:42:24,026 INFO servlet… —> (0.932ms)
23:42:24,029 INFO servlet… —> (2.451ms)
We can see clearly that “index2″(SSJS request) cost 10-20ms for each request on average, while servlet only did that in 1-2ms.
I’m really sad now. Should I continue to work on it? I’m also a little tired of Java, which in my opinion always turns simple things to complex. I’m considering to use PHP, not Java any more.
You might want to look at Torino which provides a Mozilla Rhino JavaScript implementation hosted in a servlet-compatible server such as Tomcat or Glassfish. Server-side programming may be performed using scripts or server pages in the style of PHP and server-side APIs are provided by the Java runtime environment so Torino can do anything on the server you can do with Java including JDBC, XML, network access and so on. The Torino project is hosted on SourceForge at http://torino.sourceforge.net and is open-source (GPL3).
And in May 27, 2009 node.js was released. ;-)