What Would Bruce Lee Do? The Tao of the Extensible Web.

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.

The Non-Option

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 equation 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..