When and how do you use server side JavaScript? [closed]

Question

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?

Donee

See this question about Jaxer: #99415 – Philender

And also related: #110262 – Philender

I thought this may be helpful here- Wikipedia on Comparison of server-side javascript solutions: en.wikipedia.org/wiki/… – Heritable

This question is a near equivalent to "When and how do you unify languages in the development stack?". Javascript is the standard language at client, JSON for transport... So, with Javascript at server-side you can unify the development. See answer here. – Towland

@PeterKrauss - I know this is not the place to discuss this, but of all the languages available today, that it is javascript that has become common .. horrifies me. On the other hand, maybe that means the WWW committee, next time around, can agree on substantial language improvements, that they were unable to agree on for HTML5. (Based on the meeting transcripts, reading between the lines, failed to agree largely because doing so, meant helping either Adobe or Microsoft, since those were the two companies with substantive languages that could have been used as a basis for new features.) – Cuspid

Answer 1

There's the project Phobos, which is a server side JavaScript framework.

Back In The Day, the Netscape web server offered server-side java script 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 Mozilla's 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 java script, even to the point that some are JIT compiling their java script internal codes.

I foresee 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 shareable.

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.

Selfloading

note that there is an effort to improve the interoperability & availability libraries for serverside JS wiki.commonjs.org/wiki/CommonJS – Rickrack

2016 UPDATE: Look into node.js. And read Peter Krauss' answer. – Cuspid

This answer was more of a prophecy back then to the raise of server-side JS like Node.js, etc. – 3d

Answer 2

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.

Johnny

Some day I'd like to automatically generate JavaScript from database CHECK constraints this way. (I wonder if pgsql has JS bindings?) – Johnny

+1, never thought about the validation angle – Vharat

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. – Kalin

Answer 3

2013's NEWS

Node.js (see also at Wikipedia article) is a sucess, and its community is growing!

MongoDB (at server), Chrome (at client), and Node.js (at server) use V8 JavaScript engine.

PS: you can use only one language, Javascript, to all your project modules: client-APIs, client interface, "server hub", and server database (ex. stored procedures). All programmers "coding once"!

---

The main distinction between "Server-Javascript" and "Client-Javascript" languages, is explained at http://www.commonJS.org/ , the standard library for Server-Javascript.

CommonJS exists since 2009, and today (2013) is a mature standard, used in both, MongoDB and Node.js.

---

HISTORICAL NOTE: the oldest active "client+server Javascript" (including use of PostgreSQL) open package is alive!
Released in 2001 and in continuous development since then, Whitebeam is a mature Javascript (and DOM) technology. The last update was in January 2016.

---

2016's NEWS

Node.js engine continues as a runtime built on Chrome's V8 JavaScript... And now is, in fact, a consolidated success! The last releases are v7.0 and v6.8 LTS.

JSON, as data interchange format, have continous growing interest in the last years, having surpassed in 2016 the interest in XML (see also in the Science context, where surpassed in 2011). As the native Javascript format, it is also a good language-trend indicator.

The (faster) V8 engine is also the most used, since 2014: in the most popular client (Chrome at desktops and WebView at Android) and popular at servers — Node.js as runtime and PostgreSQL with PL/V8 for SQL and stored procedures.

...Perhaps the most important server-side contribution in 2016 was a fast and robust database support for JSON and Javascript: with PostgreSQL 9.1+ (2016-10) you are able to load PL/V8 (and dialects like Coffeshop) via simple CREATE EXTENSION command; with PostgreSQL 9.5+ (2016-10) the most important, a complete orthogonal set of JSON and JSONb functions and operators.

So, as a fact, there is a fast, resilient and reliable unified JavaScript development stack.

Towland

Re "JSON .. As the native Javascript format, it is also a good language-trend indicator." No, JSON popularity is exploding because it has shown itself to be equally useful in other languages, whenever small packets of key-value pairs need to be shipped between devices (phones, desktop, server). Its easier to work with than XML, for simple data needs. In particular, both Apple and Google use JSON for push notifications. That alone would be enough for an explosion of usage! – Cuspid

About "unified develoḿent", is intersting also to preserve some client/server isomorphism in the MVC-model used by both, client and server. See isomorphic-universal-javascript article or git article. – Towland

... Big problem in 2019 by patent dispute Oracle/Google, see github.com/plv8/plv8/issues/364 – Towland

Answer 4

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.

Elke

