I have been looking at server side Javascript technologies like, Rhino and Node.js. What are the advantages of using server-side Javascript and where in the server-side to they fit in a stack?

  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask – gnat Apr 6 '13 at 12:03
  • 3
    I took this to mean "server-side JavaScript" compared to "server-side [something else]" in which case this isn't a duplicate. – phant0m Apr 6 '13 at 18:31
  • 1
    @phant0m That's how I took it as well, but I don't feel comfortable re-opening until user86834 clarifies (because honestly it's just too vague now and we're only speculating). Also I'm not so sure "server-side JavaScript" compared to "server-side [something else]" is a constructive question, but it's certainly not a duplicate. – yannis Apr 7 '13 at 6:18

I'll be talking exclusively about Node.js as I don't have any experience with Rhino. The main difference would be the environment they run in. Rhino runs on the JVM and V8 (Node.js) is merely a compiler to native code not an interpreter.

The difference between Node.js and Rhino is that Rhino is a JavaScript engine and Node.js is a set of libraries that run on V8 (The JavaScript engine). These libraries are primarily built with an asynchronous approach to provide a fast, scalable system. Async isn't new. Python has many frameworks like Tornado and Ruby has EventMachine. The issue with these is their 3rd party module systems. If you start an using asynchronous you need to only use asynchronous methods. Ruby and Python's 3rd party modules are mostly synchronous. This makes choosing libraries much more difficult and not very appealing.

You could say that Node.js is build around the asynchronous model and it's 3rd party model system are purely asynchronous (albeit some exceptions where they specifically state what's synchronous or when they give both asynchronous and synchronous methods).

There's lot of library fragmentation in other languages. Fragmentation is async vs sync and module systems. Node.js has arguably one module system: NPM. This creates standardization around 3rd party module.

There are many advantages to running Node.js:

  • You write JavaScript (A well known language)
  • You can share code between the client and server-side
  • Running on-top of V8 (which is extremely fast)
  • Asynchronous model (a ton of compatible modules to help you)

As to the questions in the comments (talking about distributed architecture)....

  • If you want to write high performance, CPU-bound tasks in C++, why not write native modules?

Most of the time you'd want to write these systems independently from Node.js. The purpose of a distributed architecture is:

  • Fault Tolerant (If a failure happens in a single system, it's much easier to replace them.)
  • Modular (You'd write smaller systems with a defined scope. You can also replace the inner workings of each system and everything will still work)
  • High Performance [1]

[1] When you're building high-performance systems you don't need it to be bound to Node.js or the V8 engine as working under v8 and node.js requires additional knowledge and is much much harder to debug as you complicate the layer even more.

THe last part might be a tad out-of-scope but I'll leave it in for now.

  • I agree with most of the post, but I'm not sure I understand the last part. You can spawn as many nodejs processes as you have cores (distributing requests through nginx process for example). And if you need them to intercommunicate, the nodejs IPC is also really straight forward. – back2dos Apr 6 '13 at 12:24
  • @back2dos The last part I was talking about having a distributed system. In this case, Node.js would just handle the requests coming in and outsource them to another service if it needs havy lifting (data analysis, distributed queries, etc...) This is how many of the big systems are built, using independent, fault-tolerant services. It's trivial to use Node.js with Thrift to accomplish this. – Daniel Apr 6 '13 at 12:27
  • I really don't see what you are saying. If you just want to use nodejs as a reverse proxy, then you might as well use ngingx or something that was really taylored for that task, as it delivers much better performance. As for heavy lifting: Distribution always introduces overhead. Serialization (for whatever transport layer) rarely comes without CPU and memory cost. You can always write native extensions for CPU-bound bottlenecks once you have identified them and off-load them from the main-thread to a subprocess through nodejs or a background thread from within the extension as needed. – back2dos Apr 6 '13 at 12:42
  • 1
    If you're using C++, you might just as well write node.js modules. – Florian Margaine Apr 6 '13 at 13:48
  • @Daniel: I'm not sure where you're going with this, let alone why. As is, I think it is bad advise and also not really in the scope of the question, but if you want to keep it as part of your answer: Can you devise a nodejs scenario where the fragmentation you propose is a benefit, rather than a disadvantage? And explain why? Or why you think that "native node.js modules you're still within the V8 and Node.js context. Not something you'd want within a high performance, high CPU-bound service"? – back2dos Apr 6 '13 at 15:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.