Why the React community is missing the point about Web Components

I'm a generalist web developer with my hands in a few libraries.I don't consider myself a purist or evangelist of any technical approach, especially on the front end. That is to say, I don't feel like I have a dog in the Web Components fight, but I find this discussion very interesting.

In a conversation about technical trends lately, I got talking to @bennypowers about the dialog surrounding Web Components, and the push back from the web community. Regardless of where you stand on the issue, I found the comment very much worth reading.

Benny Powers 🇮🇱🇨🇦 • Nov 3 '18 • Edited on Nov 3 • Edited

In my humble opinion, the react community is too heavily invested in their library. I can understand that, given the runaway success of their library, but I do think the bubble will eventually burst. The wise developer will begin to sharpen their custom-elements-fu and should consider them for their next project.

React vs. Web Components is a False Dichotomy.

Since web components are browser standards, they are as usable within react components as divs are. There are some minor caveats surrounding custom events, due to the odd way that react works with the DOM, but there's a well-trodden cowpath for working around react's eccentricities on that front. Preact, by the way, largely mitigates those caveats.
Although it's my opinion that web components are technically superior to React components because they are natively supported by the web browser instead of requiring developers to fight the browser, there is actually no contradiction between the two.

React is Tomorrow's MooTools

React is quite popular today, it's true, but that might not always be the case. <span> isn't going anywhere, neither is querySelector, but we've seen plenty of library frameworks fall to the wayside. In the mean time, web components have gained traction in the enterprise world due to their obvious future-proofing benefits, and interoperability between browsers and libraries.

Today, Web Components are Widely Supported

Now that Firefox supports Shadow DOM and Custom Elements, and the Edge team has announced their intent to ship, the web component standards have truly arrived, and are a compelling feature of the platform. I don't think it's a coincidence that we've seen a lot of shade thrown on WC's on social media this past month. Now that the standards have landed it's a much more looming threat to all-js component models.

The FUD Around WC's is Unjustified

A lot of the react-world arguments against web components boil down to some variation on

• The standards aren't accepted
• They are hard to work with
• They can't do what react does

But this is simply not true. The now-deprecated v0 standards are no longer supported, they've been replaced with the v1 standard, which as we've seen is widely supported.
While it's true that the low-level APIs described by the standards can be cumbersome, libraries and base classes like hybridsjs or lit-element smooth over those bumps with only a tiny addition to js page load sizes.
As far as features, web component libraries can do everything react can do and more without the VDOM overhead or the cognitive and tooling complexity added by that abstraction - Web component dev tools are browser/dom dev tools.

An Anecdote

I have a friend at a browser vendor. A few years back, his team was busy building browser UIs and features using react.js. Even as he praised the elegance of the one-way-data-flow-with-central-store architecture (now easily implemented with custom element base classes like GluonElement or LitElement and state containers like redux etc), he complained about the performance limits of the React JS library (his words). I suggested he check out web components, since with them the performance limits would be the browser itself, rather than a JS library. He shot off an IM to a coworker. It's a few years later and lo and behold, that same browser vendor is currently in the process of re-writing their UI components with their own web-component-based library.

Summary

React brought a lot of wonderful things to the web development community.

• A Functional approach to UI
• One-way-data-flow patterns
• Popularizing the component model

But it also brought a lot of baggage with it.

• FUD around working directly with the DOM
• Cumbersome and unnecessary tooling
• The popular misconception that react is the only way to do component-based UIs on the web

Today, you can factor a modular, component-based front-end app without any browser flags, build steps, bundling, or tooling other than the browser and a text editor. And it will run on all the major browsers.

It's clear to me that the future will be built on open standards rather than bespoke implementations. However much good React has done for the web community (and I hope I clearly recognized that good), it won't be able to compete with that.

If you want to learn more about Web Components, Benny is one of a few DEV members who publish great tutorials on the subject.

Lets Build Web Components! Part 1: The Standards

Benny Powers 🇮🇱🇨🇦 ・ Sep 18 '18

#webcomponents #customelements #javascript #html

Web Components: from zero to hero

Pascal Schilp ・ Oct 28 '18

#javascript #webcomponents

Happy coding ❤️

Comments

[Reid Burton]

Note: Safari does not plan to support the is='' thing anytime soon, or ever.

[Antonio Calderone]

I've recently started working in a large scale project with webcomponents after some PoC with polymer 4 years ago.
I use to be fw or lib agnostic as much as possible but honestly, last 3 large scale project where I have worked on were made in react because of many reasons that are not part of the discussion, it's just to give some context.

My humble opinion is that the WC still not ready to be used, there are not a properly defined way to get the list of attributes, attributeChangedCallback doesn't work in some cases even if I'm using just a line of code and some other little painful staffs.
I loved the webcomponent concept when I read the first article mentioning that years ago, but again, after several years, doesn't seem to be ready to be used at scale.

On the other side, if some issues will be resolved, I would like to check it again together with React or something else limiting WC to simpler visual components. I think that orchestration and state management it's not its best and I still prefer to use something more mature and reliable (that doesn't declare props in the wild in the main object for example).

Is my humble opinion, I don't want to blame WC, and by the way, I don't have the same experience with WC that I have with other libs like React or Vue so, maybe I miss something but by far, WC is requiring to my team (the entire project have more than 140 developers, but the teams are splitted into units of 4 devs with bounded and independent scope) more time and requiring more effort to make a simple package (composition of components and logic) to work than any of the two above.

