The Three Big Lies About JavaScript

Richard Kenneth Eng

Published in

JavaScript Non Grata

5 min readMay 15, 2016

Every lie is two lies — the lie we tell others and the lie we tell ourselves to justify it.
~Robert Brault

There are three big lies that JavaScript fans tell me again and again…

Lie #1

JavaScript is the most misunderstood programming language in the world. People don’t know how to use it properly and that’s why they get into all kinds of trouble.

This is a lie because there is nothing special about JavaScript. It is your garden variety imperative/procedural programming language with a smattering of functional programming (FP) capabilities tacked on and a controversial “object-oriented” feature called object prototypes. What is there to misunderstand?

Basically, the blame for all of JavaScript’s problems is placed on the people using the language: they’re ignorant; they’re lazy; they’re inured to the way programming is done in Java or Python. But what are they ignorant about? Functional programming?

Why then aren’t people screwing up when using other FP languages such as C#, Clojure, Dart, Elm, Erlang, F#, Julia, Haskell, Scala and Scheme? Functional programming is a fairly well-understood paradigm in the IT industry. So what makes JavaScript especially problematic in this regard?

Maybe people are ignorant about object prototypes. Read all about What JavaScript’s Object Prototypes Aren’t. They aren’t good for proper software engineering. They aren’t a particularly high level of programming abstraction. Prototypes are basically glorified hash tables, quite low level, and what I call the “bricks” for real object-oriented programming (class-based OOP). People may not understand how to use object prototypes, but why would you bother to learn how to lay bricks? It’s not really worth the effort.

Yes, I get it. Prototypes are flexible. They don’t have all the ceremony that’s behind class-based OOP. In that sense, they’re fun to use. But they don’t scale well for larger applications and that’s why people jump straight to classes. If prototypes were such a useful pattern, you’d see it adopted everywhere else, because prototypes can be simulated in class-based languages, just as classes can be simulated in prototype-based languages. And that’s what JavaScript programmers don’t get.

Lie #2

Asynchronous programming is a key strength of JavaScript. Well, let’s first understand why asynchronous programming exists in JavaScript at all.

For graphics user interface (GUI) programming, an event loop is de rigueur, whether it’s in Windows, or X Window, or OS X’s Cocoa, or the web browser. They all process user input events asynchronously. Does that mean that asynchronous programming is also a strength of C++ or Objective-C? Event loops (with asynchronous libraries) have been used in Python and Perl and Tcl. I suppose they’re all strong at asynchrony, then? (I laugh when people use the non-existent word “asynchronicity.”)

So JavaScript uses the event loop and asynchronous processing to support the web browser user interface. This is supposed to make it a great language?

And now, this model of computing has made Node.js quite popular on the server side where it’s used for non-GUI-related programming, i.e., for high-performance concurrency. Node is obviously useful for many applications, but it’s hardly taking over the world of concurrency. Recent stories show Node’s limitations. And yet, this is supposed to convince everyone to use JavaScript.

The event loop has been described as “a poor man’s concurrency.”

Node proponents like to throw up the same few enterprise examples again and again (PayPal, Netflix, Walmart, Uber, etc.). For every Node example, there are — what? — hundreds of Java examples? Java has proven itself countless times in the enterprise. That’s why it’s practically the industry standard. Node has yet to prove itself. We don’t know how many corporations have tried using Node and gave up on it. We have no idea what the real-world success rate of Node projects is. For an enterprise, choosing Node is still a risky proposition.

I confidently predict that Go will displace Node in the future once it has grown its ecosystem of frameworks and packages. Its trajectory is undeniable.

Languages like Go and Erlang/Elixir can easily outperform Node in most concurrency scenarios. The event loop/async model is not sustainable over the long run. We should be attracted to using real concurrent languages if maximum performance is our goal. Why compromise with JavaScript?

Lie #3

JavaScript is the most popular programming language in the world. Is it really? There is a huge difference between a language that is widely used by default and a language that is widely used by choice.

Remember, in every other application domain besides the web, developers are not held hostage to one language. We ignore this at our own peril.

JavaScript is the only language native to the web browser, so it is the most direct means of writing a browser application. Most developers, however, despise the language and if they really had a choice of a better language, they’d jump to it. You can see this is true if you search the web (forums, social media, websites, etc.) for opinions about JavaScript. There are numerous long lists of WATs and WTFs for JavaScript that you don’t find for any other language, with the possible exception of PHP. What we know for sure is that the web is popular, not that JavaScript is popular.

Most of the major language ranking indices do not show JavaScript as the most popular. Not even second, third or fourth. IEEE Spectrum says #8, PYPL #5, TIOBE #7, CodeEval #6. Redmonk uses Github statistics which contain a greatly inflated number for JavaScript, precisely because web applications in any language must have at least some JavaScript to work in the browser; there is no choice. So Redmonk cannot give a meaningful ranking for the JavaScript anomaly; otherwise, Java is the most popular language.

User surveys such as those from StackOverflow also contain similar selection bias. When you have little choice but to use JavaScript for web development, how can you claim it’s a popular language? (Thankfully, however, transpiled languages are available to us.)

It behooves us to remember that for all other application domains (e.g., network servers, games and graphics, mobile, desktop, IoT, cloud, etc.), there are plenty of language choices. The web domain is singularly unique. (At least, it is until WebAssembly finally arrives.)

The Truth

Let me be very clear: JavaScript is not a good programming language for software engineering. JavaScript 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. What kind of a language is that?!!

Weak typing is the Achilles’ Heel of the language for proper software engineering. While it makes writing quick simple scripts for the web browser very easy, it works against you when you’re writing larger applications that require safety and reliability. This is why most major languages are normally strongly typed (not to be confused with statically typed). This is very, very important.

Weak typing and its consequent freewheeling coercions demonstrate a complete lack of language discipline. This explains a good deal of the numerous WATs and WTFs that plague JavaScript. You can find many online lists of these “warts” but I’ll give you just a few of them here:

I’m working very hard to get ECMA TC39 to fix the language’s problems: JavaScript: The Next Generation. Alas, I do not hold out much hope.