"What do you think of JavaScript"? 👾

Friday, May 18, 2018 :: Tagged under: engineering. ⏰ 7 minutes.

Hey! Thanks for reading! Just a reminder that I wrote this some years ago, and may have much more complicated feelings about this topic than I did when I wrote it. Happy to elaborate, feel free to reach out to me! 😄

🎵 The song for this post is Bustin', by Neil Cicierega. 🎵

I shared this talk with a friend of mine who's hoping to make biggers waves in computing, and he asked me "what do you think of JavaScript?"

I believe JavaScript exceeds all other languages in its ability to generate unproductive conversations; the thought of answering this gives me the willies. I'm half-tempted to pull a Kevin Williamson and just never articulate a clear position to a simple question, sputtering angrily and huffing if anyone tries to infer meaning from what I say. But that's no fun, I'll try to answer the question as best as I can.

The short answer is I don't usually love it; but have loved it before and most haters are shortsighted. Let's elaborate, I'll start with the flames, since that's probably what you're here for.🍿

Goodness, JavaScript Was Bad

There are four meanings of this. var scoping and function hoisting have no precedent in any other language I can find (it's usually just called a scoping bug). Before strict mode, if you define a variable without var it is globally scoped by default. All functions are vararg functions. You have no integers, all numbers are floats. Null, the billion-dollar mistake, is in JavaScript, but there's another value that means nothing, undefined. Implicit casting rules, combined with truthy/falsey values, are a legendary hell. ==, but also ===!

And listen: there's a lot of undue hate to JavaScript and its community. But even if it's a language you use and love, I can never look at the above and think "wow, this language is Actually Good. No language intentionally has such an abundance of pitfalls and loose correctness criteria; these things do bite people, cause bugs, hurt products, and are generally a part of all things any reasonable person calls "bad software."

This isn't to say it's not liveable (we clearly do live with it), but I don't think I can ever love this language when there's all this mess going on.

But it was designed in 10 days!

True! But if I cook a turkey in the oven for half the time, I'm still asking you to eat a frozen turkey. JavaScript-by-default is a frozen turkey.

But [thing you mentioned] isn't a problem anymore because [subsequent library or tool]!

Through strict mode, subsequent ECMAScript revisions, and tools like Babel, it's entirely possible to write many variations of JavaScript, including adding checks to ensure you're writing whichever subset you like.

an old meme

There's an old joke about Domain-Specific Languages: it's where you program the app in one language but debug it in another. Even if you have the opportunity to use fancy whiz-bang Modern JavaScript, you can't get away without knowing the 10-days subset.

Many companies you'll work at are still using Backbone or Angular 1 or whatever tool was popular at the time. You may be maintaining CoffeeScript v1! Which was great, but it's also an uncanny valley of "kinda ES6 but not."

In this way, you still have to know all the pitfalls of the language to appropriately maintain and debug, since many codebases won't (for reasons of history or portability) get to take advantage of The New Hotness.

I'll also note that there's setup cost to incorporating all these tools. Ever seen a Gruntfile with all the bells and whistles attached? Or were you one of the cool kids to move to a webpack file? Or are you the new school using Makefiles? The tools may work well together or they may not, but it's always been non-trivial effort for me to get the perfect JavaScript project set up.

And the [subsequent library or tool] you mentioned? There's usually competition behind which one to use, and it's normally to add some language feature that exists elsewhere. Did you pick TypeScript or Flow? Cool, you just got types. Remember when we were fighting over RequireJS and CommonJS? Nice, now you've got modules, until ES6 got modules (in their defense, C++ still doesn't have them 😝).

Having to choose between popular competitors and configuring it into a working build system goes beyond language features: did you pick Bluebird or q for promises? Ever seen a project with both .jshintrc and .jslintrc? Are you into Chai or Jasmine? Did you get on the Bower train when that was the way to build things? Did you/do you invest in Brunch? Browserify? Yeoman? Yarn or NPM? And on and on and on… these are all off the top of my head, and I've never been a full-time frontend dev!

To be clear, ecosystem competition is great, and I love most of these tools. But almost all of those tools are, in my mind, addressing weaknesses in the language and/or building projects in it, and there is a lot of mental overhead in keeping track of any of them.

this is for a server program that's 328 lines whose job is to serve static files and mock data.

we in Node again pic.twitter.com/Aik5ZzhsB2
— 💣 b∀BГO 💣 (@SrPablo) October 8, 2015

Man, Hating JavaScript is Boring and Tired

At the same time, server developers like me have a terrible habit of being self-serious and treating their programming like it's Real Programming. The browser is a fucking nightmare, and developers who build tools and program for it deserve massive commends.

Front end software development is:
- real-time (instant load, 60fps)
- distributed, incremental (synchronize remote data as needed)
- asynchronous
- reactive (react to user actions in realtime)
Front end is the hardest kind of dev I do. The folks who do it every day are heroes.
— Yehuda Katz 🥨 (@wycats) November 14, 2017

It's also worth noting that other languages aren't really aren't much better at this. It's hard to complain about build tools when you consider what goes on in a ./configure script, or think about trying to produce a project in Python:

xkcd

It's worth mentioning that a lot of JS's complexity comes from serving the most globbed-on, fast-changing, widest-available platform and APIs in history. JS applications have to make sense of a document model that does multiple network calls compatible with every possible display size. Of course its got messy bits.

Lastly, JavaScript and its ecosystem has been a boon for bringing new developers into the industry. I'll take a language with twice as many warts if it could bring so many wonderful, enthusiastic, brilliant people to modern spellcasting 🧙🏼‍♂️

What I love about JavaScript

There's one thing I absolutely, positively love about JavaScript that virtually no other mainstream language has: transparent object types. You can take any object, pass it to console.log(JSON.stringify(obj)); and inspect its properties.

In Java you have to you write toString(), Python it's __str__(), Ruby it's to_s, and in each you have to keep it up to date with its fields. And you can only really do this with objects you define!

While it's dogma that objects should be opaque and we should operate purely on interfaces, in practice, when I need to see what's happening, I find this invaluable. I'm a printf debugger through and through.

Similarly, the Chrome and Firefox teams have made extraordinary investments in developer tools, which make debugging a lot of the hells of CSS and JavaScript downright fun.

tickled and frustrated with how much fun hacking in Node is
— 💣 b∀BГO 💣 (@SrPablo) September 5, 2016

The giant, giant community has produced reams of useful, widely-accessible code. If someone hasn't written a JavaScript module, you're doing something really obscure.