Why Developers Hate JavaScript, and Why They’ve Got It All Wrong
If you’re just getting started in web development, you may have noticed that developers in other software fields like data science, embedded systems, or even back end web developers, just love to talk sh*t about JavaScript. It’s so common, in fact, that you might start to wonder if you’ve picked a terrible language to learn. Maybe you should ditch web development altogether, or learn Java or C++ instead?
As in any field, software can be competitive and chalked full of people with their own opinions of the best technology and practices. No matter which language is your favorite, you’ll never escape the occasional developer who tells you it’s terrible. Still, JavaScript gets an unnerving amount of hate in the software community. As a developer who loves JavaScript, I’m a little personally offended, but as a daily JavaScript user, I understand where most of these complaints are coming form. I also understand why they’re wrong.
Here are the most common complaints I hear about JavaScript and why they’re not so bad after all.
JavaScript is only suited for the web, making it a one trick pony.
It’s true. JavaScript was built to run in a web browser. Brendan Eich famously wrote the first version of JavaScript in just a few days while working for Netscape in the early 90’s. It was built to address the lack of a standard language that could be used in web browsers, and it did so brilliantly.
I don’t know if you know this, but there have been quite a few technological advancements since 1995. JavaScript is no exception. With the introduction of the runtime environment Node in 2012, (and younger brother Deno more recently), JavaScript escaped the captivity of the browser long ago. You can find it on web servers, Raspberry Pis, robots and running machine learning algorithms.
Oh yeah, and JavaScript is still the only language that runs in a web browser. So while it’s dipped its toes in nearly all fields, it still holds the champion belt for making web applications dynamic, interactive and feature rich.
JavaScript is bloated and slow.
Spoiler alert: JavaScript is slower than C. That probably doesn’t surprise anyone, since C in nearly all implementations will be faster than any high level language. What may surprise those developers who complain about JavaScript’s speed is that Node will often outperform other dynamic languages in its class, like Python and Ruby.
In fact, according to The Benchmarks Game, Node can outperform Python by several orders of magnitude. But let’s take a step back for a second and put this whole fastest language thing in perspective. For the vast majority of code written on a daily basis, we’re talking about milliseconds here. Add a variable network latency in the mix and these stats go right out the window. In short, unless you’re fine tuning optimized solutions for some serious scaling, these differences are negligible. The advantages gained in language flexibility far exceed the milliseconds lost in execution.
JavaScript’s type coercion makes code unpredictable.
This one is a popular grievance. First, let’s understand that JavaScript is a dynamically typed language. That means that variable types are not declared, but are rather interpreted at runtime.
JavaScript, like any dynamically typed language, doesn’t require us to label a variable as an integer. Rather, the interpreter will read the variable’s value at run time and figure out that it’s an integer.
People can (and will) debate the advantages of statically versus dynamically typed languages all day long. The real complaint here is about how JavaScript will coerce a variable type by making some assumptions about the code.
The reason this is a problem is not lost on JavaScript developers. As programmers, we want to be explicit about our code and it’s annoying that, in a situation like this, the language is taking such blatant liberties. The reason it’s not that big of a problem is because, for many years, JavaScript has had a solution for it.
Using a strict comparator, instead of the loose one above, prevents JavaScript from coercing any types. That means it won’t make assumptions about your code. Yes, this also means that, as developers, we must be explicit about checking the types of variables our functions are receiving as arguments. We must also be diligent about writing exceptions and handling potential errors. Isn’t that the exact level of control people are complaining about not having in JavaScript…? Oh, and if you really want to use a strongly typed language, TypeScript is one that compiles to JavaScript.
JavaScript can’t handle Object Oriented Programming
You might hear this one from Java or C# developers, as those are two languages that very much adhere to the OOP paradigm. Everything in Java is written in a Class, with strict encapsulation of program state and functionality. Neatly divided lines, like a bento box that separates your carrots and hummus — that’s the way Java developers like to code.
A simple Java class might look something like this —
public Class MathFunctions {
int add(int a, int b) {
return a + b;
}
}The Java developer who wrote it might hate the fact that it could be written as a free floating function outside of a class in JavaScript.
function add(a, b) {
return a + b;
}JavaScript, unlike heavy OOP languages, doesn’t require code to be encapsulated in classes. Functions can be written anywhere, variables can be freely declared after they’re called (thanks to hoisting) and code can be scattered all over the file and still work as expected. Is that the best way to write JavaScript? Absolutely not. Just like dynamic types, these language features require us to write code more explicitly and declaratively. They also allow JavaScript to be easily adapted to a functional programming paradigm, something not so easily done in Java or C#.
That does not mean, however, that JavaScript can’t follow an OOP paradigm. With the language features introduced in ECMAScript 6, JavaScript has clean syntax to support classes, encapsulation and inheritance. While it may operate differently than other OOP languages under the hood, (like using prototypal inheritance and using closures for private variables), the functionality is very much supported in the language.
JavaScript is useless without depending on heavy libraries like React.
With the introduction of NPM came the ability to quickly and easily add packages to your code. Need a solution for handling different time zones? npm install moment is a one-command solution to implement a plethora of functions that have already been tested and proven effective. As developers, we should be careful about reinventing the wheel. If someone has already written a viable solution to our problem, why write a new one?
Critics of JavaScript will likely point to the list of package dependencies of a program. As each dependency installed has its own list of dependencies, each of which has its own that needs to be installed, that list can grow quite large. The temptation to look through the NPM registry for solutions and blindly import them into your code is so strong that a novice JavaScript developer may have a fifty-line program with many thousands of lines of dependency code.
JavaScript is modular, with a robust community of developers adding new packages every day. The ability to quickly import these packages is an asset that saves time and keeps code DRY. It’s up to us, as developers, to add only the packages we need and to balance, as we always have, coding efficiency with program efficiency. There are situations where using a heavy package to save several days of coding is preferable. There are also scenarios where we need a trim, home-grown solution to drive an efficient, speedy program. JavaScript packages give us the ability to make that choice on a day-to-day basis.
You’ll never escape the naysayers or the programming gatekeepers who absolutely assure you that JavaScript is a terrible, useless language. You can, however, see through the particularly one-sided complaints and show them how JavaScript is a versatile, robust and feature-full language.
