There are tons of languages used for backend, from most popular like PHP, Ruby, Python, Java or C# to as much esoteric (at least for the web) as Lisp.
So every backend developer thinks different.
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 backend reliability point of view this is a tough decision.
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 thanor 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.
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.
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.
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
Please share your thoughts below.
Please share this article.
Geoffrey is an experienced software developer and open source evangelist. When not coding he writes and talks about current technology trends, small business tips and developer productivity hacks. He is no coffee addict.
How to Become Efficient With a 5 Step Web Development Life Cycle
Top 15 Best Web Development Courses on Udemy in 2018
Top 7 Trending Web Development Technologies to Learn in 2018
Top 10 Best Coursera Courses for Web Developers
7 Reasons You Can’t Get A Junior Web Developer Job
Interview with Rob Percival – How To Land Your First Junior Developer Job