Node.js makes fullstack programming easy with server-side JavaScript
Web application developers are inundated with options when it comes to choosing the languages, frameworks, libraries, and environments they will use to build their applications. Depending on which statistics you believe, the total number of available languages is somewhere between 700 and 9000. The most popular—for the past nine years according to the 2021 Stack Overflow Developer Survey—is JavaScript. Most people think of JavaScript as a front-end language.
Originally launched in 2009, Node.js has quickly become one of the most widely used options among application developers. More than half of developers are now using Node.js—it is the most popular non-language, non-database development tool. It allows you to run JavaScript on the server side, which lets software engineers develop on the full web stack.
Node.js’s popularity has snowballed for good reason. Node.js is a fast, low-cost, effective alternative to other back-end solutions. And with its two-way client-server communication channel, it is hard to beat for cross-platform development.
Here we step through just a few of the features that help set Node.js apart from the crowd.
What is Node.js?
Node.js is a free, open-source, event-driven JavaScript runtime environment rather than a framework, library, or language. Based on Google Chrome’s V8 JavaScript engine, Node.js improves efficiency with its asynchronous, single-threaded, non-blocking I/O architecture.
By breaking software down into small pieces that run simultaneously, Node.js creates lightweight, fast, scalable applications. Node.js also allows developers to use JavaScript to create command-line tools for server-side scripting.
Because of its speed and multi-tasking abilities, Node.js has become a tool of choice for many major corporations and organizations. Among the primary industries using Node.js are education, healthcare, government, and finance.
Why should you use Node.js?
Developers that are already well-versed in other programming languages, frameworks, libraries, or environments might wonder why they spend the time to learn Node.js. The short answer is that Node.js speeds development and improves overall application performance.
Node.js is easy to learn
If you aren’t already using Node.js, then you have to invest the time to learn it. Application developers typically don’t have much free time, so if they intend to learn a new tool, it needs to be simple to pick up. The vast majority of developers are already familiar with JavaScript.
And because Node.js facilitates the use of JavaScript on the server-side, it makes it easier for front-end developers to quickly and simply build server-side applications, even if they have limited knowledge or experience with back-end programming principles.
Node.js also has extensive documentation libraries to help you learn more about using Node.js for your development projects.
Node.js is fast
When discussing speed, it is important to distinguish between the speed of application development and actual application performance. Node.js offers advantages for both.
Several factors contribute to Node.js’s speed advantage. First is the Google V8 engine, which powers lightning-fast conversion of JavaScript to machine code. Google’s dedication to the V8 engine assures developers that there will be frequent updates and ongoing performance improvements.
Node.js applications run much faster than other applications. Because Node uses an asynchronous, non-blocking programming model, processes can run in parallel rather than waiting for other processes to complete. The result is improved speed and performance.
Node promotes reusability of modules, which decreases development time. Moreover, with a large number of modules available from the community, developers can frequently find much-needed functionality without building it from scratch.
Node.js has single module caching
Another contributor to Node’s performance advantages is its use of single-module caching. The first time a module is requested, it is cached in in-app memory. Subsequent calls to the module access the cached version, rather than recompiling the module. As a result, Node.js applications load faster and are more responsive.
Node.js facilitates development of real-time applications
Node’s architecture makes it an ideal candidate for developing real-time applications. Node facilitates rapid data transfer between server and client with asynchronous operations, ensuring no lag between a user request and the server response.
Node allows multiple processes to run concurrently. Therefore, I/O operations are fast and responsive. This is particularly useful when configuring web proxies or building applications with a large number of simultaneous users, such as chat and messaging apps.
And don’t forget the V8 engine, which increases Node.js’s overall speed and performance, which are extra important for real-time applications.
Node.js scales easily
Scaling Node.js is simple. Node.js can support tens or hundred of thousands of concurrent connections. And Node.js applications can easily be extended by the addition of new modules.
Node.js relies on the cluster module, which is a load balancer that distributes processes across all available CPU cores. This allows Node.js applications to handle large numbers of processes quickly and efficiently.
Node’s modular architecture promotes scaling of development efforts. Development of individual microservices can proceed in parallel, reducing development time and facilitating modular addition of functionality to applications.
Node.js has workable streaming
Node.js data handling features rely on creating streams of data when it receives requests (such as HTTP requests) from a client web server. Using streams, Node.js breaks up modules into smaller pieces, which it processes individually, without keeping the entirety of the data in memory at once. Node.js can therefore process larger files faster and more efficiently, which is why it’s a good choice for developing video or live conferences.
Using streams has two primary advantages. First, it reduces the amount of memory needed to deal with large files. Second, it allows data processing to begin immediately on receipt of the first piece of data, rather than waiting until the entire package is transmitted.
Node.js is cost-effective
Node’s individual advantages when combined lead to cost savings:
- Because Node.js makes it easy for front-end developers with JavaScript experience to work on back-end development, you no longer need to have completely separate teams for the front end and back end.
- Develop applications faster with pre-built microservices from the community.
- Node’s more efficient usage of resources means that you can minimize an application’s server footprint
- Node’s scalability means that adding functionality is simpler and faster, reducing ongoing development costs
Node.js has a strong and active community
Because of Node.js’s growing popularity, a large and active community provides support and resources. Node.js fans are constantly available to respond to questions and assist you with issues that arise during development. And many Node.js developers are happy to share their efforts with the community at large.
One of the most useful community-based resources is the Node package manager (npm). npm is a huge online collection of published Node.js projects that you can install with ease. With npm, it is easy to find pre-built content and integrate it into your application.
Node.js can help you land a job
Demand for Node.js developers has grown almost as rapidly as interest in the tool. But there is still more demand than available developers. So adding Node.js to your arsenal makes you that much more desirable for prospective employers.
When wouldn’t you use Node.js?
No tool is perfect, and not surprisingly, Node.js does have some downsides. Despite its many advantages, there are applications where Node.js may not be your best solution.
If your application relies on CPU-bound processes
Computationally-heavy applications take a toll on Node.js’s efficiency and performance. This is because Node.js prioritizes high computation processes above other processes, which results in processing delays.
Node.js is attempting to overcome this concern through the worker threads multi-threading tool it released in 2018. The effectiveness of worker threads is still up in the air, and Node is working to improve the tool’s capabilities.
If you are concerned about data security
Some developers believe that the lack of default error handling in Node.js makes it vulnerable to exploits. Admittedly, Node.js, like any other programming language or development tool, is prone to attack. However, this concern is probably overblown.
Using programming and application development best practices and incorporating security into the development process can minimize security concerns. And, naturally, it is helpful to include application features that encourage users to build effective security practices, for example, multi-factor authentication.
If you are afraid of callback hell
Because Node.js is asynchronous, it can generate a large number of callbacks. When callbacks get deeply nested, you can enter what developers not-so-fondly term callback hell. Frequently, callback hell can result from poor programming hygiene rather than actually being an issue with Node.js, but you should be aware that it is a potential issue when using Node.js.
If you want a stable API
Node.js’s API is known for its lack of stability. It changes frequently and, at times, the changes have not been backward compatible (such as Node.js 8), causing extra effort for developers.
Take Node.js for a spin
Given its rise in popularity and well-documented speed and performance advantages for many popular applications, Node.js is a no-brainer for application development. Even the most skeptical developers should give Node.js a test run to see if it is worth adding to their development resources.
Tags: javascript, node.js
38 Comments
A shame imo. JavaScript is really an awful language that was hacked together over decades resulting in massive dumpster fire and smoldering carnage.
I can say the same for virtually any programming language.
I highly doubt you could show me a language that was hacked together so horribly. Do you have any specific examples (preferably some mainstream languages)? Here are just a few items that make JavaScript so “joyous” to work with lol:
https://javascript.plainenglish.io/13-javascript-anomalies-331833001bd2
—
> typeof(null)
“object”
> null instanceof Object
false
—
—
> typeof(NaN)
“number”
—
—
> NaN === NaN
false
—
—
let values = [1, NaN, 3]
> values.indexOf(1)
0
> values.indexOf(NaN)
-1
—
—
> console.log(-0)
-0
console.log(+0)
0
> (-0).toString()
0
> (+0).toString()
0
> +0 === -0
true
—
—
> Math.max() > Math.min()
false
—
Uhm, PHP definitely trumps JS when it comes to a badly designed language that got hacked together over years. I’ve used PHP for over a decade as well as JavaScript, and things have improved with PHP 8 just like they have improved with TypeScript.
Frankly I wouldn’t use JavaScript except for actual scripts (e.g. internal tools) and even though I actually like PHP 8 I wouldn’t use it except for a WordPress website (where WP makes using PHP worth it), and I’d stick with better designed modern languages like C#, Swift, Rust, etc.
So you’d recommend making websites in C#, Swift, Rust, etc.? Okaaay…
Nothing compares to JS for inconsistency. PHP improved dramatically with 7 and even more so with 8. WordPress is bunk. A framework like Laravel is what makes it worth using.
For some reason, the newline formatting didn’t paste in. Here’s where I got most of these:
https://javascript.plainenglish.io/13-javascript-anomalies-331833001bd2
—
> typeof(null)
“object”
> null instanceof Object
false
—
—
> typeof(NaN)
“number”
—
—
> NaN === NaN
false
—
—
let values = [1, NaN, 3]
> values.indexOf(1)
0
> values.indexOf(NaN)
-1
—
—
> console.log(-0)
-0
console.log(+0)
0
> (-0).toString()
0
> (+0).toString()
0
> +0 === -0
true
—
—
> Math.max() > Math.min()
false
—
—
PHP, Perl, Fortran, VB, … all on the TIOBE top 50.
And from the next 50, the ones I have personal experience with: Applescript, Bash, PostScript. I’ll also mention C and Assembler, while not “worse” in terms of design, they would be totally inappropriate for any project where you are considering Node.js.
That is definitely not true. C++ and C#, for example, are result of long research and well thought through before being shipped.
Totally agree. JavaScript started as a hack and was unfortunately adopted for several reasons one being it was probably the language that web page developers that weren’t programmers learned and made so popular.
A good analysis.
Node.js has advantages both for software developers and consumers of various services.
It enables faster or even low-code development of micro services using JavaScript.
There is a learning curve especially when your goal is to create a production ready API or back-end application.
Vaclav’s statement may be had some degree of validity 15 years ago but JS has evolved so much. Javascript is a great language and there is a reason why it is the most widely used one for the web and beyond.
Yes, but that reason is not what you think. The fact that JavaScript support was added to every major browser is the reason it’s so widely used (IMO, in spite of it’s endless shortcomings). It was at the right place at the right time. Nothing more.
no. that is not tru. JS hasnt really evolved much.
Pardon me, I was referring to TJ, not Vaclav.
Javascript ES6 is not bad. Use Classes and modules so the code becomes readable. TINYMCE is an example of really ugly coding.
Spot on. I needed to develop an easy and quick way to create a dynamic link from Ms sql to a web GIS site in the intranet environment and nodejs came to the rescue. Few lines of code and voila. No middleware needed.
reply to the first comment, java script has actually not changed much since the first version, even the most recent concepts, like classes existed in some form before (it’s just using the prototype chain) the only important change is the use of async await, by the way, there is. o callback hell of any kind, that was years ago, now u just use await, await, await, instead of 3 nested callbacks, your comment is just provocation, or do you actually have an example ?
what you are saying applies to PHP, confused maybe ?
IMO js has the cleanest syntax of the most popular languages, with python.
JS is the best language which was designed in 10 days. It has many, deep design flaws. It’s possible to write great stuff in JS, but its design makes it also really easy to write horrible, hacky, working code.
Before node.js, at least those bad snippets were only on the frontend. Now, bad developers can also write horrible code on the server side!
Since you asked for examples, I’ll just mention `1 + ‘2’`, `1-‘2’`, `[]+[]`, `[]+{}`, `{}+[]`, `{}+{}`, which are just a few of the hundreds of WTFs hidden inside JS.
I really don’t know how you could claim that JS has a clean syntax. Which other languages do you know?
“hidden” is a great choice of words given that these examples never really see the light of day. doing something like {} + [] is like trying to add the suffix ‘ly’ to a noun: an idiotly example.
If it’s stupid, then the language should notice it, and throw an exception or at least write a warning.
But JS almost never does, and it always tries to return something, even if it’s nonsensical. It makes it much harder to detect bugs, because the weird behavior could have been caused by an operation 5 steps ago. Sane languages try to detect stupid stuff ( e.g. 1 + ‘2’) and force the user to make a clear decision, instead of making implicit, unexpected conversions. Weak typing is simply horrible.
@ “Weak typing is simply horrible”
“typing” as used in coding and scripting languages is horrible. It should be “type-ing”. Get it?
I wonder why we bring up flaws in languages that we never ever use in production. In what world do you ever need to do a numeric add between an empty object and an empty array? What were you expecting would happen if you did a numeric addition of two empty arrays?
Just an addendum. You can write really terrible code in any language. Unfortunately this is not a problem with the language but with the developers.
“You can write really terrible code in any language.” Yes. But in other languages (e.g. Python), there is at least some correlation between working code and clean/readable code.
“What were you expecting would happen if you did a numeric addition of two empty arrays?” : well, in many other languages, “+” on arrays means concatenation. So I’d expect [1,2] +[3,4] to be defined, and equal to [1,2,3,4]. So []+[] would simply be []. And not an empty string.
“why we bring up flaws in languages that we never ever use in production” How can you be sure? Some JS libraries return a string representation of a number instead of the number (don’t ask me why). And then you get weird results, depending if you use this string in additions or subtractions. JS will never complain, but will happily return 1 + ‘2’ = ’12’ and 1 – ‘2’ = -1.
Just one more JS WTF: sorting an array of numbers sort them lexicographically.
Uh you guy’s need to review what the term full stack implies. Node.js is in no way full stack.
front end – yep – it’s a solid choice, far from perfect, yet solid.
backends? there are so many flaws and shortcomings that I am still baffled how any serious tech organisation chooses Node for backends – it was worked around rather than head-on, a scripting language with practically no standard library and endless dependencies (Python too BTW), a concurrency model that isn’t truely concurrent and a hell of callbacks to somehow work with it. So many security advisories stemming from having so many dependencies. I can go on.
Golang, Kotlin/Java, Rust are probably better suited for backend projects IMO. but I’m not here to change anyone’s mind – I get the emotional attachments to a language you love working in… I honestly do.
“Do one thing and do it good” is the unix (and SOLID’s) way of thinking, and that kind of frames my thoughts on Node and JS for backends.
BTW pretty sure even Deno – the creator of Node – rejects the idea of it being a good choice for backends: https://mappingthejourney.com/single-post/2017/08/31/episode-8-interview-with-ryan-dahl-creator-of-nodejs/
Prototype pollution is an inherent flaw in Javascript’s design and it makes it almost impossible to secure templates in Node. Lack of truly private variables and methods is ok on a client because any engineer knows that clients aren’t supposed to be trusted, but on a server this creates an almost infinite attack surface that is almost impossible to defend.
The only solutions that would fix this permanently are things that would break node’s compatibility with regular javascript and that is something that calls into question the usefulness of a language like node because the main justification for its existence is interoperability with standard javascript.
Since I guess most very active programmers and developers these days are in their 20’s and 30’s they may not know the full history of what they’re dabbling in and working with.
So here’s a little snippet for you and, that I used 25 years ago. MS had server side JavaScript in 1997 in it’s classic ASP and IIS 3.0+ web server. Shocking eh?
You could build a whole application using JavaScript on the server and on the client side too just by including the javascript.inc file that was embedded into the server’s O/S.
Programming languages has a history going all the way back to the 1950’s and some things in use today like NoSQL for example have been around since the 1970’s where big business and govt’s had rejected it. Now in the mid 2010’s it was all the rage and most people thought it was an innovation of the time, little realising it has been around for 50 years.
To be a good programmer/developer you should know the history of what you are indulging in and you’ll probably find that your toolset is not as 21st century as you think and in fact you may be working with something that got rejected or dismissed as being problematic 50 years ago.
Having said that, I am not aware of many JavaScript based apps that were built in ASP 25 years ago, but it did help to encourage C++ programmers who were prevalent at the time and who also steadfastly refused to indulge in this new ASP/HTML scripting thingy, calling it and us who did it, ‘pretend’ programmers.
Thank you,
Form an old ‘dinosaur’ programmer of some 40 years standing. 🙂
Node.js isn’t a language. Using this, you increase the amount of dependencies, moving part, complexity, and ultimately maintenance costs. When will professionals learn about this kiss principle. This isn’t hard.
You also keep talking like nodejs is the ONLY way to implement async logic server side…
Use “techempower” to watch actual data on the performance. Nodejs isn’t anything special at all. To me it seems more like inexperienced programmers gets attracted to it because of articles like this one, selling them nodejs as the ultimate solution, which them give them a bias because of the time invested and career path they took. This is a dangerous cycle.
Callback hell? I had to read the date on when this was wrote. I honestly thought it was a blog post from years ago.
I can’t even remember the last time I even used a callback other than event listeners..
I lead off interviews with “Is JavaScript a good programming language?” If they answer yes, the interview ends.
Only a complete fucking moron would voluntarily code anything in JavaScript, easily the worst programming language I’ve ever used.
The language is so bad, Microsoft asked Anders Hejlsberg to try and fix it. And now the industry has TypeScript.
Google realized it was fucking garbage, so now we have Dart.
JavaScript’s performance is horrific, so now we have WebAssembly.
The reason JavaScript is used on the backend is your average HTML programmer is too fucking stupid to learn a real language. It’s really that simple.
You probably also reject anyone who is not your race, gender, religion or other bias. So worse than bad programming languages is bad managers. And that is you. A good manager would realize that there are use cases to do different things in different languages. That is why there are so many. And I’m grateful we have options because writing a bunch of bloated code in what you call a “real language” isn’t always the best option.
Managers who stick to only one solution should be fired! Usually bad apps out there are a result of bad management with poor decision-making. Rarely the developers themselves.
“I’ve had a great idea! Let’s take the worst language ever designed and put it on the server!”
Watching non-JS devs talk about JS is the real dumpster fire. And quite a predictable one at that! I wish I had time to pick apart and respond to what some of you are saying. Sure, JS gives you plenty of rope to hang yourself with. Go and show me another language that had to run in an evolving manureshow of browsers like Netscape Navigator and the older IE’s. Yup, it’s a tough origin story. It takes discipline to write it well because of that. ES6 was a gigantic leap, and it keeps getting better. Sure, devs have opinions. But rather than regurgitate what you’ve heard about JS (and run to google a bunch of obscure quirks — TJ, I’m looking at you), you’re really better off learning how to write it. One language that compiles to browser code, server code, and native code? Its ubiquity is its greatest strength. Take the good parts and run with it!
The “active ecosystem” is the main reason I dislike Node. The instinctual reaction of JS developers seems to be “there’s this really great library that does things just sliiiightly differently from how I want it. Rather than contribute to and improve it, I’m going to create my own sliiiightly different version of it.” So we end up with 20 mediocre libraries that all do the same thing rather than one or two really amazing ones.
I’m following Deno with bated breath and hoping that it’ll fix the numerous pains that Node has given me.
The “If you are afraid of callback hell” argument seems to have been copied from an article written 10 years ago. This is not an issue anymore with async/await being available in all major browsers since 2017, or when using TypeScript.
Did an actual programmer currently doing programming actually write this article?