This post seems to be an ad for some sort of development contracting company, which disgusts me, but I feel compelled to respond to the points anyway because their content is interesting independent of the ads. My position is that Node is a terrible choice, and I will rebut these reasons.

Easy learning curve

This paragraph assumes you already know frontend. Yes, it’s easier to learn backend JS than another backend language if you know frontend JS; it’s not easier to learn backend JS than another backend language if you don’t know frontend JS. (Not all developers are full stack)

The V8 JavaScript engine has been proven to be at least twice as fast as any other server-side language out there, including Java and PHP, while using far less memory than any of them.

This argument is bizarre. I have seen that Node is faster than other dynamic langauges, but have you forgotten that compiled languages exist? I would be astonished if you could find any evidence that Node is faster or uses less memory than say, Go (the backend language we use at my job).

One Language

Much like the previous point, this assumes the perspective of a developer who already knows JS and nothing else. If you know only JS, you might prefer to use that language everywhere. But let’s say you know two languages: Go and JS. Using Go would mean using different languages on the frontend vs backend of this particular application, but using JS would mean using different languages on the backend of this project vs your experience in other projects - neither side has the “One language” advantage.

Open Source and Community Developers

This is just silly as all relevant programming languages are open source. A closed source programming language would be a joke.

Scaling Up

The number of companies using it is irrelevant. The ability to scale is relevant, but it’s not a distinct benefit; it’s a consequence of being more resource-efficient, which almost any compiled langauge should beat Node’s ass on due to the intrinsic performance advantage of compilation.

Ease of Deployment

I have no idea what this is even talking about. I thought this was about web backend, where all languages can be deployed in the same way.

A great thing about JavaScript frameworks in general, and especially Node.js, is that they can be used across a variety of different platforms: desktop, mobile, and web.

This only applies to frontend. No one’s saying you shouldn’t use JS for the frontend of a web app as you have no choice.

Security

There’s no evidence that applications written in Node are more secure than applications written in another language such as Go or Rust, and the content of this point has nothing to do with “Security” anyway.

Ability to Use RESTful APIs

Any language can implement and use a REST API.

Lots of Modules / Plugins

It’s true that Node has one of the biggest ecosystems of available libraries, but it’s not the only one. Python, Go, and Ruby all have sufficiently large ecosystems that it seems impossible to find a task for which there isn’t a preexisting library.

I agree that using JavaScript increases the chance of participation. I released a few versions of Thai word breakers in different programming languages. One on node.js is the most popular. 8 people contributed to the JS-based project compared to 2-3 people in other programming languages. However, JS has a downside too. In 2017, @iporsut and I made an experiment to compare Thai word breakers that we created. JS version running time is 15X of the Rust version. Even by comparing with another dynamic language, the Julia version is faster than the one in JS.

I created a website using node.js in 2014, and it is still running. The performance is good. However, I have a few regrets.

• We had a very hard time by install this project on other team members who use Windows 10 because we didn’t know how to build a Bcrypt library.
• Recently, I have to fix the project without adding any new feature because Express.js was changed, MongoDB was changed, and some packages that I used were abandoned.
• It was a small project so I wanted to keep the session storage in RAM, but I can’t since I ran 4 node.js processes. Now the project requires Redis as session storage, which causes more troubles for team members, who don’t familiar with GNU/Linux, Docker, or WSL.

Welcome on Lemmy.

I appreciate your opinion and post but the reason against it are much stronger, IMHO

• Mainly for Developing API’s, Backends and Servers or WebApps, this can be seen as pro and con. Depends on what you want to archive. For simple CRUD application this is too much.
• Uncaught exception or error event in JavaScript code, this also includes security issues.
• Excessive memory usage, which may result in an out-of-memory error.
• Unresponsive application, possibly looping or hanging.
• Poor performance.
• Crash or abort in native code as well as unexpected application behavior or functional issue.

More reasons.