Original URL: https://www.theregister.com/2014/08/01/programming_the_web_25_part_ii/
Quicker, easier to fly to MOON than change web standards ... OR IS IT?
Snail's pace system might be forced to speed up
Posted in Software, 1st August 2014 07:59 GMT
Programming the Web, Pt. II It took the United States eight years to put a man on the Moon. That was time between John F Kennedy’s call to Congress in 1961 and Neil Armstrong getting his boots dirty on the lunar surface, in July 1969 – 45 years ago this month.
Yet it took 17 years, from the start of CSS, to get widespread support for custom fonts in HTML.
You read that right. It was easier to plan and co-ordinate the vast and lumbering military and civilian resources required for a pioneering space flight and to bring a crew back than produce a piece of paper on how web pages should be displayed in a browser.
Even taking into account that much of the delay was related to licensing problems, it doesn’t mark out standards bodies or browser makers as innovators.
Part of the problem is that neither standards bodies nor browser makers are made up of web developers and there's often a considerable disconnect between what developers want and what standards bodies and browser makers focus their attention on.
Even when standards bodies run like well-oiled machines, which is rare, few would argue that they make for a good source of innovation on the web.
Standardisation is, by its very nature, a long, drawn-out process designed to achieve consensus, not drive innovation. In fact, there's an argument to be made that taking 17 years to get support for custom fonts is a feature, not a bug, in the system.
Consensus conschmensus – why can't we just get the job done?
Consensus is needed. Arguments need to be entered into, sensitivities must be catered for, everyone with a vested interest or sensitive ego must be carried along.
Do I sound critical? Consensus is vital to the web and without web standards, we would not have the web we have today, but if web standards were the end of the story there would be no innovation on the web. The standards themselves are not the web. It's people who make the web and it’s the back and forth between developers and those slow-moving standards bodies that make the web a better place.
Web developers, though, want to build new things when they think of them, not wait for standards bodies to get round to endorsing them and for the browser makers to finally get around to shipping them.
The slow pace of new features on the web means the web is constantly playing catch up with proprietary platforms where new features come faster and more regularly.
And for developers, those new features make native platforms more appealing than working on the web. Even if you were going to only support browsers that update every six weeks, like Chrome and Firefox, you’re still waiting a minimum of 24 weeks for new features to progress from experimental builds to actually shipping.
Hey, problem – meet solution
I feel a solution is presenting itself to this problem. It’s a collection of new tools, referred to as Web Components, that promises to put the power of creating new features into the hands of web developers. Ironically, it’s coming to us through yet another standards process – the World Wide Web Consortium (W3C).
Yes, Web Components is a specification that is a catch-all for several interrelated tools designed to make it much easier for anyone to add new elements to HTML. Some of these tools, like the mysterious sounding Shadow DOM, are already making their way into web browsers.
Others, particularly Custom Elements, let you define your own HTML elements and their behaviour, and are just starting to arrive. All of them will hopefully be available in all the major desktop and mobile web browsers within the next 12 to 18 months.
Developers seem prone to hyperbole when talking about Custom Elements and Web Components in general - and with good reason. Web Components let you create, package and reuse your own HTML elements.
You mean we can write HTML elements on the fly? Tell me more
The easiest way to understand the power of Custom Elements is to look at an example. Take Google, which has gone to great lengths to make it pretty easy to embed a map in a webpage and use some JavaScript to control it. Using Custom Elements, though, Google could simplify the process even more by defining a new HTML element, say "<google-maps>".
Herein dwells the intertubes. And you - yes, you - can now tinker with its BONES
Browsers would see the made-up <google-maps> element and register it using the HTMLElement interface. The HTMLElement interface then allows developers to add methods and properties, in effect creating a per-element API. That means you can pass in attributes to control the element. So instead of needing to write a ton of JavaScript to set the centre of our map, we could simple do something like this: <google-maps latitude="0" longitude="0"></google-maps> and the browser would display a map centred in the Atlantic Ocean on a point about 380 miles south of the Ghanaian capital of Accra.
I didn't pick this example at random. Thanks to Polymer, a library of polyfills that includes support for Custom Elements, you can use <google-maps> element exactly as show above in any web browser today. That code element comes to us courtesy of Liferay software engineer and past jQuery contributor Eduardo Lundgren.
Now, while I started off talking about how Google could create a custom element, it’s worth noting Lundgren is independent – he doesn’t work for Google.
The truth is that anyone can create custom elements in HTML with Web Components (technically anyone can create new elements in HTML right now, without Custom Elements but there won't be any element-level API or other features that make Custom Elements actually useful).
Hey – WE'VE got the power now!
In the end, this may be the real power of Web Components - putting developers on a level playing field with web giants like Google and with standards bodies as well.
That's by design. In fact, once you get past the really great encapsulation that Web Components enable, most of what's revolutionary about them comes down to the way they shorten the distance from developer idea to web standard.
Part of the goal behind Web Components is to let web developers iterate on ideas before they become standardized. In other words, see how the web ends up using something new before you bother to start the standards process. When you do start the process, you then start with something that's already fleshed out, real-world tested and much closer to a consensus. This will hopefully create a more productive feedback cycle between web standards bodies and web developers.
Much of the effort behind Web Components has come from developers at Google and Mozilla, who put together a document called the The Extensible Web Manifesto. According to this: "In order for the open web to compete with its walled competitors, there must be a clear path for good ideas by web developers to become part of the infrastructure of the web. We must enable web developers to build the future web."
Never in the short history of the web have web developers had such power given to them. In fact, perhaps what's most remarkable about the web is that developers have created what we have today in spite of very limited input and control over the future of the web.
We take tools like XMLHttpRequest for granted today, but these exist not because a standards body created them, but because web developers used them in creative ways that drove browsers to adopt support.
Now, with Web Component support on the horizon, developers will finally be first-class citizens when it comes to determining the future of the web.
And with the bottleneck on progress open and more people involved through Web Components, maybe we can have our equivalent of more men on the moon more often. ®