Node.JS is a technology that has transformed JavaScript, which is familiar to all web developers, from a client-side scripting language to a general-purpose language that has a large number of application use cases.
How is Node good compared to other server-side scripting technologies?
At the heart of how Node works.js is asynchronous. 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.
What does this mean for your business?
- You can start your own project with relatively low costs for the server infrastructure.
- With the right architecture, this allows you to scale your business without investing a lot of money.
What does this mean for developers?
- If you don't have an understanding of asynchronous code and experience working with it, it will be very difficult at first. It is difficult to understand that some instruction written "upstream" may be executed much later than the subsequent ones, or it may not be executed at all. You will need to thoroughly study the concepts of callbacks, promises, async-await wrappers over promises, synchronous and asynchronous generators, and iterators. But it is very well structured thinking, allows you to take a different look at the program execution process and understand how much time a "normal" - synchronous-program wastes during waiting periods, and also learn how to save this time.
- A good understanding of asynchronous development approaches greatly increases the value of a specialist in the labor market and, accordingly, allows you to qualify for a higher salary.
Node allows you to quickly develop an MVP. Node has already developed a large number of packages with various functions. You don't have to spend time developing the basic functionality, but just focus on the business logic.
What does this mean for your business?
- The new product will be brought to the market faster (TTM will decrease).
- Less money will be spent on the development process, as it will take less developer hours to create the first version of the product.
- Hypotheses formed during the initial market research will be tested faster, product adjustments will be made faster, and funds will eventually be turned around faster. This is a very important characteristic for project investors.
What does this mean for developers?
- You don't have to reinvent the wheel on every project, which inevitably causes a lot of mistakes and makes the work boring, but you can work closely on tasks that are important for the project.
- Greater freedom in choosing an approach, building an architecture, and finalizing standard functionality that does not meet the requirements of the architect and/or customer.
- Node is built on the basis of the JavaScript language. As a result, this significantly increases the likelihood of developing full-stack specialists in the development team: front-enders who are well versed in the backend, or backenders who are well versed in the frontend.
Node.js is very closely related to JavaScript, the syntax and architectural approaches are identical, only the "bindings" (browser and server) differ.
What does this mean for your business?
- The development team will include specialists with a broader view of the problem, which means that the burden on management will be reduced.
- The development process will be more efficient, because it is always easier and faster for a person (a full-stack developer) to negotiate with themselves than with another person. This reduces the cost of communication between specialists.
- There will be fewer errors in the development process, because floating bugs often occur at the intersection of different development technologies with different data types.
What does this mean for developers?
- If you had to work closely with the front-end before, then you have a good understanding of the processes that occur with data in the user part of the resource, and, as a result, a simpler dialogue with front-end users.
- A good full-stack specialist is often more valued in the market than a good backend or frontend developer
- If you have enough time allocated for the development of the project, you can independently create both the front and back, thereby avoiding a huge number of "collisions", which often take a lot of time to solve.
Naturally, like any other technology, Node has its drawbacks.
What are Node's weaknesses?
- Node works very quickly with a large number of lightweight queries (such as those that do not require long data processing, complex calculations, etc.), but its performance significantly decreases if the requests require large server resources.
- The language and its execution machine are very actively developed, and sometimes it happens that individual packages are incompatible with each other or with the current version of the platform, which can lead to a complete failure of the project when updating the "engine" or a separate package.
Often, these shortcomings are used by opponents of Node in order to explain the reluctance to use it in production. Moreover, in confirmation of the first drawback, it is often stated that Node is single-threaded, so you can't write serious applications on it. At the current stage of technology development, this is completely wrong. First, there has long been an approach that runs multiple instances of the application and uses the Nginx web server as a load balancer. Secondly, in modern versions of Node, there is a built-in ability to create clusters of single-threaded processes, as well as special utilities for load balancing, automatic restart of processes, control over memory usage, etc.
The second disadvantage of Node is quite easy to compensate for. First, never specify the package version in the "latest" format, but specify the exact version of the package that the system is guaranteed to be compatible with. Second, to avoid losing access to the exact versions of packages in the public register, create copies of them in the local register. Third, do not update the platform or package versions in the production environment without first testing this bundle in the development environment (the statement is obvious, but it is often ignored).
will not be able to" overclock " Node in resource-intensive operations. But there is a solution: transfer operations that create a high hardware load to individual system components that are not written on Node, often even located on separate physical or virtual machines. There are various options for implementing this solution: microservice architecture, connecting modules written in other programming languages, etc.
As technologies that allow you to implement high-performance functionality, it is convenient to use: Rust, Go, C++.
Where is it convenient to use Node?
The technology is perfect for most projects implemented in the modern world of web development. The founders of almost any project at the start dream of having their product used by as many people as possible. Sample projects:
- online stores;
- video and audio hosting services;
- instant messengers;
- social network;
- any b2c products.
For all these directions, Node allows you to implement, as mentioned above, a quick start, and then fast, relatively inexpensive horizontal scaling.
Projects on Node
During the year leading up to writing this article, we applied technology to develop resources from scratch such as:
- freelance exchange;
- spare parts marketplace;
- realtime auction (API for the mobile app and web version);
- interactive system for creating media materials for - social networks;
- system for organising e-mail newsletters;
- assistant to the inspector of retail enterprises (API for the mobile app);
- patient assistant (API for the mobile app).
Top comments (23)
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.
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.
You people should stop confusing us please. We are still very young software engineers.
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.
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.
Yeah because compared to Java, C# or many others it's stronger and reliable (IRONY).
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.
Look into AssemblyScript then
@insidewhy you didn't get it, did you?
@insidewhy can you make an article how you configure ts to
exclude the crap from js?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
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.
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.
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
Pgmodule, 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.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.
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.
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.
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...
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....
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!
hahaahaha I love this post. same applies for php, ruby, python.. you are not saying specific at all
yes, once you know the hammer, every problem is a nail 😄
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-...