soledad penadés

I was invited to join and give a lightning talk at the Extensible Web Summit that was held in Berlin past week, as part of the whole JSFest.berlin series of events.

The structure of the event consisted in having a series of introductory lightning talks to "set the tone" and then the rest would be a sort of unconference where people would suggest topics to talk about and then we would build a timetable collaboratively.

My lightning talk

The topic for my talk was... Web Components. Which was quite interesting because I have been working/fighting with them and various implementations in various levels of completeness at the same time lately, so I definitely had some things to add!

I didn't want people to get distracted by slides (including myself) so I didn't have any. Exciting! Also challenging.

These are the notes I more or less followed for my minitalk:

When I speak to the average developer they often cannot see any reason to use Web Components

The question I'm asked 99% of the time is "why, when I can do the same with divs? with jQuery even? what is the point?"

And that's probably because they are SO hard to understand

• The specs--the four of them-- are really confusing / dense. Four specs you need to understand to totally grasp how everything works together.
• Explainer articles too often drink the Kool Aid, so readers are like: fine, this seems amazing, but what can it do for me and why should I use any of this in my projects?
• Libraries/frameworks built on top of Web Components hide too much of their complexity by adding more complexity, further confusing matters (perhaps they are trying to do too many things at the same time?). Often, people cannot even distinguish between Polymer and Web Components: are they the same? which one does what? do I need Polymer? or only some parts?
• Are we supposed to use Web Components for visual AND non visual components? Where do you draw the line? How can you explain to people that they let you write your own HTML elements, and next thing you do is use an invisible tag that has no visual output but performs some ~encapsulated magic~?

And if they are supposed to be a new encapsulation method, they don't play nicely with established workflows--they are highly disruptive both for humans and computers:

• It's really hard to parse in our minds what the dependencies of a component (described in an HTML import) and all its dependencies (described in possibly multiple nested HTML imports) are. Taking over a component based project can easily get horrible.
• HTML imports totally break existing CSS/JS compression/linting chains and workflows.
• Yes, there is Vulcaniser, a tool from Polymer that amalgamates all the imports into a couple of files, but it still doesn't feel quite there: we get an HTML and a CSS file that still need a polyfill to be loaded.
• We need this polyfill for using HTML imports, and we will need it for a while, and it doesn't work with file:/// urls because it makes a hidden XMLHttpRequest that no one expects. In contrast, we don't need one for loading JS and CSS locally.
• HTML Imports generate a need for tools that parse the imports and identify the dependencies and essentially... pretend to be a browser? Doesn't this smell like duplication of efforts? And why two dependency loading systems? (ES6 require and HTML imports)

There's also a problem with hiding too much complexity and encapsulating too much:

• Users of "third party" Web Components might not be aware of the "hell" they are conjuring in the DOM when said components are "heavyweight" but also encapsulated, so it's hard to figure out what is going on.
• It might also make components hard to extend: you might have a widget that almost does all you need except for one thing, but it's all encapsulated and ooh you can't hook on any of the things it does so you have to rewrite it all.
• Perhaps we need to discuss more about use cases and patterns for writing modular components and extending them.

It's hard to make some things degrade nicely or even just make them work at all when the specs are not fully implemented in a platform--specially the CSS side of the spec

• For example, the Shadow DOM selectors are not implemented in Firefox OS yet, so a component that uses Shadow DOM needs double styling selectors and some weird tricks to work in Gaia (Firefox OS' UI layer) and platforms that do have support for Shadow DOM

And not directly related to Web Components, but in relation to spec work and disruptive browser support for new features:

• Spec and browser people live in a different bubble where you can totally rewrite things from one day to the other. Throw everything away! Change the rules! No backwards compatibility? No problem!
• But we need to be considerate with "normal" developers.
• We need to understand that most of the people cannot afford to totally change their chain or workflows, or they just do not understand what we are getting at (reasons above)
• Then if they try to understand, they go to mailing lists and they see those fights and all the politics and... they step back, or disappear for good. It's just not a healthy environment. I am subscribed to several API lists and I only read them when I'm on a plane so I can't go and immediately reply.
• If the W3C, or any other standardisation organisation wants to attract "normal" developers to get more diverse inputs, they/we should start by being respectful to everyone. Don't try to show everyone how superclever you are. Don't be a jerk. Don't scare people away, because then only the loud ones stay, and the quieter shy people, or people who have more urgent matters to attend (such as, you know, having a working business website even if it's not using the latest and greatest API) will just leave.
• So I want to remind everyone that we need to be considerate of each others' problems and needs. We need to make an effort to speak other people's language--and specially technical people need to do that. Confusing or opaque specs only lead to errors and misinterpretations.
• We all want to make the web better, but we need to work on this together!

Thanks

With thanks to all the people whose brain I've been picking lately on the subject of Web Components: Angelina, Wilson, Francisco, Les, Potch, Fred and Christian.