The Speed Race Is On: Vert.x and Node.js

Vert.x and Node.js are similar in some ways, and different in others. One such difference is that Node.js only allows you to write code in JavaScript whereas Vert.x allows you to code in Java, Groovy, JavaScript, Ruby and eventually as the Vert.x team expands support for the following is planned: Clojure, Scala and Python. So what happens if you could have as good or better performance (a very simple benchmark – check out the comments though!) than Node.js and you can write your code in your preferred language which may or may not be JavaScript?

One of the benefits of Vert.x is that it uses the JVM which over the years has been fine tuned by highly skilled people. Of course one of the arguments of using the JVM is that people might not trust the current caretaker of Java that is Oracle. With Node.js though you are currently dependent on Google’s V8 (and you might make the argument for Joyent as well). Either way there is corporate backing to V8 and Java so for each project there is really no way around that.

Ideally, the ability to code in your preferred language (or mix and match) and use mature libraries for the JVM is a big win for some developers. Node.js however is maturing quickly and has several solid libraries out there now (Express, Socket.io and Mongoose are three that immediately come to my mind and there are more).

Something that struck me right away is that using more cores on your server is dead simple with Vert.x, a command like this is what you can use:

vertx run server.js -instances 4

Have a look at this post from Tim Fox on the Vert.x Google Group regarding the concurrency model. Now, check out my article on building a clustered ATOM server with Node.js. Also, clustering on Node.js is currently in the experimental stage as noted by their docs.

Tim Fox mentions in another thread: “Also vert.x scales far more easily than node.js. For example if I create a simple webserver it will scale across available cores just by specifying the -instances command line param (see the front page of the web site). With node.js you have to manually start N instances, and then implement glue code (cluster module) to farm out requests between the instances.”

Here is another interesting tidbit from Tim: “As mentioned above, one advantage of vert.x over node.js is it doesn’t force you to run everything on an event loop, so you can more easily use legacy blocking APIs (e.g. JDBC). You can’t do this with node afaik.”

Working with both Vert.x and Node.js I’ve found building a project to be quicker to build in Node.js along with a little easier debugging. With Vert.x there are more pieces you have to mix in, see my post here. As time moves on though things will get easier. Right now you’ll find that there are more articles and books out there for Node.js.

This is just the tip of the iceberg of course. Each project is relatively young yet gaining a lot of attention now. Regardless of which one you choose the great thing is these kinds of projects are pushing the envelope now of how new apps can be built in the future. As developers, we win either way. The thing to keep in mind is to use the right tool for the job. I like both of these projects and will be closely following them.