Sorry if I look like dumb here, nevertheless, could you provide a 2-3 sentences description what is server-side javascript good for?

Is it meant as server scripting replacement? E.g. to replace PHP?

I don't use JS server side, I use PHP. But sometimes, when I'm developing and take me 5-7hs to get the damn submit check routine done right, I think: "Ohh, wold be so good if I can just reuse the same routine server and client side." And other times I think: "If I was using JS server-side wold be so easy to do reports with ExtJs... I cold do a grid populate it and done... with basically the same code I used to do the client version." (I'm thinking in Aptana Jaxer, that as far as I know is the only one the permits that kind of integration.)

Maybe there is other motivations for other people, but if I choose to start using server side JS, wold be primary for that things.

You can think of it as a replacement for PHP or Java or C# or whatever on the server side.

If the implementation is an apache module, then server side JS is very much like PHP. The server gets a request for http://somehost.com/index.sjs (.sjs = server side javascript) and it runs index.sjs in some javascript engine like v8 or spidermonkey.

If the implementation is rhino based, then the server side JS is run in an application server environment. I'll talk about Helma a lot in these discussions; it's rhino on top of the Jetty Java/JSP server. When a request comes in, Jetty does all the httpd type stuff and calls your Javascript function, passing Java servlet style request and response objects in as global variables. Rhino based implementations, like Helma, will compile your javascript into JVM byte codes, so you're basically running at Java speed (considerably faster than PHP).

If you're using a Rhino based server, your javascript can script java. This is detailed here:
http://www.mozilla.org/rhino/ScriptingJava.html

The gist is that you can use any Java class that's on your CLASSPATH from your Javascript programs. This means you can do image manipulation with the Java graphics classes, use the JDBC driver/classes to access SQL databases, and so on.

The thing about Helma is that it comes with a very robust and mature library of Javascript code for the server side that include functions for doing all those things and more.

My interest in SSJS is to be able to write client and server code in the same language and to even share the code between client and server. There's a huge advantage of having your server be an application server (e.g. Jetty or even .NET) vs. being a WWW server - the application and state remains and changes even when there's no WWW accesses from clients.

Share code? Don't we all have to validate form fields on the client and then again on the server? A single Validator class can run on either/both sides; you don't have to maintain two separate bits of code in two languages.

That's just a start...

Thank you for explanation.

Just thinking that it would need to be a very, very, very strong motive or advantage that I could see, experience, test that would make me to switch from Apache/PHP/MySQL.

I'll speak of Helma, again.

In your script, you have access to a global object named "app." In app.data, you can store any complex Javascript object, and it will persist from WWW page hit to WWW page hit (or WWW service hit to WWW service hit, whatever).

PHP has something similar in $_SESSION. The cost of using this is a serialize() and unserialize() call per hit on the server, and $_SESSION is only tied to a user/browser by cookie. It's not shared among other accesses by other users. If you use something like APC or eAccelerator, those provide functions for storing serialized objects in shared memory, so you can access them from request to request, shared among all users. Again, the cost is serialize() and unserialize() per request.

app.data does not have the serialize()/unserialize() penalty and it has the added benefit of being able to store live instantiated objects. In PHP, you cannot serialize an instantiated mysqli object. In Helma, you CAN instantiate a JDBC object and store it in app.data and issue queries against it in numerous requests. Maybe JDBC/mysqli isn't the best example, but imagine you have a socket connected to AIM or Yahoo! or to GMail; in PHP, you'd have to open those sockets every request, in Helma you'd keep those sockets open until your business logic decides to close them.

With helma you get worker threads, too. So you can complete a request and have the worker thread do some database operations.

Of course there's the consideration of the language. I happen to really like Javascript. I will say that I do see PHP 5.3 as a major improvement in language capabilities (you get namespaces and lambda functions and closures), but it still doesn't get around the nature of how the entire environment has to be initialized at the beginning of every request.

I hate it when PHP complains I define an array:
$array = [];
Or how ugly it is to create initialized arrays of arrays of arrays of objects...

Then there's performance.

I've presented benchmarks in a forum thread where rhino based javascript consistently is faster than the same program written in PHP.

If you have an application that is comet style, the cost of setup/initialization of PHP script once per interval (1/sec?) is a huge performance loss. When you consider 100 people using your comet application, your server could be swamped. Most of the time tested and well used PHP applications (like vb3, this message board) serialize()/unserialize() large complex objects and store them in blobs in the DB, using the DB as a cache. They can be configured to use memcached or other things that are really band aids, IMO.

My biggest gripe with PHP development (and I do a LOT of it) are the tools. As soon as you get comet and/or ajaxy things going on, XDEBUG based debuggers blow up. I've had little success with Zend's products due to performance and bugs.

With helma, you type ./start.sh on the server and it opens a firebug like debugger window (X window) on your desktop. You can use Notepad or Notepad++ or whatever IDE/editor you are comfortable with and fully debug your server side and client side. And the language (javascript) is the same for both.

I implemented a demo using Helma, for work (maybe I can make the sources public someday). It's the basis for a CMS, something like Drupal. I had it dynamically generating 10,000+ WWW pages/sec (apache benchmark/ab) with every page having 5 JST templates (JST is a javascript templating system) per page. It's on the order of hundreds of times faster than Drupal doing the same thing (if not thousands of times faster).

YMMV, of course.

A server-side example from NodeJS:

Code:

var dj = require('./djangode');
    dj.serve(dj.makeApp([
        ['^/$', function(req, res) {
            dj.respond(res, '<h1>Homepage</h1>');
        }],
        ['^/other$', function(req, res) {
            dj.respond(res, '<h1>Other page</h1>');
        }],
        ['^/page/(\\d+)$', function(req, res, page) {
            dj.respond(res, '<h1>Page ' + page + '</h1>');
        }]
    ]), 8008); // Serves on port 8008

I used to implement Ext Core in Server-Side JS

Hint: Hey mschwartz, have you ever tried FirePHP with FireBug to debug PHP code? I use it in a daily basis and think it is the best think ever after FireBug it self.
I let it after all my error messages inside the code, and in the beginning of each server access I test, if its me instantiate the FirePHP, if not, replace it by a custom function that log the error. (:

@Frank

Implementing Ext Core for the server side is an interesting proposition, but you'd need the DOM implemented server side, too. Right?

@ethraza

FirePHP is a cute trick, but I've done my own thing that I like much better (for ExtJS). Basically, I wrap my JSON responses from the server with extra JSON. Something like this:

Code:

{
   console_log: 'what I want to print via console.log()',
   data: {
      // what would normally be sent as JSON to the client
   }
}

Then I implement Ext.Ajax.on('requestcomplete'...) handler that unpacks the JSON and does the console.log() for me.

What I describe is a bit more simple than what I really do... But you get the idea.

I am a SSJS user, and I use it very often