The State of Node.js & JavaScript for Backend Development

In 2009, a new technology made its humble beginnings in the vast universe of backend development.

Node.js was the first legitimate attempt to bring JavaScript to the server-side.

Today, you'd be hard-pressed to find a web developer who hasn't heard about Node. Even JS beginners.

Following its inception, it has split communities, triggered forum wars, and brought many to despair.

Think I sound dramatic?

Do a quick Google search. You'll land on a gold mine of controversy. Some arguments you'll stumble upon:

"Whatever happened to the axiom “Use the best tool for the job”? JavaScript on the server side is NEVER the best tool for the job."

Some even sound poetic:

"Callback hell is real
Debugging is a bitch
JavaScript was not made for server-side
[...]"

And some are more... straightforward:

"Node.js is cancer."

For this post, I thought it was time to set the record straight about Node.js and JavaScript as a backend language.

Today I'm going to discuss:

• The current state of Node.js

• Its best use cases

• Its limitations

• What we can expect from Node moving forward

The state of Node.js as backend

Before we get into it, let's just remind ourselves what Node.js is exactly:

It's a JavaScript runtime built on Chrome's V8 JS engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.

Now I know the intro painted Node as a developer nightmare. Truth is it's become widely popular. But don't take my word for it:

Stack Overflow's developer survey for 2017 shows that it's currently the most used technology by developers.

It's also the language with the fastest growing popularity over the last five years, whereas languages like C# and PHP are losing steam. JavaScript itself is also on the way up.

How can we explain the rapid shift from the original backlash to the mainstream acceptance for Node.js and JavaScript as a backend language?

To put it simply, Node has outlived the "just a fad" period and entered a solid maturity state. It has built a strong and ever-growing community & ecosystem around itself. In fact, its package manager, npm, is now the largest software registry on the web.

Node.js not only revolutionized backend web development but also contributed to bringing performance to the frontend by bringing serious engineering to the client-side. It's also played a part in the expansion of the overall JavaScript ecosystem and the improvement of modern JS frameworks such as Angular, React or Vue.

Over time, it has proven wrong many of the preconceptions people had in its early days:

JavaScript & Node.js are notoriously difficult to debug.

→ You can leverage the same debugging experience you have in the frontend using node-inspector which packages Chrome's native Dev Tools.

Folks at Joyent also know a thing or two about advanced Node debugging & profiling: their DTrace universal debugger was released a long time ago!

You can't use it for enterprise-level server applications.

→ Such engineering can be achieved with Node.js: it just doesn't have as many built-in tools taking you by the hand. Big players such as Netflix, PayPal, Walmart, and Yahoo! have all used it. More on this later.

JavaScript is a dynamic language, so you don't get a static pass from the compiler.

→ This is true. However, tools like TypeScript and Flow emerged to provide that kind of language security. Google's Closure Compiler can also do the trick here.

JavaScript was not made for server-side.

→ Well, JavaScript was already on the server at the same time that Netscape built JS into their browser, back in 1995! It has been a frontend typecast because, well, it took complete monopoly over it.

And the list goes on & on.

So let's just jump into some of the best use cases & limitations, to get a better idea of Node's positioning.

JavaScript for backend: best Node use cases

So why should you even consider Node.js as backend in your stack?

General advantages & characteristics

Let me fire some quickies for you:

• It's highly probable to assume you're already running your frontend with JavaScript. In that case, code universality across your stack is a great advantage to keep in mind.

• Tools like webpack help reuse code on both ends and stay coherent across all system levels.

• Going with a JavaScript full stack, you can write a web app that renders both on the browser and the server seamlessly. That's exciting.

Some have seen this as a con for Node.js, arguing that it forces you to choose JavaScript all the way. It's not entirely true, as you still can use the right tool for the job, granularly.

Let's say you need to do video encoding, you won't go searching for an esoteric Node.js library: you'll simply call proven tools in the command line from Node. Or if there's already a Python library that can do the complex calculation you require, you can spawn a micro-service and call these functions through a REST API.

• The async/await feature completely changed the way we write asynchronous code, actually making it look and behave a little more like synchronous code. Supported by Node.js since v7.6, this feature came as part of the solution to the infamous Callback hell.

All of the above make Node.js great for the following use cases.

Use case 1: Real-time applications

Collaborative apps (Trello, Google Docs), live-chat, instant-messaging, and online gaming are all examples of RTAs that benefit from a Node.js architecture.

These applications function within a time frame that the users sense as immediate and current. Node.js specifications are the solution for the low-latency needed for these programs to work efficiently.

It facilitates handling multiple client requests, enables reusing packages of library code and the data sync between the client and the server happens very fast.

Use case 2: Single page applications

SPAs are web apps that load a single HTML page and dynamically update that page as the user interacts with the app. Much of the work happens on the client side, in JavaScript.

