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.”
"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.
#javascript #node.js #programming
