Uncomfortably Excited

Jeremy Keith is wringing his hands about Web Components. I likewise can’t attend the second Extensible Web Summit and so have a bit of time to respond here.

Full disclosure: I helped design Web Components and, with Dimitri Glazkov and Alex Komoroske, helped lead the team at Google that brought them from concept to reality. I am, as they say, invested.

Jeremy’s argument, if I can paraphrase, is that people will build Web Components and this might be bad. He says:

Web developers could ensure that their Web Components are accessible, using appropriate ARIA properties.

But I fear that Sturgeon’s Law is going to dominate Web Components. The comparison that’s often cited for Web Components is the creation of jQuery plug-ins. And let’s face it, 90% of jQuery plug-ins are crap.

Piffle and tosh.

90% of JQuery plugins don’t account for 90% of the use of JQuery plugins. The distribution of popularity is as top-heavy there as it is in the rest of the JS UI library landscape in which developers have agency to choose components on quality/price/etc. The implicit argument seems willfully ignorant of the recent history of JS libraries wherein successful libraries receive investment and scrutiny, raising their quality level. Indeed, the JS library world is a towering example of investment creating better results: the winners are near-universally compatible with progressive enhancement, a11y, and i18n. If there’s any lesson to be learned it should be that time and money can improve outcomes when focused on important libraries. Doing general good, then, comes down to aiming specific critique and investment at specific code. A corollary is that identifying which bits will have the most influence in raising the average is valuable.

Web Components do this cycle a solid: because they are declarative by default we don’t need to rely on long-delayed developer surveys to understand what is in wide use. Crawlers and browsers that encounter custom elements can help inform our community about what’s most popular. This will allow better and more timely targeting of investment and scrutiny.

This is worlds different than browser feature development where what’s done is done and can scarcely change.

A particularly poor analogy is deployed in the argument that Web Components are somehow a rehash of Apple’s introduction of <meta name="viewport" value="...">. This invokes magical behavior in some browsers. We’re meant to believe that this is a cautionary tale for an ecosystem of intentionally included component definitions which cannot introduce magic and which are not bound by a closed vocabulary that is defacto exclusive and competitive — other browsers couldn’t easily support the same incantation and provide different behavior without incurring developer wrath. The difference in power and incentives for browser vendors and library authors ought to make the reader squirm, but the details of the argument render it entirely limp. There is no reasonable comparison to be drawn.

This isn’t to ignore the punchline, which is that copy/paste is a powerful way of propagating (potentially maladaptive) snippets of content through the web. Initial quality of exemplars does matter, but as discussed previously, ignoring the effects that compound over time leads to a poor analysis.

Luckily we’ve been thinking very hard about this at Google and have invested heavily in Polymer and high-quality Material Design components that are, as I write this, undergoing review and enhancement for accessibility. One hopes this will ease Jeremy’s troubled mind. Seeding the world with a high-quality, opinionated framework is something that’s not only happening, it’s something we’ve spent years on in an effort to provide one set of exemplars that others can be judged against.

Overall, the concerns expressed in the piece are vague, but they ought not be. The economics of the new situation that Web Components introduce are (intentionally) tilted in a direction that provides ability for cream to rise to the top — and for the community to quickly judge if it smells off and do something about it.

Yes, messes will be made. But that’s also the status quo. We get by. The ecosystem sets the incentives and individuals can adapt or not; the outcomes are predictable. What matters from here is that we take the opportunity to apply Jeremy’s finely-tuned sense of taste and focus it on specific outcomes, not the entire distribution of possible outcomes. It’s the only way to make progress real.

PS: Extensibility and the Manifesto aren’t about about Web Components per sae. Yes, we extracted these principals from the approach our team took towards building Web Components and the associated technologies, but it cuts much, much deeper. It’s about asking “how do these bits join up?” when you see related imperative and declarative forms in the platform. When there’s only declarative and not imperative, extensibility begs the question “how does that thing work? how would we implement it from user-space?”. Web Components do this for HTML. Service Workers do this for network caching and AppCache. Web Audio is starting to embody this for playing sound in the platform. There’s much more to do in nearly every area. We must demand the whole shebang be explained in JS or low-level APIs (yes, I AM looking at you, CSS).

6 Comments

  1. Posted September 11, 2014 at 11:40 am | Permalink

    Like I said (multiple times), I am very excited about Web Components. Sorry if my note of caution comes across as hand-wringing.

    Apologies for writing such “piffle and tosh.”

  2. Posted September 12, 2014 at 4:30 am | Permalink

    Web components are really exciting, but I have the same fears as Jeremy, it’s about people, not tech.

    Re: “thinking very hard” at Google, you mean like what AngularJS is doing in their Docs, for instance?
    https://twitter.com/pauljadam/status/499617653292826624

    I really hope Web Docs are taken more seriously than this.

  3. Posted September 15, 2014 at 9:18 am | Permalink

    I finally got (took?) a chance to play with Web Components & Polymer on a cross-country flight yesterday. It’s great! It feels natural(ish). It’s an abstraction we needed. And now I don’t feel like those years writing XBL weren’t wasted…

  4. Posted September 22, 2014 at 2:40 pm | Permalink

    Some relevant links concerning the “piffle and tosh” characterisation of any display of concern around web components…

    Soledad Penadés:
    http://soledadpenades.com/2014/09/19/extensible-web-summit-berlin-2014-my-lightning-talk-on-web-components/

    “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.”

    Bruce Lawson:
    http://www.brucelawson.co.uk/2014/extensible-web-summit-berlin/

    “We need to ensure that all devs who want to can participate by allowing ease of collaboration, courteous discourse.”

  5. Posted October 27, 2014 at 6:28 pm | Permalink

    90% of JQuery plugins don’t account for 90% of the use of JQuery plugins. The distribution of popularity is as top-heavy there as it is in the rest of the JS UI library landscape in which developers have agency to choose components on quality/price/etc. The implicit argument seems willfully ignorant of the recent history of JS libraries wherein successful libraries receive investment and scrutiny, raising their quality level. Indeed, the JS library world is a towering example of investment creating better results: the winners are near-universally compatible with progressive enhancement, a11y, and i18n.

    I know you’re trying to answer Jeremy’s argument on jQuery plugins here but your thought here is a non sequitur. Jeremy’s point is about plugins, not libraries. You start out talking about plugins, but then for some reason move on to libraries. Why? They’re not really the same thing, especially in the context of this discussion.

    I don’t think it’s true that jQuery plugins have had the same fate as libraries, as you imply (although I’m not sure if that’s what you meant). Jeremy is spot-on: jQuery plugins are generally very big, bloated, and they have been customarily included as separate scripts, often loaded synchronously in the head of the document. That’s basically the problem Jeremy was talking about (although I’m adding to his word) and I think he’s rightfully concerned about the same problem happening with Web components.

    Not to say that the components scene will end up just as bad. But I think it’s fine to have some skeptical constructive criticism, seeing the prior paths we’ve paved.

  6. Kevin
    Posted December 7, 2014 at 8:47 am | Permalink

    Tone down the snark and fey pomposity.