[Alex]

You are forgetting a very important problem that React was intended to solve... That is excessive DOM manipulation with native javascript. You can say WebComponents are good and well supported and safe, but you can't say that the devs implementing the web components are any more knowledgeable about DOM bottlenecks than they were 5 years ago. React only updates the DOM when necessary. Remember when we had monolith front-ends with jquery, and every piece of javascript having a slice of the DOM pie? How is WebComponents gonna solve the problem of batching and optimising DOM reads/writes on a monolith codebase?

[Brian Cruickshank]

lit-html provides a good example of how to solve that problem in a way that works well within a Web Component context: From npmjs.com/package/lit-html/v/0.2.1 :
lit-html's method of creating HTML templates with markers for dynamic sections, rather than updating the final DOM tree, enables efficient updates of previously rendered DOM

[Robert Wensman]

It seems to me that the WC community is also completely missing the point with React. For those who build static non-responsive web pages based on interactive components, there is probably no reason to use React at all. You could just as well use WC. However, for those who wish to build the dynamic pages of the future, there is certainly a need for the likes of React.

So what is React? It seems to me that this article completely misses the point on that. React is not just a way to define static components on a website. React is foremost a way to constantly and dynamically rebuild those components, without loosing the state of some components mind you!

So, react and the synthetic DOM comes to use when:

1. The UI is rebuilt when the screen size changes.
2. The UI is rebuilt when the data model changes.

And this is the whole point with the synthetic DOM, whether you like the (slight?) performance penalty or not.

The whole point with React, is that you can write your code, without concern for how all the components will be updated/relocated and moved once the dynamic user interface updates.

And as far as I can see, WC has no solution for this whatsoever. WC is just a way to isolate and package components, but WC in itself offer no coherent and thought out methodology to rebuild and rearrange those components.

So, if there is a resistance from the React community, in adopting WC... think again. Perhaps there is a valid reason for it.

And, it is also my guess that many of those who fail to se value in React over WC, probably never built very dynamic user interfaces.

[Mark Schmeets]

I remember the old saw about "alternating hard and soft layers". React and WC are exactly that. WC provide the "hard layer" basically an extension of HTML as a platform. React is the soft layer we use to assemble the WC into our working applications. Think C components, plus Python. Or C++ COM and Visual Basic.

The only problem is that React and WC do not interface very cleanly for events, or properties. Once that is fixed it's going to be a great combination. Just wish the React team would put more a higher priority on that.

[Beknar Askarov]

First time I've heard "use the platform",
I thought everyone is using it, no? Perhaps they meant use the platform More?

As I have learnt later, what they actually meant was -
"Use the new features that are not shipped yet and mostly supported only by Chrome, so use the Chrome, and polyfill for everyone else".

But in light of recent news with Edge moving to Chromium stack,
"Use the platform = Use the Chrome"? Coincidence?

Even though they might be right in a longer term, but in short term, businesses that have invested in those ideas, probably are downshifting now.
I haven't seen anyone actually benefiting a lot from webcomponents reuse, mixing them inside of their applications with other frameworks, since most webcomponents libraries provide means to make a framework around them, just add Redux, and don't look around, you are using platform now.

Microfrontends architecture articles encourage use of webcomponents. But you can't have custom elements defined twice in the same page. I know that message was that you isolate your microfrontend, not use it to build everything. But message was picked up wrong by many.

I may have sounded salty, its just because I just have invested a lot in platform, I hope it will pay off one day, React's support will definitely help.

And lets wait for webassembly to replace javascript, lets see what use the platform will mean then:)

[Robert Biggs]

Caleb, if you want save and reload for React you might try using ES6 imports and HTM: npmjs.com/package/htm. HTM lets you use ES6 template literals that resemble JSX sort of. I've used it with Preact. You literally skip the build step. You do need to run a server instance in the project to run the page in the browser so that ES6 imports work in the browser. Since this works with Preact I'm assuming the same thing would work with React.

Here's a live demo of Preact using HTM running in the browser without a build step: htm-demo-preact.glitch.me

[Caleb Williams]

Can't believe I'm just now seeing this, but it is what it is. In case any one else stumbles on this conversation, what I'm talking about is native custom event binding. In React, you pass down handlers through props: <my-el onClick={whatever}></my-el>, but that requires React's synthetic event system to know what your event name is (which it can't the way it's currently architected).

In Angular and Vue you can bind using the (event-name)="callback" or v-on:event-name="callback" syntax. LitHTML or LitElement use the @event-name="${callback}" syntax. There's currently no way to declaratively process non-native events using React/JSX and that's what I need.

[priolo]

The reason why webcomponents are not successful:
the majority of "web developers" are not programmers.
They do yoga, they are vegans, they copy-paste code, they are gurus

[Eka]

Great choice of topic and great discussion! I'm learning such a lot just reading the comments.

[Junk]

What problems do you think they're solving? And better solutions for what?

For scoping CSS? Shadow DOM is the ONLY solution that provides both bottom up and top down style encapsulation.

For extending HTML? React components only work in React components; not in HTML.

For application orchestration? Web Components don't and aren't trying to solve that.

[Leo Giovanetti]

Just wanted to show appreciation for the good conversation about the current state of things, above all, respectfulness as shown is the way to go.

BTW, in case it comes handy, there is an open standards initiative based on GitHub I started over at openstandards.guide