10 things we hate about JavaScript

Endless library reloading, cool tools that piggyback on JavaScript success, spaghetti code -- alert(‘Over it!’)


10 things we hate about JavaScript

We love JavaScript. Static Web pages were cute back in 1992, but now our Web pages sing, dance, and otherwise entice users with seductive code written in JavaScript. We write JavaScript every day, on almost every platform, for almost every purpose. But that doesn't mean we love everything about it.

Here's a list of 10 things we've come to hate about the hippest new old language on the Web. Maybe not hate with the same degree of animosity we feel toward, say, the scumbag who rootkitted my server just to send out a billion spam messages. Maybe it's mere disdain. You can read the list, examine your own feelings, and decide for yourself.

Andy Fitzsimon via Flickr

Too many nested curly braces

Sure, it's cool to pass a function as a parameter and even cooler to pass a function that contains its own function that calls a parameter, but at some point all the nesting is insane. No one has time to count all those curly brackets and parentheses to figure out where your code unraveled or how your whiz-bang solution solved some other shortcoming of JavaScript. Yet what do the programmers do? They could give the methods names and pass them by name but that would be too simple. Instead they nest the methods in one big spaghetti pile of bracketed and parenthetical code.

cyclonebill via Flickr

Browser bouillabaisse

Yes, the headaches from browser inconsistencies were greater in the past. Things have certainly gotten better. But still, each browser uses slightly different mechanisms for almost everything it does with your code, with standards remaining at least in some measure an ongoing quagmire of vendor vs. vendor ire. There are still big differences in little things like how white space is parsed. These drive programmers crazy -- and drive us to use libraries like jQuery to make our code work wherever it might be executed. And as we all know, libraries are great, except when they're not.


The DOM is off in la-la land

JavaScript was designed to make it easy to manipulate Web pages, but it runs in some space separate from the page itself, leaving you to feel like you're constantly programming the Web through some API. Every time you want to perform some action or render an effect, you need to search for some DOM object. Someone clever created the $ function and added it to the libraries to make it simpler, but this should be part of the language itself. It shouldn't be off in a separate world because each browser treats these DOM objects just a little bit differently.

The jQuery Foundation via Wikimedia

People don't even program in JavaScript anymore

If you look at much of the code, it relies heavily on jQuery or some other library to find objects and manipulate lists. The code has little to do with JavaScript the language because it's just a list of library calls that are strung together. Why not just change the name to jQuery and get over it?


Endless reloading of libraries

Despite all efforts to use cacheable versions of standard libraries, most websites don't. As a result, a significant percentage of Web traffic is reloading the same JavaScript libraries again and again. How many coal cars could be saved with the electricity spent to ship these libraries around? How much time does humanity waste waiting for these libraries to load?


New feature gridlock

The committees meet. Drafts are circulated. People talk. But then progress is very slow. No one wants to break the Web, but everyone wants new features. The problem is, they don't want the same features. So everyone just talks. Round and round. Tell us again, when exactly is that next version of ECMAScript expected to drop?

mike krzeszak via Flickr

Too many cool tools crowd-surfing on JavaScript

At first glance, there's something great about languages like CoffeeScript or Dart that compile down to JavaScript. Someone wanted a better way to do something specific, and they figured out a quick way to make it work with the existing infrastructure. They didn't need to wait for everyone to agree to let them into the party. But this has brought cacophony as everyone writes their own slightly different, slightly cooler version of the future. To make matters worse, the results aren't human-readable because they came out of some compiler. This breaks one of the neatest features of the Web: The ability to dig into the HTML and JavaScript of any page to know what’s going on. But the programmer gets to write cleaner code.


Automatic type conversion bugs and confusion

It sounds nice to have the language convert strings to integers automatically, but not when you least expect it. To make matters worse, the plus sign signifies both addition and concatenation, making remembering what will happen a near crapshoot. If the variable x is set to the string 1, then x+1 will turn into 11 but x-1 will turn into 0. That's great, except when you expect or want something else to happen.

Brian Moore via Flickr

Value confusion

Quick, what's the difference between false, null, NaN, and undefined. They're all somewhat similar; some even equal one another. At this writing, Chrome tells me that isNaN(undefined) is true but undefined==NaN is false. It all makes sense if you spend a few hours on this mathematical philosophy, but that doesn't make it any easier to write code.


Mistaken Java identity

Believe it or not, people still confuse JavaScript with Java -- and all because someone decided to jump on the Java bandwagon with a language vastly different than its near-namesake. We can try to call it ECMAScript, but no one listens. The tech community can keep the differences straight, but not the suits. Oh boy, do they find it impossible to remember that Java works on the server to send markup to the browser. Except sometimes it works in concert with JavaScript that runs in the browser. Sometimes we get confused when we're talking about them.