10 things developers love about JavaScript – and 10 things they don’t

It was 30 years ago today, Sgt. JavaScript taught the web to play. Well, not exactly but close enough. The programming language began in 1995 as a project in the depths of the browser maker Netscape. It lived under several different names including Mocha and LiveScript before it finally rolled out into the wild with the name JavaScript.

The aspirations were not grand. The folks at Netscape suggested a developer could tuck a little bit of logic into a web page to, say, check some form elements or maybe make something flash. At the time, the web was filled with text and simply including an image in a web page was considered sophisticated.

Some three decades later, JavaScript reigns as the dominant way to deliver software to the end user. Web pages have turned into web applications with just a bit of text, lots of images, and even more software logic.Along the way, JavaScript has grown faster, sleeker, more capable, and, well, much more complicated. Some love this. They revel in the power, the sophistication, and the elaborate infrastructure that lets us solve so many of the world’s problems with just a click or a tap.

Others aren’t so blind in their affections. They know that complexity brings bugs and power brings more dangerous bugs. They’ve lost weekends to problems caused by JavaScript and they’re willing to spend the whole night talking about it if you trigger them.

To celebrate the long and storied history of the language, here is a list of many different ways we love the language and just as many reasons we pretty much loathe it. Many of them are tangled up with each other because the same features can be both wonderful and dangerous, helpful and problematic, good and bad.

Love: Isomorphic code

Long ago, the code that ran in the browser was written in JavaScript and the code on the server was some mixture of Java, PHP, ColdFusion, SQL, C, and several other options. The rise of Node.js makes it possible to run the same code in the browser and all of the different layers of services and microservices. That may not happen as often as we imagine, but it can be very useful to move functionality from the server to the browser and back again to meet the needs.

Not love: Not-so-isomorphic reality

While the same code may run everywhere, it doesn’t mean that life is simple. Developers continue to speak of specializing in either the front end or the back end, the client side or the server side. In theory, they can just write the same code but in practice there are so many other differences in the frameworks and APIs that it’s hard to take advantage of them. The developers have to specialize so they can learn these differences.

Love: Standard syntax

Large portions of the coding world have converged upon the syntax of the C programming language. Curly brackets to delineate the blocks. Semi-colons at the end of each line. Et cetera. JavaScript’s embrace of this very common and practical approach means that many people can switch gears pretty easily between C, C++, Java, JavaScript, Swift, Go, and many others. Yes, there are differences, but at least the basics are welcoming.

Not love: Punctuation

The biggest competitor to JavaScript today is Python, and the developers of Python took a very different approach to punctuation. There’s no need to tire out your pinky finger hitting the semi-colon or curly bracket keys because Python does just fine without them. Yes, Python users often spend lots of time trying to count invisible white space characters, something that can be onerous, but at least their code looks simpler and cleaner on the screen.

Love: Closures

These clever mechanisms for juggling the scope of variables make it possible to write compact code that’s easy to share. The language does the work of sorting out and preserving references to the data. Much of today’s modern asynchronous code relies on closures to keep the data straight.

Not love: Closures

Closures are complex and sometimes confusing. When they go wrong, they can produce maddening results that are all but impossible to debug. Many memory leaks happen because closures keep massive data objects from being cleaned up, all because of some dangling reference that will never happen.

Love: Frameworks

There are dozens of major JavaScript frameworks and easily hundreds with a smaller following. Web application developers can save many hours by leveraging some feature-rich options like Angular, React, Vue, Svelte, Node.js, Deno, Nest, Bun, and many, many more. It’s an embarrassment of riches.

Not love: Choosing a framework

Many choices is not a bad problem to have, but it’s still a challenge for many developers who are starting out on a project. Finding the right framework can be hard work and a significant hurdle. The explosion of frameworks means more atomization of the developer community. Instead of coming up with a few well-supported approaches, it seems like many developers are creating their own takes. I love creativity — until I must choose just one. It gets worse if an organization embraces more than one. I worked at one place that went all-in on React, or so they thought. There was one major service, though, that was written years ago in Angular. No one wanted to tackle problems with its code. No one was really up-to-speed in Angular. So it just sat there and stagnated.

Love: Living language