I prefer your wording to mine. :) +1 – Johnny

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. – Distant

Validation on client side is only for user experience. It does not provide any security whatsoever. – Kenyon

Answer 5

It could refer to using javascript to post messages to a web server without re-loading the page: in other words, AJAX.

But more likely I think it means something like Aptana/Jaxer (or, today, Node.js), which uses javascript for a server-side language. In this case, remember that javascript is just a language: the DOM used in a web browser is a sort of API. The server-side javascript engines would provide their own API objects, geared at server-side tasks like DB and file system access.

Server-side javascript is an interesting idea because of the client-side validation problem: you want to do validation client-side to avoid sending needless requests to your server. This improves server performance and reduces latency on the client. But you must do validation server-side because you can't trust the client. This results in a lot of duplicate code between the client and server.

The theory is that if your client and server languages match you'll no longer need two implementations of the same logic. In practice it doesn't work so well, because the client and server views of a page request are so different and because you don't control the javascript engine used by the client.

Solemn

old post, but this was the most clear and succint manner in which server side JavaScript can be used that I've read. +1 – Refreshment

Answer 6

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).

Unblown

The OP never mentioned a specific technology; he could just as easily be thinking of something like Jaxer. – Consentaneous

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. – Unblown

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(''); – Philender

Answer 7

You might want to have some functionality both in the browser and in the server to have the exact same implementation.

An example would be a renderer for a wiki-syntax, that you run in the browser for the WYSIWYG editor and on the server to render the resulting page. This way you know that both the rendered results will be exactly the same in both cases.

Apparently Rhino can compile JavaScript to Java classes.

Onetime

Answer 8

Traditionally, Javascript runs around the Document Object Model. But what if you work for a Java shop and would like a scripting engine around your custom object model? That's when Server-side Javascript comes in.

http://en.wikipedia.org/wiki/Server-side_JavaScript

Betweentimes

Answer 9

I remember with Cocoon (Apache's Java/XML/Javascript MVC framework) I used to use server-side Javascript since there was a something (I believe cforms) that needed to be written in Javascript and was running on the server even though I believe you could write it in Java.

We used Rhyno by that time, please check: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

Curbing

Answer 10

Yeah I've just read up about SSJS on a blog by some guy named John Resig.

He describes an engine called Jaxer, which he says is "Imagine ripping off the visual rendering part of Firefox and replacing it with a hook to Apache instead - roughly speaking that's what Jaxer is."

For anyone who knows ASP.NET The HTML looks familiar

<html>
<head>
  <script src="http://code.jquery.com/jquery.js" runat="both"></script>
  <script>
    jQuery(function($){
      $("form").submit(function(){
        save( $("textarea").val() );
        return false;
      });
    });
  </script>
 <script runat="server">
    function save( text ){
      Jaxer.File.write("tmp.txt", text);
    }
    save.proxy = true;

    function load(){
      $("textarea").val(
        Jaxer.File.exists("tmp.txt") ? Jaxer.File.read("tmp.txt") : "");
    }
  </script>
</head>
<body onserverload="load()">
   <form action="" method="post">
    <textarea></textarea>
    <input type="submit"/>
  </form>
</body>
</html>

Note the runat="sever" and runat="both"

Donee

I posted this above, but maybe it belonged here... Some feedback on Jaxer: #99415 – Philender

@John Nolan I believe John Rseig is 'the' guy behind jQuery – Heritable

Answer 11

http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

Check out how Steve Yegge is using Server-Side JavaScript with Rhino and why. He has a bunch of stuff on how he feels JavaScript is up and coming.

Shows

I don't have the spare 6 hours for a Yegge post. – Donee

Man, I wish I could up-vote a comment. :) – Quintanilla

Answer 12

With ASP you can use Server Side JavaScript in a number of ways. The way I most commonly use it is to have the same code executing on the client and on the server for validation.

file.js

<!--//--><%

//javascript code
function example(){return "Hello, World!";}

//%>

file.html

<%@LANGUAGE="javascript"%>
<!-- METADATA TYPE="typelib" 
FILE="C:\Archivos de programa\Archivos comunes\System\ado\msado15.dll" -->
<!--#include file="file.js"-->
<html>
<head>
  <script language="javascript" src="file.js"></script>
</head>
<body>
<%=example();%>
<script language="javascript">alert(example());</script>
</body>
</html>

file.js starts and ends the way it does to allow for inclusion of the same file.

Diabolic