DEV Community

Cover image for Why you should choose Node.js for developing server-side applications

Why you should choose Node.js for developing server-side applications

Matvey Romanov on November 20, 2021

Node.JS is a technology that has transformed JavaScript, which is familiar to all web developers, from a client-side scripting language to a genera...
Collapse
 
mindbroker profile image
anros-p

This kind of post is a perfect example of why people should look for authority sources.
It is full of misleading and outdated information.
"In addition to non-blocking I / O, this allows a server-side application on Node.js can handle much more client requests per unit of time than a similar application developed on most other server-side development technologies" -> This was true a decade ago but since most languages caught up and are in fact overperforming compared to Node.
Just an example benchmark like a thousand others : https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=composite

"A good full-stack specialist is often more valued in the market than a good backend or frontend developer" -> This is once again a completely wrong assumption. Just look at the comparisons out there, again there are hundred of them.
A good backend engineer is as good as a good frontend engineer. Fullstack developers, while being more versatile are often jack of all trades, master of none. So in the end suitable for smaller projects.

"You can start your own project with relatively low costs for the server infrastructure." -> This is true with almost all current languages/frameworks out there used for server side development.

"With the right architecture, this allows you to scale your business without investing a lot of money" -> Nodejs is currently one of the worst scaling technology out there. cf again benchmarks.

I'm not saying that Node.js is not good or does not suits your business needs, it exists, has is pros/cons and is very flexible.
Being a javascript based environment it will make it available to more developers but will also inherits the issues from the language and runtime itself.

Overall stop selling wrong assumptions to your readers without any fact, it simply is misleading for most inexperienced software engineers out there.

Collapse
 
standelethan profile image
Ethan Standel

I'm a huge defender of server side JS but this article just starts out in falsehoods. I came here to call it out but you did a better job than I was going to do, so thank you.

Collapse
 
eugenejerry profile image
Eugene N.I.

You people should stop confusing us please. We are still very young software engineers.

Collapse
 
ozzythegiant profile image
Oziel Perez

No thanks, I'm moving away from interpreted languages and using Go and C# for backend. It's really not that hard to host them if you dockerize them or use Passenger along with Nginx on a cheap cloud server. ASP.NET Core and Go's Fiber framework (an Express.js lookalike) are among the top tier frameworks on the TechEmpower benchmarks.

Collapse
 
gevik profile image
Gevik Babakhani

One of the less obvious advantages of Node.js is when you throw TypeScript in the equation, suddenly you have a strongly typed language which serves both the frontend and the backend. This unified technology stack makes development with a large team much easier than when you have different technologies for backend and frontend.

Collapse
 
joelbonetr profile image
JoelBonetR 🥇

Yeah because compared to Java, C# or many others it's stronger and reliable (IRONY).

Collapse
 
insidewhy profile image
insidewhy • Edited

TypeScript is a much less verbose and more expressive language than C# or Java, as long as you configure lint rules to exclude some of the crap it inherited from JavaScript it can be pretty nice. Although it would be nice if TypeScript could be compiled to bytecode and pick up 64 bit integers along the way.

Java is a pretty annoying language, typical Java apps are filled with boilerplate. Kotlin runs on the JVM also and is so much nicer.

Thread Thread
 
marcusmmmz profile image
marcusmmmz

Look into AssemblyScript then

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

@insidewhy you didn't get it, did you?

Thread Thread
 
bias profile image
Tobias Nickel

@insidewhy can you make an article how you configure ts to exclude the crap from js?

Collapse
 
bulsatar profile image
bulsatar

How many more "frameworks" do you need before you recognize that your language of choice is garbage? So the myriad of frameworks that wrap around JavaScript, the node framework that wraps around those, then the nvm framework because npm is garbage, then you have the other systems lol like webpack because your frameworks around frameworks around frameworks do such a complete and horrible job of managing themselves and the output they produce.

Embracing the future should not mean inheriting a giant pile

Collapse
 
bias profile image
Tobias Nickel

I think it is in most cases just much easier to wrap something and make something new in JS. There is basically no way to "wrap" something around the j2ee framework, no people make sonething very new: apache spark or spring.

Collapse
 
jeremybradbury profile image
Jeremy Bradbury • Edited

You mentioned resource-heavy being a limitation and you mentioned C++ being a good alternative.

But you didn't mention that NodeJS has a well built C/C++ API that can handle resource heavy operations.

That last point is often missed when you look at the benchmarks barely favoring Golang over NodeJS as the top 2.

Collapse
 
bias profile image
Tobias Nickel

in my opinion "native modules" should be removed from node.js. it is often a pain whe some dependency all of a sudden want to have a c compiler. A better example to run "native code" is tensor flow. Python and node.js do the same there, tensorflow is running in a process and app languages communicate with it via grpc.

also, look at postgres drivers. the Pg module, made with cpp and used by knex and almost every ORM, is loosing hard in benchmarks against a pure JS implementation in the 'postgres' module.