Even though these are an awesome evolution in web development, they come with some problems when it comes to rendering. This can negatively affect your SEO performance for instance. Server-side rendering in a Node.js environment is a popular option to solve this.

Use case 3: Scalability

Node.js won't ever get bigger than you need it to be. The beauty of it is that it's minimalist enough to customize depending on the use case. Performance-wise, that's key.

Even its name emphasizes that it's made to assemble multiple small distributed nodes communicating with each other.

Node's modularity allows you to create small apps without having to deal with a bloated, overkill ecosystem. You choose the tools you need for the job and then scale as needed.

This scalability is not free from complications though, and if you're not careful, Node.js can become... dangerous.

Node.js backend limitations

Put bluntly, Node.js allows you to easily shoot yourself in the foot. Configuration & customization come at a price, and if you're inexperienced or undisciplined, you might lose yourself—or your client.

Contrary to a more conventional approach, you create the structure that supports your backend. That involves a lot of decision-making, meaning that you have to know what you're doing and where you are going if your project scales.

With other languages like Ruby and its well-known framework Ruby on Rails, for instance, we were used to the paradigm "convention over configuration." These traditional frameworks took developers by the hand and shun some light on the safe path.

With Node.js this goes head over heels. More freedom is given to developers, but the road might get dark and scary if you make the wrong decisions.

And then you'll find out that "callback hell" is real indeed.

This doesn't mean that you can't build bigger server applications with it, but you should always keep these factors in mind.

Even the creator of Node.js, Ryan Dahl, eventually realized the limitations of the system before leaving to work on other projects. He was very transparent about it:

"[...] I think Node is not the best system to build a massive server web. I would use Go for that. And honestly, that’s the reason why I left Node. It was the realization that: oh, actually, this is not the best server-side system ever."

The preconceptions mentioned earlier were all true at one point in Node.js' short lifetime and still are to some extent. It has matured and grown enough that you are able to work around them if you take the time. The tools the community has to offer enables you to do pretty much anything.

Popular JavaScript backend tools

Not so long ago, if you thought about putting together a JS full stack, the first thing that came to mind was the MEAN stack (MongoDB, Express, Angular & Node).

It's still a relevant group of tools today, but the JavaScript ecosystem now has so much more to offer, on the frontend as much as the backend, that you can't limit yourself to this.

Here are some of the more popular Javascript backend frameworks in 2018:

• Express.js is still the most popular Node.js framework out there. It's a fast, unopinionated & minimalist web framework. It evolved quickly because it's made simple & straightforward. It's probably the one closer to Node.js' basic ideas of a lightweight system with a modularity approach.

• Meteor, on the other hand, uses pure JavaScript and Node.js inside a way bigger architecture. Meteor is an ecosystem in itself which may be good for building more complex server applications. However, its use may become harder if you want to do something that isn't built-in.

• Sails.js is a real-time, MVC framework. It was designed to emulate the MVC pattern of Ruby on Rails but with support for modern apps requirements. It does this through data-driven APIs with a scalable, service-oriented architecture.

• Koa.js was crafted by the team behind Express. Marketed as the "next generation web framework for Node.js," it's a smaller, more expressive, and more robust foundation for web applications and APIs.

• Strapi is a Node.js API framework with headless CMS capabilities. This one is quite new, but it has already proven itself to be one of the most advanced Node.js content management frameworks. The word-of-mouth is pretty good on this one, so keep an eye on it!

There are many more to explore, so I'll drop a few real quick: Nest.js, Hapi.js, Socket.io, Mean.js, Total.js, Derby.js & Keystone.js.

Moving forward

The point of this article was not to get to an ultimate conclusion on whether Node.js offers the best backend environment. Nor was it to tell you that you should use it.

And I surely won't get out there and say that it's any better than other popular backend languages such as Java, C#, C++, PHP, Python, Go or Ruby.

I guess the aim here is to paint a grey area between the black & white opinions I've been reading on Node.js and JavaScript as a backend language.

Whether you like it or not, Node.js is visibly here to stay. ;)

You should never think of any framework as a silver bullet that will magically resolve all your problems. Node.js is simply another tool in the immense universe of web development. It'll get the job done extremely well in some situations, but will be a pain in others.

After that, it's every developer's job to carefully think about the right stack for any new project. It's important to know all your options and not to write off any alternative from the get-go.

Snipcart, for instance, runs on a .NET architecture, which also has its fair share of naysayers. Why did we choose it?

It was right tool for the job, at that moment in time.

Here's hoping this overview helps you make up your mind about Node!

What are your thoughts on Node.js? And JavaScript as a backend language? Experiences you want to share? I'm sure a lot of you have something to say about it, so feel free to start/join the discussion in the comments! If you've enjoyed this post, please take a second to share it on Twitter.