I Accidentally Improved the JavaScript Language, and So Can You

For a tech company, Bocoup used to talk an awful lot about cow paths. You couldn’t take much for granted on the web of the early 2010s, and we worked on the jQuery library to make web development a little more predictable. Cow paths made for a fittingly Bostonian (yet disappointingly apocryphal) metaphor in infrastructure development: successful public works are built around evidence of heavy usage.

Photo: Landscape near Khokhlovo, CC BY 2.0 carlfbagge

Of course, the “cow paths” we paved were more electronic than bovine, but there was also a certain humanity in paying attention to what people needed and meeting them where they were.

The status quo on the web platform has improved dramatically in the years since. Bocoup has become significantly more involved with browsers and standards bodies, and those bodies have become way more attuned to developer experience. Although this company’s roots show in our prioritization of developer engagement, our role as a formalizer of ad-hoc solutions increasingly felt like a thing of the past.

…until 2024, that is. In April of that year, TC-39 (the standards body which defines JavaScript) renewed its interest in adding the function Error.isError to the JavaScript language itself.

Why did I care? So glad you asked! Ten years earlier, I’d contributed a version of that function to the popular JavaScript utility libraries of the day, Underscore.js and Lodash. I needed it for some tests I was writing, and I figured that it might help others, too. The maintainers of those libraries agreed back in 2014, and the 2024 revival of the proposal demonstrated that TC-39 felt the same.

Today, the function is available in every major JavaScript runtime, and it will be minted as “ECMAScript” in a few short months.

Mr. Magoo © United Productions of America

I’ll level with you: my royalty check hasn’t arrived yet, and I’m starting to think it’s not simply lost in the mail. That’s okay, though; my contributions solved the problem I had at the time. They were hardly substantial anyway, especially not when compared to the advocacy and stewardship that’s typically demanded of specification authors.

Honestly, the story of Error.isError rings true for most everything that arrives in the programming language. Very little is invented from whole cloth; so much is informed by (if not entirely ganked from) mundane sources. We can see this in most¹ of the new features slated for ES2026:

• Math.sumPrecise has its roots in a 1996 academic paper and version 2.6 of the Python programming language
• The Internationalization Locale Info API draws inspiration from code snippets on StackOverflow, JavaScript libraries, proprietary Firefox APIs, and even code maintained by the Unicode consortium
• Uint8Array to/from base64 and hex (which introduces Uint8Array methods like toBase64 and fromHex) grew out of an extensive review of Base64 support in RFCs, programming languages, and JavaScript libraries
• Years before work began on Array.fromAsync, the “it-all” package was collecting the values from asynchronous iterables
• The authors of Iterator Sequencing needed two whole tables to document all the places they’ve seen people solving their problem (that includes Lodash–quite a breeding ground for good ideas!)

If there’s a lesson here, it’s in the value of generalizing your work and sharing it publicly. It doesn’t need to be a standalone library with its own website and mascot and stickers and theme song; just offering it to an existing collection of similar utilities will go a long way. You never know who you’re helping, or how your ideas might contribute (in some tiny part) to future advances–even decades down the line.