Towards an extensible web | Web Directions

• By: John
• Tweet: @johnallsopp
• June 13, 2013

Remember the X in XML, and XHTML? It of course stands for extensible, the idea that these languages allow for their users to build upon them, rather than waiting for some standards organisation to add new features.

With HTML5, extensibility of the markup language pretty much went out the window, despite the criticisms of many (including it must be said, me).

But extensibility is deeper than simply new language elements. As the web platform becomes increasingly sophisticated and powerful, it has also increasingly been seen as a competitor to “native” platforms such as iOS and Android. And where these platforms iterate quickly, with major new versions in the timeframe of each year or even more frequently, the web is seen to iterate far less quickly. We as developers need to wait not just for new browser versions (which in the case of desktop versions of Chrome and Firefox at least, is in the order of weeks), but whole new features of the DOM, CSS, and HTML, which typically is in the order of years.

Many have been frustrated with this pace of change, anxious that it puts the web at a disadvantage over the commercial platforms with far faster evolution. But the suggestions as to what might be done about it (for example, that the web should have “a single source repository and a good owner to drive it”) have not been on the whole realistic, or even really solutions to the challenge at all.

Now Yehuda Katz, Alex Russell, and numerous other high profile web developers, browser developers and specification authors have suggested a new way forward, summarised in The Extensible Web Manifesto.

In essence, the goal is to have new browser features implemented at a lower level, as DOM APIs, accessible through JavaScript (these might also be described as “imperative” features), as opposed to more high level, declarative features accessible at the level of the markup language.

Katz describes the situation of offline web apps, and how the approach to building a high level, “magical”, declarative feature, AppCache, went wrong, and how developing this functionality at a lower level might have avoided the problem, by empowering developers to build the solution they needed for their use cases.

We could have built offline support as a new JavaScript capability, with the manifest feature built on top of that capability. Then, when the manifest failed Facebook (and lanyrd, and the Financial Times), they could have dropped down into JavaScript and written something that worked for them.

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.

Will this be the approach to developing new web features we see more of? With members of the W3C’s Technical Architecture Group, or TAG, such as Alex Russell, Anne van Kesteren and Marcos Caceres firmly on board, along with the inventor of JavaScript, Brendan Eich, and numerous influential W3C and Browser vendor figures among others, I think it’s a fair chance.

But with an approach that at least superficially seems at odds with HTML’s self appointed benevolent dictator for life Ian Hickson’s, where does that leave the WHATWG in all of this?

Further Reading

• The Extensible Web Manifesto
• Extend the Web Forward
• The W3C’s Extensible Web Community Group (open to all interested parties)
• The future of web innovation
• ProllyFilling (‘polyfill[s] for a not yet standardized API’)
• .NET Magazine interview with Tab Atkins on the Extensible Web Manifesto

People mentioned in this article

• Joe Hewitt
• Alex Russell
• Anne van Kesteren
• Marcos Caceres
• Brendan Eich
• Yehuda Katz
• Tab Atkins

Your opinion:

Images:

The images are downsized due to limited space here. The original dimensions may differ.
Click on the image to open it on a new tab.