web components

Mike Hartington glows about how good and useful the Shadow DOM is:

[Shadow DOM is] actually built on two simple ideas, isolation and location. Need to create a bit of DOM that is isolated from the global scope? Shadow DOM is here to help. Need to specify the exact location of a piece of DOM? Shadow DOMs scope API is what you need!

It can be helpful to think of components that use Shadow DOM as modules for HTML. Markup and styles are isolated to their own DOM tree, and removed from the global context.

Last time we talked about it around here, I showed how Twitter is using it for embedded tweets — which is a pretty awesome use case — and how it can fall back to an iframe. Mike says they polyfill it in unsupported situations.

(more…)

Monica Dinculescu on web components and why we might care:

... before web components came around, you had to wait on all browsers to agree on a new element (like, a date picker). And even after they agreed on a new element, it took them yeaaaaars to implement it... With web components, web developers get to write such elements, so that you don't have to wait for 10 years before all browsers agree that they should implement a date picker.

I struggle with trying to figure out if web components (with Polymer or not) are really "the future" or not. People definitely haven't adopted them with the same ferocious appetite as New JavaScript, which also tackles componentization. But they are a web standard with growing native support, so... probably?

I'm probably wrong in conflating the two, though. Even the React Docs say:

React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary.

Some interesting thoughts from Jeremy Keith about his concerns with Web Components:

Compare Service Workers to web components.

First of all, ask the question “who benefits from this technology?” In the case of Service Workers, it’s the end users. They get faster websites that handle network failure better. In the case of web components, there are no direct end-user benefits. Web components exist to make developers lives easier. That’s absolutely fine, but any developer convenience gained by the use of web components can’t come at the expense of the user—that price is too high.