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

It's not AJAX, unless people are using the 11 term improperly. As its name suggests, SSJS 10 is JavaScript that runs on the server, interpreted 9 by a standalone (i.e., browser-independent) JavaScript 8 engine, like SpiderMonkey.

Why bother? Well, one 7 area I currently see it underutilized in 6 is in data validation. With SSJS you write 5 one piece of code that then gets used on 4 both the server and the client. Thus you 3 get immediate user feedback from the client-side 2 JS that will automatically match the data 1 checking taking place on the server.

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

Back In The Day, the 37 Netscape web server offered server-side 36 java script as well.

In both of these cases, JavaScript 35 is used just like you'd use any language 34 on the server. Typically to handle HTTP 33 requests and generate content.

Rhino, which is 32 Mozilla's JavaScript system for Java, compiles 31 JavaScript in to Java byte codes, which 30 the JVM can choose to JIT. Other systems 29 use other means for executing java script, even 28 to the point that some are JIT compiling 27 their java script internal codes.

I foresee 26 that there will be more and more JavaScript 25 on the server. When you're writing "thick" applications 24 in JavaScript on the client, then you may 23 as well be able to write your logic in JavaScript 22 on the server in order to not have to make 21 the cognitive leaps from one language to 20 another. The environments will be different, but 19 much of your code and knowledge will be 18 shareable.

Finally, JavaScript is probably 17 the singular language that has the most 16 money pointing at it right now in terms 15 of implementations. From Apple, Mozilla, Google, and 14 even Microsoft as well as the efforts to 13 make it an even more advanced language (i.e. basically 12 a Scheme with Algol syntax sans macros).

Most 11 of those implementation are buried in the 10 browser, but that's not to say that there's 9 no value on the server side as well.

The 8 tooling is the biggest place where JavaScript 7 is lacking, especially on the server side, but 6 if you consider something like Phobos, where 5 you can debug your server side JavaScript 4 in the IDE, that's a great advancement.

Personally, I'm 3 tossing JavaScript around in my applications 2 like white paint. It offers cheap extensibility 1 for very little cost and is a great enabler.

2013's NEWS

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

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

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

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

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

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

2016's NEWS

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

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

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

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

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

Classic ASP was able to use JavaScript on 11 the server, although most people used VBScript.

One 10 compelling use of JavaScript on the server 9 is as a complement to client-side data validation. For 8 example, you might use the same JavaScript 7 validation library on the client and on 6 the server. This ensures you're using the 5 same logic on the client as you are on the 4 server, but (potentially) avoiding an unnecessary 3 round-trip by pre-validating on the client 2 side.

Wikipedia lists a number of server-side 1 JavaScript implementations here.

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

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

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

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

It really depends if you are talking about 21 ASP.NET or Classic ASP. If you are using 20 ASP.NET there aren't many good reasons for 19 using Javascript.

ASP Classic is an different 18 case. You can use Javascript on the server 17 side in ASP just the same way you would 16 use VBScript. You can access the Application, Server, Request 15 and Response objects just the same as via 14 VBScript.

There can be real benefits to using 13 Javascript on the server side in ASP rather 12 than VBScript. It means you can share code 11 between the browser code and server code. It 10 also means your developers don't need to 9 deal with two different languages.

There 8 are some downsides to server side Javascript 7 in ASP though. Firstly it doesn't appear 6 to be as fast as VBScript on the server 5 side at string concatenation. It also isn't 4 as good as making calls to COM objects as 3 VBScript (you can only get data back from 2 COM calls via the return value, rather than 1 via out/byref parameters).

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

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

Apparently Rhino can compile JavaScript 1 to Java classes.

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

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

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

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

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

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

For anyone who knows 2 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 1 runat="sever" and runat="both"

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

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

With ASP you can use Server Side JavaScript in a number of ways. The way I most 3 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 2 and ends the way it does to allow for inclusion 1 of the same file.