Recently I participated in a panel on The Standards Process and the Extensible Web Manifesto at Edge Conf. While ours was the very last session of the day (you can watch the video here), nearly every topic that day called out some mention of the Extensible Web Manifesto. Privately, there were still plenty of people I met between sessions who privately said “So, what exactly is this Manifesto thing I keep hearing about, tell me more…”. and my day was filled with discussions at all levels about how exactly we should apply its words in practice or what exactly we meant by x – or specifically what we want to change about standards.
Given this, I thought it worth a post to share my own personal thoughts, and say some of the things I didn’t have an opportunity to say on the panel. I’ll begin in the obvious place: Bruce Lee.
Let’s talk about Bruce Lee. Chances are pretty good that you’ve heard of him from his film work and pop-culture status, but it’s (slightly at least) less commonly known that he was more than just an exceptional martial artist: He was a trained philosopher and deep thinker – and he did something really new: He questioned the status quo of traditional martial arts. He published a book entitled “The Tao of Jeet Kune Do” and laid out an entirely new approach to fighting. He taught, trained and fought in a way unlike anyone before him.
He kicked ass in precisely the same way that standards don’t.… It started by being both intelligent and gutsy enough to make some observations…
There are values in principles, but nothing is too holy to be questioned…
Ok, so we all agree that standards are painful to develop and have sometimes gone very wrong. From the outside they look, at times, almost comically inefficient, illogical or even self-defeating. Many comments in our panel were about this in some form: Too much classical mess – too much Wing Chun.
Bruce Lee saw through the strict rules of forms to what they were trying to accomplish, and he said “yeah, but that could be better- what about this instead”… and opponents fell.
Likewise, standards bodies and processes are not a religion. Sometimes process is just process – it can be in the way, unproductive – even harmful if it isn’t serving its true purpose. There are no holy texts (including the Manifesto itself) and there should be no blind faith in them: We are thinking, rational people. The Manifesto lays out guiding principles, with what we hope is a well rationed incentive, not absolutes. Ideological absolutes suck, if you ask me, and Bruce’s approach makes me think he’d agree.
The Manifesto is pretty short though, it begs follow-on and one recurrent theme was that many people at the conference seemed interested in discussing what they perceived to be contradiction in that we have not redirected absolutely everything toward the absolute lowest primitives possible (and for others, a fear that we would). I’d like to explain my own perspective:
It is often more important to ask the question than it is to answer it perfectly.
Again, the Manifesto lays out principles to strive for, not laws: Avoid large, deep sinks of high-level decisions which involve many new abstractions and eliminate the possibility of competition and innovation – we have finite resources and this is not a good use of them. Favor lower level APIs that allow these things to occur instead – they will, and try to help explain existing features. Where to draw the line between pragmatism and perfection is debatable, and that’s ok – we don’t have to have all of the perfect answers right now, and that’s good, because we don’t.
Paralysis is bad. Perfect, as they say, can be the enemy of good: Progress matters and ‘perfect’ is actually a non-option because it’s an optimization problem that involves many things, including an ever changing environment. Realize that there are many kinds of advantage that have historically trumped theoretical purity every time – the technically best answer has never, to the best of my knowledge ‘won’ – and shipping something is definitely way up there in terms of things you need to succeed. More importantly, do what we can to avoid bad. At some very basic level, all the Manifesto is really saying is: “Hey standards bodies — Let’s find ways to manage risk and complexity, to work efficiently and use data for the really big choices”.
In my mind, the W3C TAG has done a great job of attempting to redirect spec authors, without paralyzing progress, toward asking the right questions: “Is this at an appropriately low level?”, “If it isn’t quite at the bottom, does it look like we can get there from here – or is it what’s here too high-level and overly complicated with magic to be explained?”, “Can we explain existing magic with this?” and, “Is it consistent in the platform so that authors can re-apply common lessons and reasoning”?
I’m sure the there are some who would disagree, but in the end, I think that Web Audio API is a nice example of this kind of pragmatism at play. There are things that we know already: We’ve have an <audio> tag, for example, for a while. We have a collected cases which should be plausible, but currently aren’t. The Web Audio API tries to address this at a considerably lower level, but definitely not the lowest one possible. However… It has been purposely planned and reviewed to make sure that it gives good answers to the above questions. While it’s possible that this could lead to something unexpected beneath, we’ve done a lot to mitigate that risk and admitted that we don’t have all of the information we need to make good choices there yet. It was built with the idea that it will have further low-level fleshing out and that we think we know enough about it to say that we can use it to explain the mechanics of the audio tag with it. We got the initial spec and now, nearly immediately, they’ve begun work on the next steps. This has the advantage of steady progress, drawing a boundary around the problem and gives a lot of developers new tools with which they’ll help ask the right questions and through use, imagine new use cases which feed into a better process. It gives us tools that we need so that efforts like HTML as Custom Elements can begin to contribute in helping to explain the higher level feature. The real danger is only in stopping the progressive work.
Similarly, it was asked by someone whether Beacon “flies in the face of the Extensible Web Manifesto” because it could be described by still further low level primitives (it might be possible to implement with Service Workers, for example). Again, I’d like to argue that in fact, it doesn’t. It’s always been plausible, but prohibitively cumbersome to achieve roughly the same effect – this is why HTML added a declarative ping attribute to links: Simple use cases should be simple and declarative – the problem isn’t that high-level, declarative things exist, we want those – the Manifesto is explicit about this — the problem is in how we go about identifying them. Because this is a really common case that’s been around for a long time – we already have a lot of good data on that. As it happens, ping wasn’t implemented by some browsers, but they were interested in sendBeacon, which – hooray – can actually be used to describe what ping does, and maybe polyfill it too! It’s simple, constrained, concise – and it’s getting implemented. It’s enough for new experimentation and it’s also different enough from what you typically do with other network level APIs that maybe it’s fine that it have no further explanation. If you read my posts, you know that I like to make the analogy of evolution, and so I’ll point to something similar in the natural world: This may simply be a case of convergent evolution – differently adapted DNA that has a similar-looking effect, but share none of the primitives you might think, and that too can actually be ok.
The important part isn’t that we achieve perfection as much as that we ask the questions, avoid bad mistakes and make good progress that we can iterate on: Everyone actually shipping something that serves real needs and isn’t actively bad is actually a killer feature.
Bruce had a lot excellent quotes about the pitfalls of aiming too low or defeating yourself.
It’s easy to look at the very hard challenges ahead of us to distill the cumbersome sky-castles we’ve built into sensible layers and fundamentals and just say “too hard” or “we can’t because explaining it locks out our ability to improve performance”.
Simultaneously, one of the most urgent needs is that we fill the gaps – if the Web lacks features that exist in native, we’re losing. Developers don’t want to make that choice, but we force them to.
We’re doing best when we are balancing both ends of this to move ever forward.
Don’t give up. It’s going to be hard but we can easily defeat ourselves before we ever get started if we’re not careful. We can’t accept that – we need to convince ourselves that it’s a non-option, because it is. If we don’t do the hard work, we won’t adapt – and eventually this inability will be the downfall of the Web as a competitive platform.
Jump in the Fire
Good things happen when we ship early and ship often while focusing this way. As we provide lower-level features we’ll see co-evolution with what’s happening in the developer community, this data can help us make intelligent choices – lots of hard choices have been made, we can see what’s accepted, we can see new use cases.
Some have made the case – to me at least – that we shouldn’t try applying any of this to standards until we have everything laid out with very precise rules about what to apply when and where. I disagree. Sometimes, the only way to figure some of it out is to jump in, have the discussions and do some work.
Standards processes and even bodies themselves have evolved over time, and we should continue to adapt where we see things that aren’t working. It won’t be perfect – reality never is — it’s messy, and that’s ok..
Very special thanks to Brendan Eich and Bruce Lawson for kindly reviewing and providing useful thoughts, commentary and corrections ❤..