Talking about Web Components with Eric Bidelman

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

In Sep­tem­ber of last year I asked Google’s Eric Bidel­man some ques­tions about web com­po­nents for a fea­ture I was writ­ing. Unfor­tu­nate­ly it turned out there was no room in the arti­cle for Eric’s answers, but I recent­ly stum­bled across them again and decid­ed they are too good to go to waste, so here they are.

Thanks very much to Eric for answer­ing my ques­tions, and apolo­gies if the pas­sage of time has out­dat­ed any answers.

What’s your role in the creation or development of web components?

I’m a devel­op­er advo­cate on the Chrome team. My focus the last cou­ple of years has been bleed­ing edge HTML5 fea­tures. Mem­bers of the Chrome team start­ed the spec efforts upwards of 2–3 years ago (my con­tri­bu­tion to specs is that I helped name “HTML Imports” :)) I remem­ber see­ing inter­nal pre­sen­ta­tions on Shad­ow DOM from folks like Alex Rus­sell and Dim­itri Glazkov; leg­ends on the web. The whole effort real­ly excit­ed me, so I hopped on board.

Around Google I/O, we kick start­ed Poly­mer and I’ve been on that team ever since.

What was the motivation behind their creation?

The need for a more pow­er­ful web plat­form. If you look at the hoops that devel­op­ers have to go through to build today’s MVC frame­works and wid­get sets, it’s crazi­ness. It’s because the web has lacked the fun­da­men­tals like encap­su­la­tion, style scop­ing, expres­sive­ness, and the share­abil­i­ty and reusabil­i­ty of code. As a mem­ber of the Chrome team, my goal is to help make devel­op­ers infi­nite­ly more pro­duc­tive than we have been. No one would rein­vent the wheel every time he/she starts a new project. This is why I’m stoked about every­thing Web Com­po­nents brings to the table. I strong­ly believe they’re the future for devel­op­ing on the web.

What have been the challenges or learning opportunities in creating them?

Not sure about cre­at­ing them. I don’t write C++ :) But teach­ing devel­op­ers about “com­po­nents” has been a chal­lenge. We web devs are used a cer­tain way of doing things (e.g. every­thing is glob­al). Mak­ing log­i­cal pieces of func­tion­al­i­ty that work seam­less­ly togeth­er is some­thing total­ly for­eign to us. A lot of peo­ple ask ques­tions like, “how do I do that in a web com­po­nent?”. 90% of the time the answer is “exact­ly the same as before”. Web com­po­nents are a men­tal mod­el shift, but once you make the leap, it’s hard look back.

Are there any potential drawbacks in terms of accessibility or performance?

I’ve seen a few arti­cles on a11y and Shad­ow DOM but more need more research. There’s a com­mon mis­con­cep­tion that con­tent in Shad­ow DOM is not acces­si­ble. Steve Faulkn­er had a nice write­up on this top­ic a while back and came away pret­ty happy.

Most assis­tive tech­nolo­gies hook direct­ly into the browser’s ren­der­ing tree, so they just see the ful­ly com­posed tree. In fact, if you exam­ine one of the native HTML ele­ments that use Shad­ow DOM, <input type="date" /> for exam­ple, you’ll notice ARIA attrib­ut­es inside the tree. These work great with assis­tive tech­nol­o­gy today! Oth­er types of assis­tive tools like Chromevox will need to be updat­ed to learn how to tra­verse the Shad­ow DOM. There’s ongo­ing work to make that happen.

Per­for­mance is extreme­ly impor­tant, but main­ly unex­plored at this point. We need to build the foun­da­tion before we can opti­mize it, both at the poly­fill lay­er and native imple­men­ta­tions. That said, there’s been a lot of recent work in Blink to opti­mize Shad­ow DOM. The Blink guys/gals tell me there is tons of low hang­ing fruit across the board. HTML Imports land­ing will also be a bless­ing; make load­ing faster.

When it comes to perf, I usu­al­ly say, “build­ing on top of web com­po­nents won’t mag­i­cal­ly make an app faster. It’ll make a devel­op­er faster!” These new APIs are pro­duc­tiv­i­ty tools that the web plat­form has need­ed for years.

What parts of them are you personally most excited about?

Hon­est­ly, the whole stack. It’s great that all of the specs are use­ful inde­pen­dent­ly of each oth­er… but putting every­thing togeth­er is magical.

Where do you see the extensible web concept going next?

My beef with the spec process has always been that the peo­ple stan­dard­iz­ing APIs for the web, are not web devel­op­ers them­selves. That’s changed some­what in recent years, but the shift from spec -> imple­men­ta­tion to imple­men­ta­tion -> spec makes me have warm fuzzies.

Poly­mer is a great exam­ple of where the con­cept of the exten­si­ble web is work­ing. We start­ed the project as an out­let for devel­op­ers to try the APIs and give us feed­back. The feed­back loop from devel­op­ers Poly­mer team Blink engi­neers has been tremen­dous­ly suc­cess­ful. See­ing this process con­tin­u­al­ly play out reminds me that we’re onto some­thing spe­cial. There are a lot of smart peo­ple work­ing to make devel­op­ers’ lives eas­i­er. It’s extreme­ly encouraging.

DOM Promis­es are anoth­er exam­ple of some­thing that made it to the plat­form because devel­op­ers asked for it. I hope we (the com­mu­ni­ty) con­tin­ue to craft new APIs based on devel­op­er pain points.

1 comment on
“Talking about Web Components with Eric Bidelman”

  1. I total­ly for­got about this! Thanks for post­ing. It’s fun to look back to Sept and see how things have even changed since then. For exam­ple, HTML imports is land­ing in Chrome 36. Woot!