When JavaScript Makes Sense for the Server

Discussions

News: When JavaScript Makes Sense for the Server

  1. When JavaScript Makes Sense for the Server (9 messages)

    JavaScript was conceived as a programming language for modern client side applications. But the popularity of the language has pushed into enterprise service applications as well. Enterprise architects should consider the benefits, potential tradeoffs, and implementation approaches of JavaScript before committing to a JavaScript strategy. At the JavaOne Conference, Chris Bailey (Twitter: @Chris_Bailey), Java Service Architect at IBM discussed his research regarding these issues. Some of his key takeaways include:

     

    • JavaScript backends have traditionally been implemented on Node.JS. Java 8 includes Nashorn and support for Avatar.JS for executing Java directly on the JVM. There were 118 presentation on Nashorn at JavaOne.

     

    • JavaScript is the dominant rich internet application language used by 88.2% of Web applications compared with only 12.9% for Adobe Flash, and .1% for JavaFX. Security concerns about running Java on Web browsers published by CERT advocate against using Java on Web clients at all.

     

    • JavaScript is a nascent language on servers, but its use is growing. There is limited platform support for JavaScript, but Node.js allows JavaScript application to directly access server operating system resources. Node.JS is a single threaded event driven JavaScript Framework designed to build scalable Web applications.

    • The best feature of Node.JS is the use of non-blocking asynchronous IO, which means that JavaScript server applications are really good at scaling to support IO intensive applications that do computationally intensive processing with other applications. But problems can occur if other back end applications stalls forcing the queue to grow large forcing the JavaScript server to  run out of memory.

     

    • The single threaded nature of JavaScript means it is challenging to access the multiple threads made available across modern servers with multiple CPU cores. it is possible to spin up multiple slave JavaScript applications running on different cores or servers using cluster management techniques.

     

    • Java is more efficient for JSON serialization. The top performing JSON serialization applications all achieve three to four times the performance of the best JavaScript applications.

     

    • Java is more efficient for applications that make a single query to a backend application with at least double the performance of JavaScript applications. When multiple queries are required, Java is only about 20% more efficient than JavaScript applications.

     

    • JavaScript excels for applications involving data updates for fetching data from multiple rows in a database, and can achieve twice the performance of Java applications. These improvement are likely because of the higher levels of IO involved.

     

    • Early tests indicated that the V8 compiler adapted for use in  Node.JS is 4.8-times more performant than Nashorn, and about 10-times faster than the older Rhino compiler. The Node.JS compiler also used about 10% of the memory for some test applications. These differences are expected to drop with the evolution of Nashorn. It is currently difficult troubleshoot memory usage in Nashorn application because the memory analysis tools have difficulties separating JavaScript usage from Java usage.

     

    • Nashorn and Avatar.JS might provide benefits in terms of better integration with an enterprise's Java development tool chain than Node.js.

     

     

     

    Threaded Messages (9)

  2. Only now the Java community is realizing the impact of Node.js, serverside javascript and related technology processing and starting to think about solutions. They should be long there. 

  3. http://avatar.java.net/

    Announced several years ago, and now with most of Node.js being able to run on Java on the server, I'd hardly say that was a slow response.

  4. Why? I don't want this typeless nonsense on my server. Node.js changed the javascript world. It didn't magically make better servers.

  5. Microservices.  JSON services where the client, server, and nosql database all speak the common data format natively.  This article reads like the dusty old C/C++ shops poo-pooing Java performance when it first came out and completely misses the larger productivity picture.

    If you are a modern day dusty old Java shop that only deploys software frameworks that require vendor service agreements - stop reading now 'cause your Node code will never see the light of day.

    If you need to move fast, Node.js could be for you.  With the event-based programming, you will eventually get bogged down in promises/futures but you will get through it.

    My feeling is javascript + unit tests ~= strongly typed Java so don't be afraid of Javascript.

     

     

     

  6. Microservices.  JSON services where the client, server, and nosql database all speak the common data format natively.  

    JSON is a representation, it really shouldn't be your native data format. This sounds a lot like xml 15 years ago.

    I do use JSON for exchange all the time. I don't store it.

    If you are a modern day dusty old Java shop that only deploys software frameworks that require vendor service agreements - stop reading now 'cause your Node code will never see the light of day.

    If you need to move fast, Node.js could be for you.  With the event-based programming, you will eventually get bogged down in promises/futures but you will get through it.

    I'm a modern day java shop that doesn't need node.js. My code is typed. I can use events wherever I want. My server has threads, I know what they are and how to use them, and I don't need ugly artifacts to emulate them because of somewhere with an out-of-nowhere, non-academic statement that my server should be single-threaded.

    My feeling is javascript + unit tests ~= strongly typed Java so don't be afraid of Javascript.

    Well, that feeling is wrong. Let's use strong typing + unit tests.

     

     

  7. Never[ Go to top ]

    I know when JS makes sense on the server.

     

     

    NEVER

  8. Never[ Go to top ]

    +1

    Until now, I never saw any good argument for javascript on the server. No new paradigm. Nothing that isn't done in other (better) languages / platforms. Just some feeling that some cool kids do it. No added value, but they still want to give up your typing, standards, etc in favor of a random framework that will disappear in a few years.

    The only reason for javascript to still exist is that it's the consensus for browsers. They do a good job of letting it run fast nowadays, but that doesn't make it acceptable when you've got alternatives.

  9. This article above is a strong argument to stay with Java in the server.  The one performance advantage (currently) with node.js from async IO.  Is it impossible to use async IO in Java: no.  So..after reading this, I don't think javascript will every makes sense for the server.

  10. Do you know what's security implication for using JS on the server?