On standards work

This week I'm looking at standards with my open source class. I find that students often don't know about standards and specs, how to read them, how they get created, or how to give feedback and participate. The process is largely invisible. The timing of this topic corresponds to a visit from David Bruant, who is a guest presenter in the class this week. I wanted to discuss his background working "open" while he was here, and one of the areas he's focused on is open standards work for the web, in particular, for JavaScript.

All of the students are using JavaScript. Where did it come from? Who made it? Who maintains it? Who defines it? Who is in charge? When we talk about open source we think about code, tests, documentation, and how all of these evolve. But what about open standards? What does working on a standard look like?

There's a great example being discussed this week all over Twitter, GitHub, Bugzilla and elsewhere. It involves a proposal to add a new method flatten() to Arrays. There are some good docs for it on MDN as well.

The basic idea is to allow an Array containing other Arrays, or "holes" (i.e., empty elements), to be compressed into a new "flat" Array. For example, the "flattened" version of [1, 2, [3, 4]] would be [1, 2, 3, 4]. It's a great suggestion, and one of many innovative and useful things that have been added to Array in that last few years.

However, changing the web is hard. There's just so much of it being used (and abused) by people all over the world in unexpected ways. You might have a good idea for a new thing the web and JavaScript can do, but getting it added is not easy. You might say to yourself, "I can see how removing things would be hard, but why is adding something difficult?" It's difficult because one of the goals of the people who look after web standards is to not intentionally break the web unnecessarily. Where possible, something authored for the web of 1999 should still work in 2019.

So how does flatten() break the web? Our story starts 150 years ago, back in the mid 1990s. When it arrived on the scene, JavaScript was fairly small and limited. However, people used it, loved it, (and hated it), and their practical uses of it began to wear grooves: as people wrote more and more code, best practices emerged, and some of those calcified into utility functions, libraries, and frameworks.

One of the frameworks was MooTools. Among other conveniences, MooTools added a way to flatten() an Array. While JavaScript couldn't do this "natively," it was possible to "shim" or "polyfill" the built-in Array type to add new properties and methods. MooTools did this in a way that causes problems: we have all be told that it's a bad idea to modify, "step on," or otherwise alter the definitions of the language and runtime without first checking to see if they are, in fact, available. We wrote code in 2007 using assumptions that don't necessarily hold true in 2018: the browsers change, versions change, the language changes.

I remember when I started writing JavaScript, and looking at the long list of reserved keywords I wasn't supposed to use, things like class that everyone knew you'd be safe to use, since JS doesn't use classes! Well, much like hundred-year land leases, eventually things change, and what was true once upon a time doesn't necessarily hold today. It's easy to point a finger at MooTools (many people are), but honestly, none of us thinks with enough long-term vision to truly understand all the implications of our decisions now on the world 10, 20, or 50 years hence (code people are writing today will still be in use by then, I promise you--I was a developer during Y2K, so I know it's true!).

At any rate, MooTools' flatten() is going to collide with JavaScript's new flatten(), because they don't work exactly the same (i.e., different argument signatures), and any code that relies on MooTools' way of doing flatten() will get...flattened.

And so, someone files a bug on the proposal, suggesting flatten() get changed to smoosh(). Before this gets resolved, imagine you have to make the decision. What would you do? Is "smoosh" logical? Maybe you'd say "smoosh" is silly and instead suggest "press" or "mix". Are those safe choices? What if you used a made-up word and just documented it? What about "clarmp"? What about using a word from another language? They say that naming things is one of the great problems in computer science? It really is a hard problem! On some level we really should have lexicographers sitting on these committees to help us sort things out.

I won't give you my opinion. I intentionally stay out of a lot of these debates because I don't feel qualified to make good decisions, nor do I feel like it matters what I think. I have ideas, possibly good ideas, but the scope and scale of the web is frightening. I've had the privilege to work with some amazing web standards people in the past, and the things they know blow my mind. Every choice is fraught, and every solution is a compromise. It's one of the reasons why I'm so patient with standards bodies and implementors, who try their best and yet still make mistakes.

One thing I do know for sure is that the alternative, where one person or company makes all the decisions, where old code gets trampled and forgotten by progress, where we only care about what's new--is a world that I don't want either. If I have to smoosh() in order to live on a web that's bigger than me and my preferences, I'm OK with that.

It's easy to laugh, but instead I think we should really be thanking the invisible, hard working, well intentioned open standards people who do amazing work to both advance the front and guard the flank.