The ECMAScript committees keep adding new features and significant syntactic expansion. There are very nice shorthand symbols like the spread operator (...) or the pipeline operator (=>) that make code concise. The developers adding these features are ensuring that the language morphs to accommodate modern usages and modern data structures.

Not love: Keeping up

Is that combination of punctuation marks a typo? Or is it a new feature? Many developers can be frustrated simply trying to understand JavaScript from a different era. And by “era,” I mean just a few years. For every developer overjoyed to find a fancy new operator that shortens the code, there’s another developer scrambling to ask an AI to explain just what’s going on.

Love: Code running in my browser

Long ago, people had to install software by copying files and running local code. Now, most of our software is “installed” by opening up a web page. It’s so much easier. And the capabilities of web applications have exploded. Jobs like picture editing or even movie editing were once only viable when executed as native code in the OS. Now, they run smoothly in a browser, all thanks to better just-in-time compilation.

Not love: Code running in my browser

Why did my machine slow to a crawl? Was it the browser tab I just opened? Or was it one left over from this morning? Is someone mining Bitcoin in the background? Or is it something worse? There’s so much going on in the modern browser that it’s just mass confusion as a bazillion spare cycles are devoted to rendering a web page that no eyes will ever see.

Love: Dynamic typing

Both new and experienced developers enjoy the flexibility of using variables that keep track of the type of data on their own. Yes, there are good arguments for using strong typing that’s defined by the programmer. For those who need it, there’s always TypeScript, a superset of JavaScript with a type system and type-checking. The rest of the time, JavaScript developers enjoy declaring a variable and letting the back end handle the details of its type.

Not love: Dynamic operations

Alas, the simplicity of dynamically typed variables comes with a dose of confusion and strange rules that don’t always make sense. The plus sign (+) is overloaded and that can produce mysterious results in the edge cases. Standard equations like adding two integers may be entirely predictable, but adding objects to strings can produce surprising results that can vary between versions and compilers.

Love: Type conversion

Let’s say you want to compare a string with an integer in it to another integer. Why should you, the programmer, have to do anything more than say “if x > y…”? The suckers with their strictly typed languages will need to handle all of the conversion themselves. They’ll have to add some extra lines and declare a few more variables just to get it done. JavaScript does it all for us in the background. Voilà.

Not Love: Type conversion

Type conversion is great — until it suddenly does something at the wrong time without telling you. The expression “02” > “1” is false because the comparison is done lexicographically. The values are compared as strings. But “02” > 1 turns out to be true because JavaScript magically converts the “02” into an integer just to be helpful. It does all of this without telling you because it doesn’t want to bother you — or help you debug your code by identifying that moment when things went wrong.

Love: Clever hacks

JavaScript is a descendant of C and some of the fun ways to write simple code persist. The language will automatically handle type conversions in ways that allow us to write very simple and effective code. The if-then-else statements don’t just insist upon boolean values. They can make decisions with integers, strings, or objects too. The result can be very short and simple code.

Not love: Truthiness

While boolean expressions should be some of the simpler forms of computing, they can get strange and programmers need to memorize many of the oddest edge conditions. For example, the if statements will make decisions even when the variable doesn’t evaluate to a boolean true or false. The various integers, strings, arrays, and objects have different values and sometimes they can be confusing. The empty string is false but the empty object is true. The integer 1 is true but the integer 0 is false. All we can do is try to memorize these rules — and hope they don’t morph between versions.

Love: Transpilers

Even if you don’t love JavaScript, you can live well in the JavaScript realm. There are hundreds of transpilers that will convert almost every language. Some are just extensions or variations to JavaScript like TypeScript or CoffeeScript. Others will completely convert entirely different languages like Python, Java, C#, SQL, and many more. Some relatively ancient languages like Lisp or Cobol can live on to run smoothly and quickly with modern optimizing just-in-time infrastructure.

Not love: Nomenclature

Is it JavaScript? Or ECMAScript? Does Oracle own the trademark? Or is it really owned by the people who built it? Or maybe it has become a generic term? Is there a connection with Java? What am I supposed to type in my legal contract? Should I just call it Node? The questions are many and the answers are all indefinite. So pick a name and try to stick with it for the same paragraph, OK?