Wednesday, January 8, 2014

Occasionally I search for some JavaScript help and I come upon the term "Server-side JavaScript". When would you use JavaScript server-side? And how?
My experiences of JavaScript have been in the browser. Is there a compiled version of JS?
share|improve this question
 
interesting question –  DFectuoso Jan 19 '09 at 21:50
 
See this question about Jaxer: stackoverflow.com/questions/98915/… –  Prestaul Jan 20 '09 at 1:41
 
 
I thought this may be helpful here- Wikipedia on Comparison of server-side javascript solutions:en.wikipedia.org/wiki/… –  startup007 Nov 24 '11 at 7:01 
add comment

13 Answers

There's the project Phobos, which is a server side Javascript framework.
Back In The Day, the Netscape web server offered server-side javascript as well.
In both of these cases, Javascript is used just like you'd use any language on the server. Typically to handle HTTP requests and generate content.
Rhino, which is Mozillas Javascript system for Java, compiles Javascript in to Java byte codes, which the JVM can choose to JIT. Other systems use other means for executing javascript, even to the point that some are JIT compiling their javascript internal codes.
I forsee that there will be more and more Javascript on the server. When you're writing "thick" applications in Javascript on the client, then you may as well be able to write your logic in Javascript on the server in order to not have to make the cognitive leaps from one language to another. The environments will be different, but much of your code and knowledge will be sharable.
Finally, Javascript is probably the singular language that has the most money pointing at it right now in terms of implementations. From Apple, Mozilla, Google, and even Microsoft as well as the efforts to make it an even more advanced language (i.e. basically a Scheme with Algol syntax sans macros).
Most of those implementation are buried in the browser, but that's not to say that there's no value on the server side as well.
The tooling is the biggest place where Javascript is lacking, especially on the server side, but if you consider something like Phobos, where you can debug your server side Javascript in the IDE, that's a great advancement.
Personally, I'm tossing Javascript around in my applications like white paint. It offers cheap extensibility for very little cost and is a great enabler.
share|improve this answer
 
note that there is an effort to improve the interoperability & availability libraries for serverside JSwiki.commonjs.org/wiki/CommonJS –  oberhamsi Sep 18 '09 at 13:48
add comment
It's not AJAX, unless people are using the term improperly. As its name suggests, SSJS is JavaScript that runs on the server, interpreted by a standalone (i.e., browser-independent) JavaScript engine, like SpiderMonkey.
Why bother? Well, one area I currently see it underutilized in is in data validation. With SSJS you write one piece of code that then gets used on both the server and the client. Thus you get immediate user feedback from the client-side JS that will automatically match the data checking taking place on the server.
share|improve this answer
 
I like this idea +1 –  Michael Haren Jan 19 '09 at 21:50
 
Some day I'd like to automatically generate JavaScript from database CHECK constraints this way. (I wonder if pgsql has JS bindings?) –  Kev Jan 19 '09 at 21:53
 
+1, never thought about the validation angle –  orip Jan 19 '09 at 23:04
 
I'm using this approach on some legacy ASP apps. It's not without issues (the same issues you'd face with IE vs FF vs Opera), but once you have managed to make it work, it works great. –  voyager Jul 13 '09 at 18:29
add comment
Classic ASP was able to use JavaScript on the server, although most people used VBScript.
One compelling use of JavaScript on the server is as a complement to client-side data validation. For example, you might use the same JavaScript validation library on the client and on the server. This ensures you're using the same logic on the client as you are on the server, but (potentially) avoiding an unnecessary round-trip by pre-validating on the client side.
Wikipedia lists a number of server-side JavaScript implementations here.
share|improve this answer
 
I prefer your wording to mine. :) +1 –  Kev Jan 19 '09 at 21:57
 
We used JScript w/ ASP at my last company. The bonus is fewer languages (we had front-end developers writing some server-side data calls) and code re-use, because you'd use almost exactly the same code to validate on both sides. Good stuff, but now I'm struggling to find good ways to put it into Apache. –  Alex McpMar 13 '10 at 4:59
add comment
It really depends if you are talking about ASP.NET or Classic ASP. If you are using ASP.NET there aren't many good reasons for using Javascript.
ASP Classic is an different case. You can use Javascript on the server side in ASP just the same way you would use VBScript. You can access the Application, Server, Request and Response objects just the same as via VBScript.
There can be real benefits to using Javascript on the server side in ASP rather than VBScript. It means you can share code between the browser code and server code. It also means your developers don't need to deal with two different languages.
There are some downsides to server side Javascript in ASP though. Firstly it doesn't appear to be as fast as VBScript on the server side at string concatenation. It also isn't as good as making calls to COM objects as VBScript (you can only get data back from COM calls via the return value, rather than via out/byref parameters).
share|improve this answer
 
The OP never mentioned a specific technology; he could just as easily be thinking of something like Jaxer. – Adam Lassek Jan 19 '09 at 21:51
 
Lots of people don't realise that you can even do server side Javascript in Classic ASP. So I thought it would be helpful explaining that the term "Server-side Javascript" could just be referring to plain old ASP Classic. – andynormancx Jan 19 '09 at 21:54
 
JScript string concat is slightly slower using the operator (+), but pushing onto an array and joining is very fast and not much more difficult. If you are concat'ing enough strings to matter then it is no harder to do: var buffer = []; buffer.push('strings'); return buffer.join(''); –  Prestaul Jan 20 '09 at 1:39
add comment