Advantages of server side javascript over java

Question

I'm new to server side javascript programming, and I'm trying to understand the differences between this and the traditional server side java. What are the significant differences and why is SSJS becoming popular? How is SSJS better than Java? From a layman's perspective, I would assume JS to be slower than Java in terms of performance, primarily because of it being an interpreted language.

Regards, Anand

Answer 1

I think node.js has had a lot to do with the rise of this phenomenon:

http://nodejs.org/

Pretty sure it has been the impetus for a lot of the commonjs library development, etc.

I see comments to the effect that it makes lives easier when the client and server side code is in the same language. For the node project I worked on, there were only 3 programmers for everything initially, and we were more-or-less given carte blanche to use whatever technology we wanted. This led to some debate as everybody had different backgrounds; but when somebody suggested nodejs, one reason it seemed like a good idea was that javascript was something we all had in common.

However, I don't think the success of node is mainly because it uses js; it's about the design. I liked it a lot more than most of the other server side technology I've worked with (Rails, PHP, cgi, mod_perl, mason), and I would probably have liked it just as much regardless of the language used in the interface. But js it is.

So that's my point: I think it has less to do with anything in particular about javascript and more to do with some of the clever thinking and development that has gone on in the "javascript community", surprise surprise. Consider PHP: I don't think the success of PHP had much to do with the design (or performance characteristics) of the language, I think it had to do with the nature of how it is used and how people conceived of server side programming 10-15 years ago, and (closely related) the tools they had to build upon.

One issue there (in the "clever thinking" department) is the (very convincing-if-you-try-it) assertion made by the people behind node and, eg, nginx, to the effect that an asynchronous, event driven model is better suited to server programming than the traditional parallel synchronous, thread driven model. I believe the later predominates in java, even tho methinks it could just as easily be used the other way. Javascript, on the other hand, was originally intended for use in the asynchronous, event driven world of the browser, and doesn't have threads at all. Again: not so much the language, but the culture.

Also worth noting is the predominant use of JSON as an interchange format and of NoSQL databases like couchdb (which I've used) and mongodb (which I haven't), that make fundamental use of JSON in structuring the db. Couchdb also uses js for some server side programming (basically, query handlers), presumably because the database documents are in JSON, which is also nice to hand off to the client. Very slick and clever. One language, one protocol, from model to view; in a significant sense, there is no "interchange" at all.

Answer 2

the differences between this and the traditional server side java

First of all, Java and JavaScript have nothing in common. They are two totally different things. Keep that in mind.

• I think many people like server side JavaScript, because they can stay in one language. They use JavaScript on the server as well on the client, instead of using another language (like Java, PHP or Ruby). Also, a lot of web programmers are familiar with JavaScript (because they use it on the client), so they understand it well.

• JavaScript can also be easier as Java. If you have just a small project, Java could be a lot of overhead compared to JavaScript. Some things like callbacks could be very elegant in JavaScript.

• Also, new frameworks like Node.js make it attractive to use this language. As long as there wasn't any server side framework, you simple couldn't use JavaScript on the server. But the language has evolved well today.

• I think the performance of JavaScript depends also on the server. I'm not sure of this, but as far as I know, JavaScript could be (just in time) compiled, too. Google's chrome is doing something like that. Also, performance isn't such a big thing on most websites, because the performance is mostly IO to a database. The actual creation of an HTML page is very simple and no big thing. And: PHP is also interpreted and used on many sites. Ruby is significant slower then Java, but Ruby on Rails is very popular. So performance seems not so important. It's more about how "nice" and elegant the language is.

Answer 3

The main advantage from my point of view is simplification of client-server interaction if you have rich JS client interface. If you use the same language at server and client side you can share common code between them (for example, if you have some business logic like validation and it is used at client and at server you can implement it once in JS and use in several places).

And if you already know JS you should not learn a new language to do server-side work.

Answer 4

It's like why using GWT (java web client from google) when you have such wonderful thing like JS.

It's more psychology question I think- people tend to stay in their own save and known zone, instead of moving to an unknown language. If you used java in the last 5 years, and you know all it's pitfalls, and you love it very much, you'll start convince yourself that every thing should be written in java, and is the quickest solution.

I don't say that Java is better than js (although I think that it's better for large server-side projects), but I think that most of the js-server-side users uses this because they already comfort with js, so they don't want to change it.

Answer 5

I would like to add my point here.
In one sentence: Node.js shines in real-time web applications employing push technology over websockets.

This is in stark contrast to the typical web response paradigm, where the client always initiates communication. Additionally, it's all based on the open web stack (HTML, CSS and JS) running over the standard port 80.