By John Jenson
These were my thoughts when my co-worker told me he was planning on abandoning Java and adopting Node.js on the backend. I couldn’t believe it, and I thought he was seriously misguided. I had been developing applications using Java for over 10 years, and in my mind there was no reason to consider anything else. Java was still king. It had the greatest market share of all languages in use, and it’s performance was amazing. Java could even outperform C++ because of the genius of its JIT compiler. Why would anyone choose anything else?
If you are a Software Architect with a bias for Java, let me give you some other factors to consider before ruling out Node.
Factors In Favor of Node
This observation isn’t so much about the Java language itself. I would argue that the syntax is understandable and clear, and the documentation of the core language libraries is quite good. Where things start to go wrong is in the complex build tools, web configurations and frameworks. Developers just want to code. They don’t want to spend hours pouring over boring documentation about how to correctly setup a web.xml, a spring application xml, or how to configure an osgi container using apache karaf. They want to get started solving problems right away.
Node has strong appeal to new developers, because everything you need to know, you can find in one place, npmjs.com, and the documentation for most of the libraries can be summed up in a few paragraphs in the project readme. This means that you can be up and running in just a few minutes, rather than a few hours or even days.
I spent 5 years of my career building a large banking app that was built on Java. As the application grew, I watched the number of classes grow steadily over the 5 years. By the end of the project we were well over 3.5k class definitions. The interesting thing is that at least half of our class definitions didn’t have anything to do with the core logic of our program. Most of the classes were bean, pojos, or dtos; these are essentially objects that were created just to hold data so that it could be processed by the real application. One of the primary complaints that I hear about Java is all the “pageantry” that is necessary for doing simple tasks. In the end, what this amounts to is a lot of extra code to write, and that means more time to write.
Less Lines of Code Means Less to Maintain
A common mistake in software development is to think only about the cost to build an application, but the cost to maintain it, over the life of the application, can easily be more costly than the cost for the initial build. When considering the total cost of ownership of software, consider that if the same application can be written with far fewer lines of code, there are fewer places for things to go wrong.
Compile Time Checks Can Be Replaced with Unit Tests and Linting
Static Typing and Interfaces Don’t Have to be Abandoned
Like it or not, Java is slowly becoming a niche skill that is harder to recruit for. If you don’t think this is an important factor in choosing a technology, think again. Many college grads are no longer coming out of school with a desire to use Java. I personally noticed the shift about 5 years ago. Today, recruits coming out of school are far more likely to be interested in using Node than Java. For me, that fact will prove to be very problematic for Java’s future. If the future generation isn’t interested in it, then it is only a matter of time before it becomes a past relic.
Node’s Efficiency is Hard to Beat
The fact is that although Google’s V8 engine that powers Node is quite impressive, it will never quite have the raw computational speed that Java has. But what Node lacks in computational speed, it makes up for with efficiency. In fact, because of it’s non-blocking IO, and its single event loop architecture, it can easily process 5 to 10 times the volume that Java can. If you don’t believe me take a look at my post about Node performance, Performance: Java vs Node.
Nodes performance is so impressive, that very notable companies have switched to Node. Netflix, LinkedIn, Amazon, Github, Ebay, Paypal, and Google, are all on the list. If scaling is a primary concern, Node should be primary contender.
A Non-Blocking Ecosystem Matters
The key offering that gives Node the ability to defeat its contenders is its ability to do non-blocking IO. The interesting thing is that Java can do non-blocking IO as well, but the problem is that Java didn’t have non-blocking IO capabilities until it’s 4th major release, which was 6 years after its debut, way too late. Furthermore because async programming in Java is awkward and clunky, the non-blocking api never really caught on.
Fast-forward to today, and now Java is in its 8th major release. It has 20 years of mature libraries, but the vast majority of them aren’t written using non-blocking IO. Consequently what you get is a language that is capable of non-blocking IO, but an ecosystem that doesn’t lend much support for it. For example, database IO is a huge part of what most web applications do, but Java’s JDBC standard for connecting to databases is a blocking spec. How is someone supposed to build a non-blocking backend if JDBC doesn’t allow it?
The Java community has attempted to implement an event driven architecture similar to Node with Netty and Vertx, but the success of these frameworks will always be limited because non-blocking IO isn’t much more than an afterthought, Java will continue to trip over itself when it comes to non-blocking architectures.
Summing It All Up
Node is a serious enterprise contender, and leading in scalability. If you are looking to get to market faster with your products, recruit talent more easily, and scale your systems further than ever before possible, Node.js might be exactly what you need.