This is unfortunate and we’re stuck with it forever

I. Some weeks ago, at NodeConf Argentina, Mathias Bynens gave a presentation about RegExp and Unicode in JavaScript. At some point he showed a series of examples that yielded counter-intuitive results and said: “This is unfortunate and we’re stuck with it forever”. The phrase immediately resounded in my head, because to me it was a perfect definition of JavaScript, or at least the current state of JavaScript.

II. Douglas Crockford published JavaScript: The Good Parts about eight years ago. It’s a masterpiece to me, with a lot of takeaways: JavaScript is loaded with crap (the bad and awful parts); there’s a great functional language somewhere in there, striving to get out; sometimes, a lot of the times, less is more. The book itself is the perfect example: 100 pages long, mostly filled with snippets and examples, and still it had a clearer purpose and communicated it more effectively than most computer books. We can (and we should) make a better language out of JavaScript by subsetting it.

III. JavaScript and its ecosystem have been evolving constantly over the last few years; I imagine it mutated faster than any other programming language has done before. And a lot of the changes are genuinely good additions, that make our lives easier and more pleasant. But is JavaScript as a whole getting any better?

IV. Unlike any other language, JavaScript runs in browsers. And we can’t control the runtime of the browsers. And we want older browsers to support our new code, and new browsers to support our old code. We can’t break backwards compatibility. We can add (some) stuff to the language but we can’t take stuff out. All the bad and awful parts are still there. JavaScript is like a train wreck with a nose job.

V. I always wonder how is it like to learn JavaScript in 2016, for new programmers and for programmers coming from other languages. Do you tell them about var? Or just stick to let and const? And which one of those is preferred? And why the preferred one isn’t just the default? Why do we always have to prepend some operator to define a variable? Yes, we can instruct a linter to forbid this or that keyword (especially this!) but it should be the compiler/interpreter doing it. And we can’t make the interpreter assume a const declaration by default.

VI. Is there really no way to break backwards compatibility? Can’t we just stick a flag in there somewhere? <script language="javascript-good">? 'use non-crappy'? I don’t mind adding the 'use strict' on every file and I honestly forgot what it does. Can’t the browsers manage multiple versions of JavaScript? is it worth their save, especially now that this uneven language has crawled its way to the server and the desktop?

VII. I know there must be excellent reasons why we can’t break backwards compatibility of JavaScript or why it would be just too expensive to do so. But I can’t help my mind, my syntax-oriented-programmer-with-an-inclination-to-a-less-is-more-kind-of-thinking-type-of-mind, I can’t help it from imagining how would I go about subsetting the language. How would I design my JavaScript--. I can’t help myself from outlining a spec of that imaginary language in my head. I even came up with a name for it, which, unsurprisingly, has already been taken.


6 thoughts on “This is unfortunate and we’re stuck with it forever

  1. Everyone with any power to affect JS *hates* the idea of versioning (to be fair, they have some good reasons since past versioning attempts failed miserable). As a result we’re going to be “stuck with it forever” … forever.

  2. Yeah, let’s solve this problem by bolting another JavaScript engine on entirely. Just when all the major browser vendors have started to converge, let’s just tear the whole thing down because screw years of carefully growing and building an Ecma standard by committee.

    From a figure who comments so fervently on languages and specs yet dropped “what does strict mode even do again?”, we can safely place this article alongside “Sad State of Web Development” in the forgettable, whiny trash bin.

    • I wouldn’t call this fervent. Whiny? definitely. But not intended as an attack to anyone.

      I don’t see how being more or less knowledgeable about a specific language feature makes my opinion on another subject less valid. If a politician takes a decision that screws up my life, I’m going to complaint about it, I don’t need to recite the constitution to prove my opinion worthy.

      In any case I avoided using more than one or two examples exactly to avoid this sort of argument. Regardless of specific features, I’m pretty sure that most developers would agree that JavaScript as a whole was flawed ten years ago, and it’s almost equally flawed today since none of the bad parts were actually removed.

      Finally, I don’t think that something being slowly grown into a standard by a committee makes it necessarily good. History shows examples of quite the opposite. The decisions made by the committee are driven by the interests of the parties represented in it, which most likely differ from the interests of the developers that end up using the language. I wrote this from a developer standpoint.

  3. WebAssembly will solve this. No longer will you need to use JavaScript at all. Instead, use any (sane) language you wish, and it can be run in the browser.

    This will have the effect of fragmenting web development; there will not be a common language, so it will be more difficult to switch between projects or teams. However, frontend development is already quickly fragmenting; see the proliferation of build tools, compile-to-JS languages, Babel, etc.

    You’ll also lose the ability to inspect and modify the code running on any page. But maybe source maps could help with that.

  4. Python3 should teach the lesson that introducing a backwards incompatible change into a language requires thinking in terms of decades. Javascript is moving too fast for anyone (let alone everyone) to think on that long of a timescale.

  5. Pingback: Recap of the Schneide Dev Brunch 2016-08-14 | Schneide Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s