The Three Big Lies About JavaScript

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

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

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

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

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.

JavaScript Non Grata

Just say no to this abomination

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store