The broken promise of Web Components

The assertions about the DOM are long on hyperbole but rely on e.g. benchmarks from a decade ago and broad hyperbole like:

“This was cumbersome. This was limiting. You could not prototype easily and quickly. You could not easily escape the limitations of UI libraries. etc. etc. etc.”

It would have been far more interesting to look at whether the broadest claims were even true, or why people ran into problems using various libraries. Every time I've done a test, React is significantly slower than using standard JavaScript + DOM but that's the wrong question to ask when you really care about whether it's a) fast enough and b) helping you write code faster, reducing maintenance or sharing costs, etc.

All I got from this is that using React makes life easier than calling the DOM APIs directly every time, which is technically true but doesn't say anything about e.g. how WebComponents compare when using abstraction following the best practices of software developers since something like the 1950s.

The “easy-peasy” example is:

    ['Hello', 'world'].map((text) => {
        return <p><span>{text}</span></p>
    })

The alternative given is:

    ['Hello', 'world'].forEach(text => {
    	const p = document.createElement('p')
    	const span = document.createElement('span')
    	span.textContent(text)
    	p.appendChild(span)
	
    	MyComponent.appendChild(p)
    })

Since the first example requires 140KB of React code plus a ton of setup code to get to that it's either careless or dishonest to compare the two without acknowledging the possibility of using a helper function or two to simplify the second one, as JavaScript developers have been doing routinely for multiple decades.

Again, not a slam on React, just this kind of unhelpful advocacy. It'd be a lot more interesting to compare real examples with multiple libraries and talk about how the different choices impact debugging, performance, isolation, etc.

> you can substitute your favorite library: Inferno, Preact, Vue, snabbdom, virtual-dom (or non-js libraries and frameworks like Elm, Om, etc.). Similarly, replace Polymer with Vaadin, or X-Tag, or…

It's gotten to the point where if you list JS frameworks, you can slip in 2-3 that don't exist and I don't think anybody would notice.

This article is trash. In retrospect it was a huge waste to coin the term "web component", by doing so the expectation is that web components eliminate all need for 3rd party JS libraries, which as the article points out, they don't. Instead "web components" is a set of low-level libraries that provide bits and pieces of stuff needed to make components.

The article makes the usual criticism that web components doesn't have a databinding spec. It's true, it's a short coming. But the lack of a databinding spec doesn't make Shadow DOM any less useful. The two are unrelated.

The author really likes JSX, but didn't bother to google "jsx web components"; if he had he might have come across this: https://skatejs.gitbooks.io/skatejs/content/

There are some real things to criticize about web components. Shadow DOM makes it hard to theme your app. Custom elements has some warts in regards to the way that some events are composed. But the article doesnt make these criticisms.

My team is using web components, polymer 1, 2, React, Vue and Riot in 3 strategic projects.

I have a bigger rant about web components, and polymer and interesting enough, I believe - none except one - of the article owner's comments matter much.

Here's another rant and what currently sucks at web components (for us)

