web components

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.