What is the usage ? the front, back end ? ... VS
To be honnest my preference comes defintly (after many years of using it) to javascript.
First argument to me - simplicity.
Second : everywhere .. thanks to Node.JS and ts packaging system NPM. It's so easy to deploy, to test on any OS or VM.
But Java has learn from JS !
Look at this code : Web server with Nodejs vs Spring Boot - How to create a Http server ?
Nodejs
var http = require(‘http’);
http.createServer(function (req, res) { res.writeHead(200, {‘Content-Type’: ‘text/plain’}); res.end(‘Hello World’);
}).listen(3000);
Spring Boot
@RestController
class ThisWillActuallyRun { @RequestMapping(“/”) String home() { return “Hello World!” }
}
Another argument for system or architectures should be performance.
Let's see a set of performance tests to be run against both a Java EE application and a Node.js application, both backed by the same CouchDB database.
A site i love (https://dzone.com/articles/performance-comparison-between)
J2EE
The following Java code is a servlet that fetches a document from CouchDB by id and forwards the data as a JSON object.
package com.shinetech.couchDB;
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.log4j.Logger;
import com.fourspaces.couchdb.Database;
import com.fourspaces.couchdb.Document;
import com.fourspaces.couchdb.Session;
@SuppressWarnings("serial")
public class MyServlet extends HttpServlet {
Logger logger = Logger.getLogger(this.getClass());
Session s = new Session("localhost",5984);
Database db = s.getDatabase("testdb");
public void doGet(HttpServletRequest req, HttpServletResponse res)
throws IOException {
String id = req.getPathInfo().substring(1);
PrintWriter out = res.getWriter();
Document doc = db.getDocument(id);
if (doc==null){
res.setContentType("text/plain");
out.println("Error: no document with id " + id +" found.");
} else {
res.setContentType("application/json");
out.println(doc.getJSONObject());
}
out.close();
}
}
What can be seen is that the response time deteriorates as the number of concurrent requests increases. The response time was 23 ms on average at 10 concurrent requests, and 243 ms on average at 100 concurrent requests.
The interesting part is that the average response time has an almost linear correlation to the number of concurrent requests, so that a tenfold increase in concurrent requests leads to a tenfold increase in response time per request. This makes the number of requests that can be handled per second is pretty constant, regardless of whether we have 10 concurrent requests or 150 concurrent requests. At all observed concurrency level the number of requests served per second was roughly 420.
NodeJS
The Node.js application ran on Node.js 0.10.20 using the Cradle CouchDB driver version 0.57. The caching was turned off for the driver to create equal conditions.
The following shows the Node.js program that delivers the same JSON document from CouchDB for a given ID:
var http = require ('http'),
url = require('url'),
cradle = require('cradle'),
c = new(cradle.Connection)(
'127.0.0.1',5984,{cache: false, raw: false}),
db = c.database('testdb'),
port=8081;
process.on('uncaughtException', function (err) {
console.log('Caught exception: ' + err);
});
http.createServer(function(req,res) {
var id = url.parse(req.url).pathname.substring(1);
db.get(id,function(err, doc) {
if (err) {
console.log('Error'+err.message);
res.writeHead(500,{'Content-Type': 'text/plain'});
res.write('Error' + err.message);
res.end();
} else {
res.writeHead(200,{'Content-Type': 'application/json'});
res.write(JSON.stringify(doc));
res.end();
}
});
}).listen(port);
As before the average response time has a linear correlation to the number of concurrent requests, keeping the requests that can be served per second pretty constant.
Conclusion
Node.js is roughly 20% faster, e.g. 509 requests/second vs. 422 requests/second at ten concurrent requests.
:)
:)
Tech Wind of Change ;)
