So every back-end developer thinks different.
1. There is no standard approach
It’s loosely typed, it fails silently, and it tends to allow some really bad habits to go unnoticed.
It is hard to pick a fixed set of all these parts and be sure that everything will work as needed.
From back-end reliability point of view this is a tough decision.
2. Lack of deep understanding.
It’s an entirely different discipline.
They are different jobs with different requirements.
Once again, this becomes a concern when management, who doesn’t understand the difference and only sees the cost savings of less expensive developers, puts the wrong person in a position they aren’t prepared for.
With Node.js, developers have to design what is called “full stack”, which in very simple terms means whole backend is controlled by you.
That creates much more work and points of failure for unskilled developers and requires much more knowledge.
There are all the technical concerns.
Depending on what you’re doing, these can be more or less important, but as a rule, anything you expect to deal with a lot of traffic needs to be multithreaded.
Anything that needs to work the first time, every time without fail, is faster and more reliable if it is compiled, safer and more robust if it has strong compile-tile checking.
LESS people know Node.js than ASP.NET or Python or Ruby or Java or PHP.
In long term this can make huge maintainability issues.
That’s one of the reasons Node.js is much widely used by startups who are more or less sure of their team and are more open to new web development technologies.
4. Poor Language design
That’s good for a quick prototype.
In a large production project however, this can bite you in the ass if you make the wrong assumption about a type.
It was designed to be a light, breezy scripting language for the web browser. As such, it was made to be flexible and extremely forgiving, with weak typing and crazy-ass coercions.
It doesn’t even have a proper integer type nor a proper array type.
In front end web development i.e. the client-side, this is often not only acceptable but also preferable.
On the server side, however, this is strongly frowned upon, and that’s why the languages that dominate that side are more strongly typed and rigid.
What’s good for client-side isn’t always good for server-side.
5. Developing in Node.js is a pain!
This solution would then need to be picked up by the major hosting companies and added as part of their product offerings for it to really take off. If that happens then I think you’ll find that it might explode into the back-end server space.
Related: Best Udemy Courses
Many websites (blogs or e-commerce) have several tested and tried solutions in PHP, Java, etc. that can be deployed in hours and become production in weeks.
No one would switch to Node.js in such a case, so as a back end developer I am correct that it is unsuitable for what I do.
To wrap it up, I’d say that developers have emotions towards technologies and languages in particular.
No justification needed here.
It is possible to write working code in any language and platform, but languages and platform still matter and have a cost you will pay during the lifetime of your application, in
- scalability and
Please share your thoughts below.