“Design by Committee” is rarely a compliment. Can the Web shift away from that model, retaining some order without falling into troublesome chaos?
The Manifesto
Part of the excitement around the Extensible Web Manifesto was that it wanted to move the Web to more of an evolutionary model:
We aim to tighten the feedback loop between the editors of web standards and web developers.
Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.
This sounds great. Web standards have always been difficult, their universal goals making it difficult to bring together different vendors and even different standards organizations. Developers are impatient, and most of us have little connection to the kinds of reasoning that drive vendors, consortia, and yes, committees. Open source and similar models have taught us that many eyes are valuable, and small experiments seem less likely to break the Web than specifications that lurch the wrong direction.
Unfortunately, extensibility is not, as we learned from XML, a magical way to speed things up and make committees disappear. The rest of the Extensible Web Manifesto explains how it hopes to make this work, but the key piece is the very first item:
Focus on adding new low-level capabilities to the web platform that are secure and efficient.
The Summit
At last week’s Extensible Web Summit, about 75 people explored what this meant in a variety of different Web contexts. The committee leading the committees, the W3C TAG, hosted it, but the focus was rarely on the TAG. Instead, a 4-track wide unconference explored a huge variety of challenges. As you’ll see below, the challenges aren’t solved yet, but talking about them is a key step to getting there. You can get a broader sense of the conversations from the (highly variable) minutes.
I started at something I knew would be difficult: data binding interop. Despite decades of object-oriented programming and an even longer history of working with tree structures, getting programmers to agree on the best ways to put data into trees in order to process it remains… contentious. Sometimes there are issues with the data, sometimes there are issues with how people want to process it, and sometimes there are differences over what “simple” means. All of those are still with us.
The next session, on Web Components, seemed more promising. Reusing code and making it easier for more to use through declarative approaches seems great. (For background, this interview is great if you have time and this article is great if you want to move faster.) The session, though, mostly swirled. Some of it was familiar from XML conversation: the terrors of letting people create their own vocabularies, the endless challenges of name collisions, and questions about embedding vocabularies in HTML or starting clean with a new vocabularies that might include HTML where convenient. One fascinating point to me was that there isn’t yet enough experience to sort out what reuse patterns, the key promise of web components, should look like. It’s early yet, of course.
By lunchtime, apps and object trees were making me want to run back to dull old documents and functions. I’d worried for years about whether the Document Object Model (DOM) tree was up to the task, and by lunch I was pretty much thinking it wasn’t.
The afternoon was brighter, though. A session on CSS.next looked at both possibilities for making CSS itself more extensible and the (tricky) connections between the CSS box model and the DOM. The ‘black box’ of CSS implementation surfaced a bit more, coming into view as something JavaScript folks want more control over. Tab Atkins also asked about Grid Style Sheets and how they might interact with or replace existing models.
Packaging should be peaceful, right? The W3C TAG itself and TAG member Jeni Tennison are taking another look at creating a system for packaging content for delivery on the Web. Much of the conversation was about whether this mattered for performance given the improvements SPDY and HTTP 2.0 are bringing, but it was also clear that “zip files plus manifest” is a worthwhile conversation on which to build. Web Components and data interchange are making it more important again.
To close my own day, I went to a small session on editing and specifically about ContentEditable. I knew it was a hard problem – I’d tried using it years ago, and tried using other (Java, Mac) approaches to building text editors before as well, but it was remarkable how unsolved a problem text editing is. We should marvel at the great things people and companies have created despite the challenges. If nothing else, that session gave me a sense that maybe the other problems I’d been studying were more tractable than this one.
The Challenge (and Maybe a Challenger)
I went to the Extensible Web Summit with a basic concern: is it possible to extend the Web while preserving the models that give it its strength? Can we keep the declarative model that makes the Web approachable to non-programmers and maintainable by a much larger and more diverse group of people than coders?
The Extensible Web Manifesto clearly values this declarative nature:
We want web developers to write more declarative code, not less. This calls for eliminating the standards bottleneck to introducing new declarative forms, and giving library and framework authors the tools to create them.
However, the “low-level capabilities” questions, both in conversation around the Manifesto and at the Summit, always seems to get into requests for more and more imperative features. Somehow we have trained programmers to believe that imperative is always easier, and that reaching into a system to grab just the bit you want and yank it is a good approach to building complex systems.
My one angry outburst came after a lot of requests in the Web Components session for ever more imperative hooks into the system. Can we really get to the declarative approaches that make it easier to maintain web apps and sites by adding ever more imperative hooks?
I suspect that in the end it depends on how we think developers will use them. The risks are clear. As Peter Gasston put it in his Web Ahead interview:
“In the rush to create our elements, I have no doubt whatsoever that we’re going to end up with [accessibility, markup usability] being overlooked. I’m absolutely sure of that… I termed it “a proliferation of rubbish”… Quite often we cut corners and we want to get things done and we have deadlines to meet and budgets to meet and sometimes we just don’t care about stuff.
He’s still hopeful that Web Components will help, at least “won’t exacerbate that problem,” by helping us manage the connections between bundles of code and declarative markup. Addy Osmani describes a declarative and composable future for the Web that includes addressing the challenges of extending the Web responsibly.
Can “good, responsible developers” drive this conversation forward?
Even if they can, another challenge is rising. Earlier this year, I noted the appeal of “ripping out HTML completely and replacing it with Canvas” and “visions of rebuilding the rendering stack in JavaScript”. That may be arriving now, though it’s still largely in closed beta. Famo.us has developed ““an open source 3D layout engine fully integrated with a 3D physics-based animation engine that can render to DOM, Canvas, or WebGL.” Their docs proudly proclaim a different relationship between markup and rendering:
One of the first things to notice about Famo.us is how little we expose HTML and the DOM to the developer. Interacting with the DOM is riddled with performance issues. Famo.us abstracts away DOM management by maintaining a representation of it in JavaScript called the Render Tree.
If you inspect a website running Famo.us, you’ll notice the DOM is very flat: most elements are siblings of one another. Inspect any other website, and you’ll see the DOM is highly nested. Famo.us takes a radically different approach to HTML from a conventional website. We keep the structure of HTML in JavaScript, and to us, HTML is more like a list of things to draw to the screen than the source of truth of a website.
So far what I’ve seen of Famo.us feels deeply app-centric, but it’s early yet. Has the Web given birth to technologies that will replace it? And how hard will it be to maintain the apps and sites created with these technologies?