Web Components: concerns and opportunities

Warning This article was written over six months ago, and may contain outdated information.

On the 21st of March I had the plea­sure of par­tic­i­pat­ing in the Web Com­po­nents pan­el at Edge Conf, and the priv­i­lege of giv­ing the intro­duc­tion to the pan­el. I’m a strong advo­cate of Web Com­po­nents and it was great to be able to pro­vide my opin­ion on them, along­side some real experts in the field, as well as hear ques­tions and feed­back from the com­mu­ni­ty. The main con­cern which was raised is that, as devel­op­ers cre­ate their own ele­ments, some impor­tant con­sid­er­a­tions — acces­si­bil­i­ty not least — could get for­got­ten about.

If you want to see the pan­el in full — or, if you’re not sure what I’m talk­ing about and just want to watch my ten-minute intro­duc­tion — the video has been made freely available:

The dis­cus­sion con­tin­ued after the con­fer­ence, on Twit­ter and blogs. Jere­my Kei­th looked at the acces­si­bil­i­ty angle, say­ing:

Just adding more and more pre­de­fined ARIA roles won’t cut it—we need some kind of exten­si­ble acces­si­bil­i­ty that match­es the expres­sive pow­er of Web Components.

Paul Lewis took a broad­er view, and echoed a poten­tial pit­fall I men­tioned in my intro­duc­tion, which I dubbed the pro­lif­er­a­tion of crap:

Since by default there is very lit­tle that enforces good acces­si­bil­i­ty, secu­ri­ty and per­for­mance, we’ll end up with a load of com­po­nents that are ter­ri­ble, with no way for devel­op­ers to sort the wheat from the chaff.

My co-pan­el­list Soledad Penadés per­fect­ly summed up what I believe is the key to the whole issue:

Web com­po­nents are just a tool that will enable you to write bet­ter and encap­su­lat­ed front end code. They are not a sil­ver bul­let that automag­i­cal­ly makes every­thing work.

This, I think, is the mes­sage that needs to be drummed in. Web Com­po­nents are a way that we, the web devel­op­ers, get access to low­er lev­el APIs, allow­ing us to cre­ate our own ele­ments, bypass­ing the imple­men­ta­tion and stan­dard­i­s­a­tion process. It gives us much more free­dom — and much more respon­si­bil­i­ty. While stan­dard­i­s­a­tion can be slow, it means that UI ele­ments imple­ment­ed in browsers have the ben­e­fit of long con­sid­er­a­tion of usabil­i­ty and acces­si­bil­i­ty; as we move more rapid­ly to cre­ate our own, the bur­den (and I don’t mean that to have a neg­a­tive con­no­ta­tion) of cre­at­ing usable, acces­si­ble ele­ments is placed onto our shoulders.

The prob­lem with that is, as Bruce Law­son said:

The pri­ma­ry imped­i­ment to acces­si­bil­i­ty on the Web isn’t tech­ni­cal, it’s social. It’s that many (most?) devel­op­ers don’t give a toss.

Mairead Buchan has done some think­ing about that:

The prob­lem, as I see it, is we have no mech­a­nism for qual­i­ty con­trol and no plat­form for pro­mot­ing the best we have to offer. This is a peren­ni­al prob­lem with our devel­op­ment stack.

Her pro­posed solu­tion is this: a com­mu­ni­ty upvot­ing plat­form that lets us col­lab­o­rate on best prac­tise in front end code. I think that’s def­i­nite­ly an idea that’s worth look­ing into, and the team at webcomponents.org are already on the case. The idea is that the plat­form could act as a fil­ter for the pro­lif­er­a­tion of crap, pro­mot­ing best prac­tices until we arrive at a set of com­mu­ni­ty-made com­po­nents that can be sub­mit­ted back to browsers for native imple­men­ta­tion. And that’s what makes me most excit­ed about Web Com­po­nents: the things we make can define the future of the things we make.

I also want to say that I’m delight­ed that the Edge Conf pan­el has pro­voked the debate around this sub­ject. If we’re going to assume this great respon­si­bil­i­ty, we need to hear everyone’s opinions.

Update: A round-up by the con­fer­ence organ­is­ers, which tells me that our pan­el was one of the most enjoyed, and I was vot­ed fourth in the list of stand-out con­trib­u­tors! Thanks to all who voted.

Comments are closed.