JavaScript was created years ago almost as an afterthought to be included in web browsers which is front-end.
If you are familiar with the language then Node.JS, a JavaScript framework for the back end, will not present much of a learning curve.
So why do I consider JavaScript for the back end an awful option?
There are tons of languages used for back-end, from most popular like PHP, Ruby, Python, Java or C# to as much esoteric (at least for the web) as Lisp.
Related: Top 15 Best Coursera Courses & Specializations
So every back-end developer thinks different.
However, I am sure there are many developers who consider JavaScript not suitable for the server. Below is the list of my reasons:
1. There is no standard approach
First, JavaScript, as a language, is really “loose.” Whether you’re self taught or learned from an online course, there can be dozens of different approaches.
It’s loosely typed, it fails silently, and it tends to allow some really bad habits to go unnoticed.
You can build a solid web back end in JavaScript, but you can also build a piece of crap held together with duct tape and string, and the management looking at it won’t be able to tell the difference until they try to scale, by which time it’s far too late to fix it.
Node.js is only a platform that runs JavaScript on server, but everything else, the frameworks, databases etc, have many options, some of them very immature and others still in early development.
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.
There’s the idea that anyone who knows JavaScript can do back end web development, and that’s just not the case.
It’s an entirely different discipline.
Even if your entire stack is JavaScript, you still need front end and back end developers.
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.
3. Maintainability
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.
None of that is to say that JavaScript is never the right choice. Just that as a rule, the further toward the back end, the more strict and rigid the platform should be in order to avoid serious problems, and JavaScript is none of those things.
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
JavaScript is weakly typed, so you don’t have to explicitly declare objects as a String, int, float, etc.
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!
Nobody makes the decision to write JavaScript for client-side code; they simply must, because every browser supports it.
On the back end, other languages (Java, PHP, Python, Ruby, …) offer advantages that JavaScript can’t.
Besides, the lack of a neatly packaged and standardized (for Linux at least) drop-in solution for the server to run JavaScript greatly holds you back.
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.
For many applications there are completely NO reasons to switch to JavaScript.
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.
Finally…
To wrap it up, I’d say that developers have emotions towards technologies and languages in particular.
Some can just hate (or in better terms refuse to accept ) JavaScript for the same reasons others love it.
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
- security,
- reliability,
- scalability and
- maintainability.
What do you think about JavaScript programming language being used on the server?
Please share your thoughts below.
Agree !