Advantages of javascript server over java

Question

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

Regards, Anand

Answer 1

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

http://nodejs.org/

Pretty sure that this served as an impetus for the development of the commonjs library, etc.

I see comments that it makes life easier when both client and server code are in the same language. For the node project I was working on, there were only 3 programmers in everything, and we were more or less provided with carte blanche to use any technology we wanted. This led to some debate, as everyone had a different experience; but when someone suggested nodejs, one of the reasons it seemed like a good idea was that javascript was something in common that we all had.

However, I do not think that the success of node is mainly because it uses js; it's about design. I liked it a lot more than most of the other server-side technologies I worked with (Rails, PHP, cgi, mod_perl, mason), and I probably would have liked it the same way, regardless of the language used in the interface. But js it.

So, my point of view: I think this has less to do with anything, in particular with javascript, and more with some clever thinking and development that continues in the “javascript community”, an unexpected surprise. Consider PHP: I don’t think that the success of PHP had much to do with the design (or performance characteristics) of the language, I think that it had to do with the nature of how it is used and how people thought about server-side programming 10-15 years ago and (closely related) tools on which they should have relied.

One of the questions (in the "smart thinking" department) is the (very convincing, if you try) statement made by people from node and, for example, nginx, that the asynchronous, event-driven model is better suited for server-side programming than the traditional parallel synchronous flow-controlled model. I believe that later ones prevail in java, even, apparently, it can be just as easily used in a different way. Javascript, on the other hand, was intended to be used in an asynchronous, event-driven browser world and has no threads at all. Again: not so much a language as a culture.

It is also worth noting the predominant use of JSON as an exchange format and NoSQL databases such as couchdb (which I used) and mongodb (which I do not have) that make fundamental use of JSON in db structuring. Couchdb also uses js for server-side programming (mainly request handlers), presumably because the database documents are in JSON, which is also nice to pass to the client. Very sleek and smart. One language, one protocol, from a model to view; in a significant sense, there is no "exchange" at all.

Answer 2

differences between this and traditional java server

First of all, Java and JavaScript have nothing in common. These are two completely different things. Remember this.

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

• JavaScript can also be simpler than Java. If you only have a small project, Java can have a lot of overhead compared to JavaScript. Some things, such as callbacks, can be very elegant in JavaScript.

• In addition, new frameworks such as Node.js make it attractive for using this language. As long as there was no server structure, you simply could not use JavaScript on the server. But today the language has developed well.

• I think JavaScript performance also depends on the server. I'm not sure about this, but as far as I know, JavaScript can be (just in time) compiled. Google chrome does something similar. Also, performance is not such a big thing on most websites, because performance is mainly IO for the database. Actual HTML page creation is very simple and unimportant. And: PHP is also interpreted and used on many sites. Ruby is significantly slower than Java, but Ruby on Rails is very popular. Thus, performance does not seem so important. This is more about how “good” and elegant language is.

Answer 3

The main advantage from my point of view is the simplification of client-server interaction if you have a rich JS client interface. If you use the same language on the server and on the client side, you can exchange common code between them (for example, if you have such business logic as verification, and it is used on the client and on the 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 work on the server side.

Answer 4

How do you like using GWT (java client from Google) when you have such a wonderful thing like JS.

I think this is more a matter of psychology - people, as a rule, remain in their own safe and well-known zone, instead of switching to an unknown language. If you used java for the last 5 years, and you know that all this is a trap, and you really like it, you will begin to convince yourself that everything should be written in java and is the fastest solution.

I'm not saying that Java is better than js (although I think it is better for large server-side projects), but I think that most users of js-server-side use this because they are already comfortable with js, so they don’t want to change it.

Answer 5

I would like to add my thought here.
In one sentence: Node.js shines in real-time web applications using push technology over websites.
After more than a 20-year period of inaction based on apathy based on a stateless request-response paradigm, we finally have real-time two-way web applications where both the client and server can initiate data exchange, allowing them to exchange data free.
This contrasts sharply with the typical web response paradigm when the client always initiates communication. In addition, all this is based on an open web stack (HTML, CSS, and JS) working on standard port 80.