Year round learning for product, design and engineering professionals

Towards an extensible web

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

People mentioned in this article

delivering year round learning for front end and full stack professionals

Learn more about us

this was a masterfully curated event … a brilliant day that educated, entertained, and rekindled some old connections

Ash Donaldson Service & Behaviour Design Director, Tobias
Portrait of Ash Donaldson