The Extensible Web Manifesto has launched, aiming to “change how web standards committees create and prioritize new features,” which is “critical to the long-term health of the web”.
Primarily, the group is working to create a tighter feedback loop between web standards editors and web developers, with iteration being far more rapid. On that basis, the group wants to see more feature development and iteration in JavaScript, followed by implementation in browsers and standardisation.
Developer Yehuda Katz outlined his thoughts on the manifesto in a post on Medium, and argued: “Instead of placing our faith in central planning, we should let the ecosystem of web developers build the features they need, on top of low-level capabilities exposed efficiently and securely by the browser.” He likened the Extensible Web Manifesto’s philosophy to that of Web Components, which enable developers to craft their own HTML tags rather than waiting for centrally designed equivalents to arrive.
.net spoke to Google ‘spec hacker’ Tab Atkins Jr (TA), one of the early signees of the Extensible Web Manifesto, to gain further insight into the reasoning behind the manifesto, why existing processes are failing and what the repercussions could be for developers.
.net: Why is the Extensible Web Manifesto needed? What are the big dangers to the web if these ideas aren't taken on board?
TA: The problem with today's processes, which the EWM tries to solve, are size and speed.
Too often, we try to design single, smart solutions to missing capabilities. Even when we get everything right, we can never meet every single need, and because our new APIs are monolithic, apps that don't match our expected model exactly are forced into dirty hacks at the margins, or are forced to reinvent the entire feature themselves. This means they have to deliver more code over the wire, eating up valuable time, and which is often much slower than what could be offered by a native solution that actually works for them.
Note that is a best-case scenario, when the feature is actually useful for most people. Inevitably, we end up developing a few failures that work for almost no-one, but are still used too much to be dropped, meaning we have to add a second version of the API to browsers, increasing their size as well.
The correct way to handle all of this is to limit the inevitable ‘magic’ (things that are slow, hard, or impossible to do on the web author side, but which can be done well by the browser) to a set of 'composable' building blocks with small, simple surface area, possibly accompanied by a high-level ‘smart’ API which can be explained in terms of those building blocks.
This gives us the best of all worlds: authors who are well-served by the high-level API have something easy to use, authors almost served by the high-level API can hook into the building blocks and modify things where necessary, and authors who have completely different needs can easily roll their own solution without too much inefficiency. Hence the Extensible Web Manifesto.
.net: What do you feel existing processes aren't doing well enough? Is this holding back the web?
TA: The fundamental problem is one of composition. It's much easier to design something that solves all the problems put in front of you; it's much harder to design something well-factored into small components, which can be re-used to solve problems that you haven't even thought of.
Because of this, there's often a lot of pushback from browser devs when we try and encourage them to break an API down into its component parts. They've got work to do, and the solution they've come up with looks really nice and elegant for the use-cases they've been presented with. We need a more general acceptance that the ‘building block’ approach is the correct way to design things. The alternative is trying to mimic every hot new native capability as it comes out, which is a losing game given the relative iteration speeds of controlled platforms versus the web.
.net: Do you think developers aren't being listened to enough of late when it comes to standards, what's implemented and how fast such things iterate? Should they have more 'control' over the web's evolution?
TA: I think developers are being listened to much more now than ever before. Any feeling to the contrary is because the number of devs who are interested in these kinds of APIs is growing rapidly. It’s the same with iteration speed. We're churning faster than ever before, but our expectation of speed is outstripping our actual speed.
Perversely, it's because of this that we need to give devs more control over the evolution of the web. No matter how hard we try, we simply can't design and ship new APIs fast enough to meet the needs of web devs. Even if we could, the growth in browser size, and the connected increase in testing needs, and inevitable bugs, would be unsustainable. We need to grow the platform without growing the browser, and the only way to do that is to put more control at the fingers of the devs.
.net: What reaction has there been from browser vendors and standards bodies about the idea of shifting more initial work/iteration to JavaScript?
TA: Since I'm on the ‘inside’, I see surprisingly good signs from my colleagues. Within browsers, well-designed APIs often have a smaller code weight, especially over time as the feature grows, and are much easier to test for correctness. Standards bodies get the harder side, since it's more difficult to design those good APIs, but there are promising noises from that direction as well.
For example, the election of Marcos Caceres, Yehuda Katz, Anne van Kesteren, and Alex Russell to the W3C's TAG (a steering group for the W3C as a whole) is awesome, because the four of them have been some of the loudest voices for good API design in recent years. Similarly, I just got back from a CSS Working Group meeting, where I heard several people talk about ‘extensible CSS’, similar to what I outlined at the beginning of the year in a blog post.
Not everything is perfect, of course. One of the hardest things to sell is the refactoring of existing monolithic APIs into better-designed pieces. An example of this is the Navigation Controller effort, which is a refactoring of AppCache. That seems to finally be succeeding, but it's late by years, and has been far more difficult than it should have been.