Collapse
 
jeremybradbury profile image
Jeremy Bradbury • Edited

C & JS are the 2 most popular languages which Node is built.

Having an issue with a c compiler is a system config issue common for windows developers, easily solved. Similar to complaints about TS transpiles happen too. On other platforms it's never been an issue... Unless the module has bugs including missing compatable hardware in the package.json

C allows a direct API to the hardware, it's damn near 1s and 0s. That & cross-platform, OS native compilers which work on every machine, is why C is still so highly used.

The idea that you should remove an API to the core language that NodeJS is written is ridiculous to me. And your rationale was "sometimes I have compiler issues"? I respect your opinions, but I starkly disagree.

A C compiler built the NodeJS binaries on your machine (including most of the core modules like fs & http). The text is smaller than binary, the compiler is native to the machine, which is the reason open source became a thing and source is often transmitted then compiled.

To be clear about my original comment, using FS is literally the same API your OS has to the filesystem. Linux kernels are written in C, so is the Kernel of windows & Mac & Android & iOS.

Java, PHP, RoR, Go also use their own modules to access files, and they're just not as efficient as the very well written C based, FS binary (even used by the module loader), mostly taken from popular Linux kernels. Then when you set production flag on a linux machine, FS removes itself from the equation asking the Kernel directly for files.

So again, it's fast because it's written in C and extends the API to Javascript. Not just the core modules of node can be written in C. It's not just a JS framework, it's an OS hybrid that plays nice with (polyfills) other OSes.

Thread Thread
 
bias profile image
Tobias Nickel

I see the compiler problems more with incompatiblities with docker, inside docker there is linux, outside is a mac or windows.

"hey let me try the feature in a script" "ohh win32.module is not a file" run the script in docker, but it should access this external file,.... of cause you can make it work, but it is a pain in the ass.

When talking pure speed, I do not argue against c. And yes, you propably have the highest potential speed using it. The problem is the pretty slow n-api. In between the two languages, objects and values need to be serialized and unserialized. I would estimate, that a task would need to have a runtime of at lrast 1 or 2 seconds, until the overhead of the N-API will pay off.

Accessing specialized hardware, such as I2C devices, works today with pure js modules. and on embedded devices yes, I do not complain about native modules. these modules don't need to run in vm/docker or various OS.

Thread Thread
 
jeremybradbury profile image
Jeremy Bradbury

You can pass primitives across in the napi in fact it's highly recommended, which is why it works great now in concert with typescript but it was more of a challenge with raw JS.

Again 98% of core NodeJS is in C/C++ making it run super fast.

Saying the N-API is slow is just false as that would also slow down core modules like fs and https.

Honestly, and I know it sucks to hear this, but most of the issues you are complaining about are related to binary C/C++ modules that aren't tested or maintained on windows devices. So they have bugs related to the one platform.

If you use WSL you're still using a windows c/c++ compiler inside docker. With WSL2 you can add actual linux kernels.

But none of that matters if you use only well-tested modules that are 3rd party and you properly test all your first party code on windows.

I feel your pain, I know the grumbles of poorly maintained c/c++ modules. I have to do linux server engineering not only to web clients but an UnrealEngine Windows game. I can't use a Mac or Linux to develop on because I need the game running from built source, in the editor on a gaming quality windows machine connected to a local dev server.

But just like you don't have any problems with the core Node modules, the same should be true for any well-tested and well-written c/c++ module.

Collapse
 
johnkey profile image
INDERA SHAH

for me why we not use them all...exp : today use node.js after this mybe 1 mouth or 1 year waiting another Develop like you all find solution to project like jvst/aws/azure/npm/react/ and /inthera.key/ (i try to make 1) ,😅 get improvement and upgrade. we use and Run a New one...
info :if want share something new ideas visit my Github.page only make for me after them let me take control github.com after my public JavaScript to Open resources 2020...

Collapse
 
joedotnot profile image
joedotnot • Edited

TL;DR; This article should be replaced with "Why you should choose <Insert your Fav Server side Framework here>"; I get that node is your fav, but my fav is C# and somebody else may be java, or whatever else....

Collapse
 
louissa profile image
Louis Sawyer

Good article! I figure you can discover extensive data here
computools.com/software-developmen... This is about programming development dangers and how to keep away from them. This is additionally an essential guideline for inside site review in programming development, which influences traffic. Try not to thank!

Collapse
 
nicolasdanelon profile image
Nicolás Danelón

hahaahaha I love this post. same applies for php, ruby, python.. you are not saying specific at all

Collapse
 
bias profile image
Tobias Nickel

yes, once you know the hammer, every problem is a nail 😄

Collapse
 
bhaviksadhu profile image
Bhavik Sadhu

Thanks for this article it's very helpful, Node.js is a great choice if you're looking to invest in something large and innovative. Well i have article like yours devdojo.com/techavidus/10-reasons-...