This article is just awful. There seem to be two main criticisms here: 1. Web Components don't provide a DSL for creating DOM trees. This is true, because Web

This article is just awful. There seem to be two main criticisms here: 1. Web Components don't provide a DSL for creating DOM trees. This is true, because Web Components don't provide a DSL for creating DOM trees! That's and entirely separate concern that can be addressed by a library[1] or by a future, more-ergonomic tree construction API in the DOM. 2. The author doesn't like Polymer's templates. Which is, nearly as unrelated to Web Components as the first complaint, because it's also the same as the first complaint. Polymer's template system allows you to create DOM trees, and automatically wire together properties and events. That's it. You can do this without using custom elements at all. You can also use any number of ways to construct trees: JSX, DSLs, HTML templates and cloning, string templates, etc. It's no different from any other framework including React. And then he repeats Sebastian Markbåge's, creator of React, tired complaint that Web Components can only consume string data. This is FUD, pure and simple. Web Components are Elements, and Elements are Objects with properties. Every Web Components framework relies on this for data-binding or setting "props". And... that's it. That's basically the extent of the critique. The author could have actually tried to compare React and Web Components and he would have seen that: 1. The component models are very similar, there are analogs for most lifecycle events. 2. Web Components don't prescribe state management or dataflow, and there are indeed functional, unidirectional, immutable (by convention), Web Components libraries and patterns out there. 3. Shadow DOM fixes nearly everything that css-modules address in a native and performant way. Web Components aren't a be-all-end-all standard. They are a few fixes to the platform that should have been there from the beginning, namely that you should be able to extend the HTML vocabulary (Custom Elements), you should be able to encapsulate some DOM and styling (Shadow DOM, which most browsers already had for their own UIs), and that you should be able to ship and parse _potential_ DOM (<template>). That's it. Everything else is either a library responsibility and/or TDB. Web Components are a foundation to make it easier to create frameworks, libraries, and an base-level interop story that answers some, but not all, critical, simple questions: How do I write a widget? : Extend HTMLElement How do I keep other scripts and styles from interfering with my widget's internals? : Put the internals in a ShadowRoot. How do I scope my own styles? : Put them in a ShadowRoot How do I instantiate my widget: Use a tag in markup, call createElement(), or call it's constructor. Anyone coming to the web platform as a new developer now doesn't have to sift though 100 frameworks and contradictory tutorials for such simple questions, the platform provides answers, as it should have from the beginning. [1]: See Hyperscript as a React-like example https://github.com/hyperhype/hyperscript https://github.com/hyperhype/hyperscript