I’ve been doing a very tiny amount of JavaScript "programming" recently. I think I’ve finally figured out what the other problem with JavaScript is.

Before I describe that, I obviously have to mention the first problem and, simultaneously, why my JavaScript skills are intentionally very weak. The incredible thing about JavaScript’s first problem is that it has been entirely cured. Although JavaScript’s name implies some kind of relationship to Java, I can think of only one aspect of similarity: both JavaScript and Java are quintessential examples of what I call "turd polishing". Say what you will about Java, but these days it can program a Minecraft, which is astonishing when one considers how truly awful it was in every dimension in the 1990s. Exactly like its otherwise completely unrelated namesake, JavaScript underwent the same kind of transformation from completely useless as a programming language to, well, less useless.

What exactly then was JavaScript’s glaring problem that has been completely cured? In the 1990s and early 2000s JavaScript suffered from being utterly pointless to learn. Sure learning it and saying as much on a resume served many people well, but I’m talking about fundamentals, not irrational market forces. The reason that learning JavaScript was, in my opinion, a completely worthless investment was that it was not general purpose. You’d have been no less enlightened learning PLC programming in elevators or traffic lights.

Not only was JavaScript confined to the browser in a very bizarre way, but what could be done with it was absurdly limited. It seemed to me that JavaScript specialized in tepidly validating form boxes, thwarting client rendering preferences, creating inconsistent mouse over surprises, and some other truly forgettable annoyances.

That wasn’t even what made it pointless to learn. Maybe you needed to implement some of those annoyances. The problem I had was that whenever I felt I had a reasonable occasion to apply JavaScript, rather than learning it properly, I could simply search for the exact functionality I had in mind, and there would be the JavaScript code I needed. Not only that but there would be huge collections of such standard techniques. All JavaScript could do was control the browser and because the server controlled the proper content anyway, the only time it was interesting was when there was user input. Back in those days, that meant form boxes. Because there was such limited applicability, it seemed to me that every possible problem that JavaScript could conceivably be the solution to was not only solved, but those solutions were completely enumerated, implemented, and ready for download to all. It was a programming language where the random monkeys had typed all possible programs and helpfully put any vaguely sensible ones on the web. Why would one bother to recreate their work?

Although I do know a lot about JavaScript compared to normal people, I’m no JavaScript programmer. I feel like I know obscure languages that I’ve just dabbled in better than JavaScript even though it is so prevalent in everyday life. That brings me to the second problem that I’ve realized about JavaScript: side effects. Side effects in programming are basically where you send a function some input and it returns some output… And, oh ya, some other stuff somewhere else might be different now. Good luck with that.

I am aware that JavaScript has transformed into a completely proper and sensible programming language thanks to efforts like Node.js and I’m sure there are sensible people doing sensible things with it all the time. I’ve even seen that Node.js sports relatively high performance. However, it still seems to me that the overwhelming majority of JavaScript code that is run is run by a browser. And, frankly, as someone who learned and accepted how K&R wrote programs, browser JavaScript just seems damned weird. Speaking of K&R, the first place to look for an example of the weirdness, is Hello World, i.e. the first program in traditional programming language pedagogy. "Hello world" is not exactly natural in C, but in JavaScript it’s really hard to even be sure you’re really writing something along those lines at all. This is because normal JavaScript has no natural input/output system (yes, I know, but still). To "print" a message somewhere, you have to either create a new web page, replace part of an existing web page, or generate a pop up alert box.

Basically all real functionality is done by sly state changes in the DOM (basically the web page). The DOM is like one huge ugly global variable discouraging good design practices. This brings up a programming ethos question: are side effects bad? In some basic sense they’re almost necessary just to get a screen to update or something noticeable to happen. But in C, you can write a program that just calculates some things and returns an answer as an exit code with absolutely zero side effects. With JavaScript not only is it possible to write code with nothing but side effects, that’s the typical way! Changing some nebulous DOM state seems more common than changing properly scoped variables. I feel like JavaScript not only allows you to shoot yourself in the foot, it sets up the loaded gun already aimed at it.

Thanks to HTML5 (the "canvas" tag especially), WebGL, and SVG, JavaScript has become quite a useful language capable of solving far more problems than it could 15 years ago. Despite this, I still have a hard time letting my mind get comfortable with the style of programming JavaScript encourages. Incidentally, if you fastidiously run NoScript like I do, it quickly becomes apparent, sadly, that most JavaScript is still pure evil. Oh well, at least it’s improving. 😕