Node: A Compelling Choice for Java Developers

If your development background is anything like mine, then you probably think writing server side code in JavaScript is a terrible idea. JavaScript likely seems like an immature language that lacks basic object oriented capabilities, and you may have even gotten burned by horribly written JavaScript front-ends that were insufferable to maintain. If you are a Software Architect with a bias for Java, let me give you some other factors to consider before ruling out Node.

Considering Node…

If you’re like me you’ll think twice before giving up compile-time checks, and static typing, and you can’t imagine developing a large complex app without the ability to enforce design patterns using interfaces and abstract classes.

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?

The reality is, there is more to Node.js than just being a really fast JavaScript interpreter, and there is more to consider than just the raw computational speed of Java. When you take a closer look, you will see that Java’s raw computational speed alone isn’t enough to beat the efficiency of Node.

Factors In Favor of Node

JavaScript is Faster to Learn

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.

JavaScript is Faster to Write

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.

Because of the dynamic nature of JavaScript, it doesn’t have all the bloat that is required by Java. A lot can get done with a lot less lines of code, and that means quicker time to market.

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

Many organizations have test coverage requirements for their software. Unit testing is a good practice for all software regardless of the technology, and once your unit tests are in place, they have the ability to expose far more than simple compile time checks could reveal. This makes the argument for compiler checks less relevant. Furthermore, JavaScript linters are quite good at pointing out additional issues that even compilers don’t check for.

Static Typing and Interfaces Don’t Have to be Abandoned

I have learned to live without interfaces and abstract classes, but for those that still desire it, they can get all the benefits of node by adopting TypeScript or Flowtype. Both of these languages are supersets of JavaScript that use transpilers to perform all the same checks of a type safe language before compiling into JavaScript. These languages are fantastic languages that run seamlessly on Node.

JavaScript is a Ubiquitous Skill

One beautiful thing about JavaScript is that everyone knows it, regardless of his or her backend programming experience. 3 years ago I worked in a Java shop with only Java developers. Our recruiting needs only allowed us to consider candidates with significant Java experience. Today my recruiting pool includes developers from all different backgrounds. There are talented web developers everywhere that have been using JavaScript in one way or another since its introduction in the 90s.

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?

On the other hand, JavaScript made blocking impossible from its inception, so everything by definition is non-blocking. All socket IO, database reads, file operations are non-blocking. This is key to making an event loop architecture work, and Node provides over 50k modules all written in the async style, ready to use.

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.

If your development background is anything like mine, then you probably think writing server side code in JavaScript is a terrible idea. JavaScript likely seems like an immature language that lacks basic object oriented capabilities, and you may have even gotten burned by horribly written JavaScript front-ends that were insufferable to maintain. If you are a Software Architect with a bias for Java, let me give you some other factors to consider before ruling out Node.

Considering Node…

If you’re like me you’ll think twice before giving up compile-time checks, and static typing, and you can’t imagine developing a large complex app without the ability to enforce design patterns using interfaces and abstract classes.

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?

The reality is, there is more to Node.js than just being a really fast JavaScript interpreter, and there is more to consider than just the raw computational speed of Java. When you take a closer look, you will see that Java’s raw computational speed alone isn’t enough to beat the efficiency of Node.

Factors In Favor of Node

JavaScript is Faster to Learn

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.

JavaScript is Faster to Write

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.

Because of the dynamic nature of JavaScript, it doesn’t have all the bloat that is required by Java. A lot can get done with a lot less lines of code, and that means quicker time to market.

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

Many organizations have test coverage requirements for their software. Unit testing is a good practice for all software regardless of the technology, and once your unit tests are in place, they have the ability to expose far more than simple compile time checks could reveal. This makes the argument for compiler checks less relevant. Furthermore, JavaScript linters are quite good at pointing out additional issues that even compilers don’t check for.

Static Typing and Interfaces Don’t Have to be Abandoned

I have learned to live without interfaces and abstract classes, but for those that still desire it, they can get all the benefits of node by adopting TypeScript or Flowtype. Both of these languages are supersets of JavaScript that use transpilers to perform all the same checks of a type safe language before compiling into JavaScript. These languages are fantastic languages that run seamlessly on Node.

JavaScript is a Ubiquitous Skill

One beautiful thing about JavaScript is that everyone knows it, regardless of his or her backend programming experience. 3 years ago I worked in a Java shop with only Java developers. Our recruiting needs only allowed us to consider candidates with significant Java experience. Today my recruiting pool includes developers from all different backgrounds. There are talented web developers everywhere that have been using JavaScript in one way or another since its introduction in the 90s.

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?

On the other hand, JavaScript made blocking impossible from its inception, so everything by definition is non-blocking. All socket IO, database reads, file operations are non-blocking. This is key to making an event loop architecture work, and Node provides over 50k modules all written in the async style, ready to use.

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.