1. Still no adequate browser support coverage (OP's point) - Google polymer team keeps the mood up, is excited and does great things but we're still waiting

-- for Firefox to support it, (which declined to implement html imports). I kind of think Mozilla is sabotaging the efforts for some political reason after reading their comments.

-- for Safari 10.2 to support it natively

-- for Edge to care.

Unless all the browsers support the v1 spec, we end up being just another JS framework and the Polyfill webcomponent-lite.js itself becomes a framework in competition with vue, react, riot, and others.

2. Web components (especially) polymer ones are not a good citizen inside an HTML page next to others.

-- Due to component scoping (which is ok), style scoping in the main document css (custom style) (which is weird) and DOM and shadow dom, you end up feeling hopeless at some point.

-- I just want to use the paper-toggle and I end up downloading 100s of files.

3. The opposite of "it just works" ( as someone wrote somewhere, kind of, like you invented the opposite of it just works.)

- Polymer, and the paper, iron and other libraries are cool, but they somehow fail silently and often. It's hard to figure out what went wrong.

4. Polymer team is trying to replicate the cool other JS tech and tools, and it just lags behind. (ES6 in polymer 2.0, the still beta app router, bower, gulp and OMG.js ....)

5. The iron, and then paper, and other elements are too heavily interdependent and no other leaner library or collection appears in sight.

- A lot of nested imports

- and the hopeless the wait for HTTP/2 and the future web of 2020s.

I will write later what can be done.

Web Components are damned awkward because they extend the damned awkwardness of the DOM rather than address it.

DOMNodes are these hot data structures when they're linked into the DOM tree. Writing (and even sometimes reading) from DOMNodes can cause whole page reflows or paints to occur, sometimes synchronously. The advice to "touch the DOM as little as possible" stems from the fact that the DOM has so many performance pitfalls.

The DOM is so damned awkward that it's faster to maintain a virtual DOM tree, diff changes to it on the next tick with those of the previous, and then only modify the real DOM tree with those changes like React does. Couple that to the fact that React's DOM update strategy is tuned for speed and they can hide/handle most weird DOM object creation/insertion rules, and overall you wind up with a less awkward system.

If I compose my page entirely out of Web Components, the chief benefit I see is good looking markup representative of what's on the page.

If I were to have designed a component system from DOM, I would have added a lightweight iframe-like tag that could be instantiated from a script/css/markup template package. Performance-wise, I thought that having a nested element's box be laid out and painted independently from the parent page could mitigate some of the global ripple effects of touching the DOM. Of course, this lite iframe's box itself would need to live in the parent page and its dimensions would have to factor into the page flow, and that could have global effects. I suspect there could be clever JavaScript or event system additions that would help limit the reflow and paint damage there.

I mean who cares, really. 90% of developers will spend time building reusable components that will be used exactly once, and and some people will open source some stuff that wedges in every suggestion and pull so it is 5 times the complexity any one person ever needs and then we will talk about the failed promise of web components.

Couple years ago I gave some thought about how to handle reusable JS in a sane fashion. Actually, a lot of thought. The end result was something that superficially sounds like Web Components, but it quite different underneath. I guess a good name for it would be "Web Behaviors".

It's not a framework or a library, but rather a set of rules and practices of how to do things. It will sounds somewhat weird, but I'll list them anyway. Maybe someone will find it useful:

- Overall mental model: libraries don't implement components, but rather change the behavior of certain elements on the page.

- No library keeps state in JavaScript variables. DOM is your model.

- All configuration is also done through DOM with liberal use of CSS selectors to reference things.

- No library has any direct dependencies on any other.

- Things that need to react to changes should (if at all possible) use timers. If that's not possible, they should register global event handlers, rather than attach them to individual components.

While this might horrify some people, it actually forced me to come up with rather nice, abstract behaviors that capture many common features I had to commonly implement. Also, this plays well with the notion of progressive enhancement. I recommend everyone to try it on some new web-based project of low to moderate complexity. Ir really does simplify a lot things.

For anyone interested, I wrote up a response: https://robdodson.me/regarding-the-broken-promise-of-web-com...

Kinda used it as an attempt to address some bigger questions around Web Components I've seen come up a bunch. Curious what you all think.

Just in case, architecture of components in Sciter. Could be interesting for some.

Assignment and composition - by CSS, and only by CSS, Sciter's specific prototype property:

   .myComponent {
     prototype: MyComponent url(components/my.tis);
     color: red; 
     ...
   }

where MyComponent is the name of script class in components/my.tis script file. That MyComponent looks like as

   class MyComponent : Element 
   {
     function attached() {
       // called when DOM element gets this class
       // a.k.a. DOM constructor

       // content initialization, if needed: 
       this.$content( <button.prev/> 
                      <button.next/> );
     } 
     function detached() {
       // called when DOM element looses this class
       // a.k.a. DOM destructor
     } 

     function method() {
        // some public method  
     } 
     property prop(v) {
        // some public property
        get { ... }  
        set { ... }
     } 

     event mousedown (evt) {
        // default mousedown event handler
     } 
     event mouseup (evt) {
        // default mouseup event handler
     } 

     event click $(button.next) {
        // click on its button.next
     } 
     event click $(button.prev) {
        // click on its button.prev
     } 

     // etc
   }

To use such component:

1. include CSS where the binding is defined (prototype above) 2. In markup to define matching element:

   <div.myComponent />  

Nothing too complicated and pretty effective. Could be done even 18 years ago: http://www.w3.org/TR/1999/WD-becss-19990804#behavior

This entire article is invalidated by the fact that React's DSL (or the TSX variant, to be precise) can be used to implement Web Components!

Take a look: https://github.com/wisercoder/uibuilder

I think your native web components example is wrong, or more probably outdated.

Here's an example with the latest wc spec: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sl...

But as far as I understand from the spec, sadly, you would still need a separate DSL that would leverage iterations, conditionals and other templating operations on top of web components.

The author of this article really gets web components wrong. You don't use JS for everything. Web components have a built in DSL.

The below from the article is ridiculous and HORRIBLY INNACURATE:

  ['Hello', 'world'].forEach(('text') => {
	const p = document.createElement('p')
	const span = document.createElement('span')
	span.textContent(text)
	p.appendChild(span)

  MyComponent.appendChild(p)
  })`

In RiotJs you would build a web component this way:

  <text-breaker-upper>
   <p each={this.input_str as out_text}>
     <span>{out_text}</span>
   </p>

    <script>
       this.input_str = input.split(" ");
    </script>
  </text-breaker-upper>

Then you declare it ON THE PAGE.

  <text-breaker-upper
      input_str="Hello World">
  <text-breaker-upper>

Web components much more intuitive, reusable, better separation of concerns, less bloat, and more elegant than React..no bastardization mixing of JSX, CSS, and JS, and how the web (and any sane technology) was meant to be.

The sooner this JS front end framework B.S. wasteland nightmare is behind us, the gournd salted on where it stood, and we laugh at JS like we laugh at COBOL.... the better in my opinion.

When done correctly web components aren't just about extensibility. They are also about encapsulation, debugging, testing, *ing, and then reusability.

React has a bigger community, more hype, more tooling around it, better native mobile support and better support for automated testing.

But if I had to pick my favourite, I'd have to go with Polymer because:

- It's simpler (fewer dependencies).

- Declaring styling and layout is cleaner (it's easier to visualise a component's appearance and to modify it during debugging because layout and styling are kept separate from a component's behavior logic). When it comes to debugging, styling/layout issues almost always happen independently from behaviour issues so it makes sense to keep them separate in the source.

- It works better with browsers' native development tools.

- No need for a compile step (and associated complexity that comes with it as your app grows).

It's not fair to pretend that React bypasses the DOM entirely. Ultimately, when the user clicks on a button, they are interacting with a DOM element, so the event still has to pass through the DOM layer. The DOM is still the API whether you like it or not.

I think we're approaching a point at which browsers will need to make some sort of break with the current DOM in order to provide the types of rich experiences engineers and users want. There's simply too much baggage with the current implementation, and this article highlights a lot of it: attribute values limited to strings, a global namespace for CSS, etc.

This is happening at other levels of the web with the HTTP/1 —> HTTPS/2 transition. We're patching over shortcomings in the DOM right now with JavaScript, but it's easy to see the appeal of a native solution to some of these issues that doesn't require a facade over the actual thing that people interact with.

This whole tangled mess of JavaScript, HTML, CSS and custom expression languages screams Lisp.

Web Components have turned into a dead end for me. Instead, I like what Facebook has done in that they have proven the declarative approach can translate to native and even VR in a very intuitive and approachable way. As far as I'm concerned this is the future for awhile as I've been having a breezy easy time doing native with React and have never experienced a simpler way to develop anything. I have also programmed in Vue but for some reason still prefer React. Possibly because it seems there is more community support, usage and toolage and of course it supports more types of devices, aside from being baised.

Important context (Twitter thread) for this article, by the same author a few days before publishing it: https://twitter.com/dmitriid/status/841172534586429441

I don't think Web Components are a "framework replacement", they are an addition.

Stuff like Bootstrap needs them to enrich their "top down" approach with CSS and HTML so you don't have to mess around with either their source OR CSS classes and "their" HTML structure everywhere to get the components right. You add their CSS & (Web Component) JS at the top and use their custom components as the "leafs" of your sites. I wrote about it here: https://dev.to/kayis/web-components-for-your-custom-elements

The other frameworks like React, Angular, Cycle or Ember will then become the Data-flow layer of the app.

> In 2017 React fulfills all the promises of Web Components

Not really - React needs a large run time, and it's really not a good fit for an existing app where you need a true component you can pop in and use within a Java or Rails app.

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

[Typo flagged and fixed]

It starts to sound like browsers should support JSX natively...