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.

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.

We're not opposed to supporting web components better. The problem is that there's no single "web component community". There are multiple subcommunities. You mention "web component libraries" in the post. These libraries don't agree on a single standard so React would need to pick a side in debates like "how does server rendering work with web components". Whatever we pick will have large downstream effects, and our reluctance to support more has to do with being careful (see [1] note below) about the semantics — not somehow being at odds with web components per se.

As I mentioned in the previous point (and you mentioned in the post), there are multiple "web component libraries". As far as I can see many of the criticisms of React would apply to such libraries as well. I don't think the way to counteract "DOM FUD" is to introduce "library FUD". If you're using a library for defining and updating your web components declaratively, you're not following a conceptually different approach from using React.

Saying "you can do everything with WCs that you can do in React" is double edged. Yes, of course, you can do anything — because we haven't actually agreed upon any constraints. If the constraint is "you don't use a React-like library on top" I think you'll find there's plenty of things that are very hard to do with an imperative abstraction like vanilla WC APIs. We've done a few talks about what using React as a unifying abstraction lets us do (such as non-blocking rendering, or dynamically loading UI code without degrading user experience). You might want to check them out (youtube.com/watch?v=nLF0n9SACd4, youtube.com/watch?v=ByBPyMBTzM0). Of course, you can do these things if you use a library like React on top of WCs. But that negates the argument that you don't need React-like libraries for this.

To sum up: we'd be happy to support WCs better in React. We don't want to rush it, and want to make sure this support is well thought-out. Additionally, we believe there are many things that raw imperative WC APIs don't give you — and for them something like React would be appropriate even in a WC world. Finally, there's this myth going around that once you write React code, you can't reuse it as web components. That's not true — and as you can see from the documentation it's a few lines of code: reactjs.org/docs/web-components.ht...

Hope that makes sense, and provides some additional context!

[1]: For example, if I'm not mistaken, the semantics chosen by Preact make introducing a new standard property to DOM base element potentially a breaking change for the web. We try to avoid such problems if possible — precisely because React did learn from MooTools and we don't want to do another mistake like what happened with Array.prototype.flatten().

I just need custom event support in JSX. There's not a lot else that's too difficult to do when just considering web development. Using refs and componentDidMount is cumbersome, adding native event handling would make a huge difference in how easy it is to work with React and web components.

Totes. It's pretty frustrating trying to compare the advocacy efforts in the wc community with what your team is blessed with. Then again, there's no "querySelector" community either. Open standards might not be sexy but they make the world go round

These libraries don't agree on a single standard

They agree on at least two: the HTML spec and the DOM spec. Those are the standards we're working with. I appreciate the React team's need to consider platforms beyond the web, and I'm grateful that's not my concern at the moment as a web developer, since that sounds like a hard problem. But server-side rendering is beyond the scope of the question "what should be the web's component model" in my humble opinion.

If you're using a library for defining and updating your web components declaratively, you're not following a conceptually different approach from using React.

As far as I've seen (and this is as a developer/user, not as a library author or community manager) the difference is about how to apply the concept of components. Should we use a bespoke all-js solution, or agree on standards for things like component model? Then, it's about how much code we're adding on to the web APIs. Justin Fagnani had an interesting hot take on this in the Polymer Community Slack

[A] meta-comment on the concept of "vanilla web components": [It's] a confusing term. Some people think "vanilla" means it has no dependencies. I think that's a silly constraint. I tend to think of vanilla as meaning that there aren't framework-style custom APIs intervening in writing or using a component. ie, LitElement is vanilla because it extends HTMLElement and you override the standard lifecycle methods like connectedCallback as necessary. StencilJS isn't vanilla because the component class doesn't extend HTMLElement and you don't implement standard lifecycle callbacks, you implement compnentDidMount and such.

Actually in the same thread, that same Justin sort of preempted your next point:

there's plenty of things that are very hard to do with an imperative abstraction like vanilla WC APIs

To loosely paraphrase - Now that we have the DOM API, we don't need jQuery, but we still sometimes need libraries like jQuery. The low-level WC APIs are best used by library authors. There might be some simple cases (like a <lazy-image> element) that are best implemented and shipped with bare-bones browser APIs, but in most or almost-all cases, it would be better to use a library.

we'd be happy to support WCs better in React.

Amazing

We don't want to rush it, and want to make sure this support is well thought-out.

Sure!

Additionally, we believe there are many things that raw imperative WC APIs don't give you — and for them something like React would be appropriate even in a WC world.

Totes. I'm not sure that's even a debate. For me, that "something like React" is the option which lets me hit save then reload without any intervening tools.

I Hope the interop promise of web components lands in the massive react community soon. In the mean time I'll be declaratively defining reactive templates in LitElements et. al., and running them without babel, webpack, or any other tooling (unless I decide to bring them in as nice-to-have optimizations)

Thanks again for stopping by, it's great that you decide to add your voice to this discussion. 😊

It's pretty frustrating trying to compare the advocacy efforts in the wc community with what your team is blessed with.

Not quite sure what you meant by this, but I'd like to emphasize we don't currently have developer advocates working on React web. People you might talk to on Twitter are just JS engineers who happen to work on it and like open source.

But server-side rendering is beyond the scope of the question "what should be the web's component model" in my humble opinion.

Maybe. It's in the scope of "how to write a performant application" though, which is why a lot of people care about it. Since it's in the scope of what React does (and perhaps holistic thinking like this is part of the reason people don't hurry to ditch React), we need to consider any decisions there very carefully — especially because they impact the web component communities too.

The same goes for all other things we consider our concerns (such as dynamic loading of UI code). They might not be low-level enough to be in the spec, but we think it's much easier to write product code when the component abstraction is aware of them. Which is why we think it's worthwhile to keep working on React.

Overall it doesn't seem like we disagree on many things? I wish these discussions were less polarized in general, as they keep being about how we need to ditch one and use the other whereas the tools are more complementary in nature. My personal impression has been that web components solve organizational problems more often than technology problems (e.g. how to share UI between teams that don't want to agree on a library). But those absolutely are valid problems, and it's great if we can have solutions to both spectrums.

we need to consider any decisions there very carefully — especially because they impact the web component communities too.

My spidey-sense is tingling. The React team isn't the w3c or the whatwg. Big questions that affect the future of the web should be the purview of standards bodies, not library authors. I'm not against awesome JS that makes things work in lieu of agreed-upon standards, (and let me take a moment to praise your team for their technical accomplishments) but we have a standard component model now - one that's not just theoretically standardized but also universally implemented (!RemindMe 6 months or so when Edge releases support).

It happens to be that I prefer not to use React because of VDOM and JSX, which for my use cases are in my (very) humble opinion overengineered. I like hitting save and reloading. I like inspecting a custom element and seeing its DOM properties in the JS console instead of some custom dev tools plugin. I like working without source maps (and if I had my druthers lit-html would be written in JS not TS 😉). I like standards and I like the web. I don't like it when people think that "web developer" has to mean "react developer"

My main issues are that React's success has made babel and webpack de rigueur requirements (I just spent an hour with a mentee unscrewing babel for a one-file 700 LOC react js script for a wordpress site. Madness!), and that a lot of the advocacy for react has come as mud slinging against standards (and I hope it's clear that I'm not pointing the finger at you personally))

My spidey-sense is tingling. The React team isn't the w3c or the whatwg. Big questions that affect the future of the web should be the purview of standards bodies, not library authors. I'm not against awesome JS that makes things work in lieu of agreed-upon standards, (and let me take a moment to praise your team for their technical accomplishments) but we have a standard component model now - one that's not just theoretically standardized but also universally implemented

This is precisely my point. I think you're both asking that we do implement a tighter WC integration, and also that we don't make any decisions about how it should interop with React (and thus impact questions like server rendering). These are mutually exclusive requirements. And they're the reason we haven't historically been hurrying with this despite efforts like custom-elements-everywhere.com/.

React's success has made babel and webpack de rigueur requirements (I just spent an hour with a mentee unscrewing babel for a one-file 700 LOC react js script for a wordpress site. Madness!)

Re: Babel, fair, although you could use it as a JSX-only transform if you don't care about newer JS features. React doesn't force you to use ES6. I found it curious that people who complain a lot about JSX tend to also love SASS — which, if you think about it — is a transform just like JSX.

Re: webpack, this has nothing to do with React. People use it because they write more complex apps, and shipping them as a single bundle without code splitting (or as ES6 modules!) hurts the users. If you don't need bundling, you can use React as a script tag and not do any bundling: reactjs.org/docs/add-react-to-a-we...

a lot of the advocacy for react has come as mud slinging against standards

Let me know when you see it and I'd be happy to chime in! I've also seen a lot of unjustified stabs back at React which doesn't help either.

Can't believe im about to be 'that guy' on an internet forum saying this, but im running out of fingers to count the times I've shook my head after seeing a "use the platform LOL" jab from the React community.

Having said that, I really do appreciate the sentiment of your comments in this thread, and you taking the time to engage in (what feels like an actual fruitful) discussion!

Overall it doesn't seem like we disagree on many things?

I wish these discussions were less polarized in general.

So now that we've established this, perhaps we can all slow down with the mud throwing a bit?

im running out of fingers to count the times I've shook my head after seeing a "use the platform LOL" jab from the React community.

Sure and I'd like to see this fade away. But I think we also both know exactly where this sentiment comes from: the feeling of alienation. Some developer advocates shame developers for large bundles — and in many ways, this is justified. But often there's a sense that they forget why we ended up here.

React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a <carousel> they get an <aside>. Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).

Now again, I understand the other side to all of this. Standards are hard etc. But I think the aggressive anti-library message (while promoting a library on top of WCs) coupled with not listening to people's problems has somewhat poisoned the "use the platform" movement. That's why many people perceive it as sarcastic now, unfortunate as it is.

I'd like to see that change though! On the React team, recently we have been tightly working with browser vendors. There is a sense that people are more receptive to hearing things we learned, and we're very optimistic about this progress.

I think you'll find there's plenty of things that are very hard to do with an imperative abstraction like vanilla WC APIs.

Would you mind expanding on what you mean by this? I'm on board with a lot of your comment. In general, while I prefer web-standards-based work to framework-based work, I have a hard time as seeing web components as "there yet." I agree with you that the fragmentation in the "web components" community harms it way more than React does, and that trying to frame web components as a replacement for React is likely to lead to using web components poorly. (For example, I see a lot of folks trying to use web components for page templating in a "React-like" way; I think this is a mistake.)

HOWEVER. "Imperative abstraction," in the context you're using it and without further explanation, seems like functional-purist FUD. One of my concerns with the emerging "functional React" default is the way it encourages folks to give their entire page over to a global state, rather than having components maintain their own boundaries. In my experience, separating out "API data state," component-level state, and route-based state really simplifies and clarifies SPAs. I suspect you have a different perspective here, which is fine. But I don't think that that different perspective justifies spreading FUD over "imperative" (object-oriented) code.

I'm not saying this as a gotcha. I think that integrating the actor style that (good) DOM-oriented approaches use with React's emerging functional consensus has always been a hard problem, and that the additional complexity of the WC APIs makes it even harder. I think that dismissing valid stylistic and philosophical differences as "weaknesses of imperative code" will make it very difficult to get a useful seam between WCs and React components which drive them! So when you use language that I read as reflecting functional-purist assumptions, I find that really disheartening.

Maybe I'm over-reading this. I hope I am! Regardless, it's not at all clear to me what the "things" that you think are "hard to do" with "imperative abstractions" are, and I think that you unpacking that could really help illuminate some of the overlapping concerns that add unnecessary tension to WC discussions.

"Imperative abstraction," in the context you're using it and without further explanation, seems like functional-purist FUD.

I'm not sure we're on the same page here. React has always been on the pragmatic side of FP — full of imperative escape hatches. We're definitely not purists. Some people in the community are, but they're a minority and don't reflect how React is being used by most folks in practice.

One of my concerns with the emerging "functional React" default is the way it encourages folks to give their entire page over to a global state, rather than having components maintain their own boundaries.

This sounds like a misconception about React to me. React doesn't have a concept of global state, and emphasizes component local state very strongly. That's all you'll find in our documentation, for example: reactjs.org/docs/state-and-lifecyc.... We strongly encourage to keep component state isolated, and to pull it down to the place where it's actually needed instead of hoisting it all on the top:

There should be a single “source of truth” for any data that changes in a React application. Usually, the state is first added to the component that needs it for rendering. Then, if other components also need it, you can lift it up to their closest common ancestor.

(This is a quote from the React docs.)

In my experience, separating out "API data state," component-level state, and route-based state really simplifies and clarifies SPAs. I suspect you have a different perspective here, which is fine. But I don't think that that different perspective justifies spreading FUD over "imperative" (object-oriented) code.

No, we're fully in agreement here. Again, I think you might be confusing React with something else. (Or perhaps, with some highly opinionated way of writing React.)

I don't consider local state "imperative" in that sense. I was only reflecting on the imperative nature of DOM API (node.property = value), as opposed to a declarative one (return { property: value }) — although even that is allowed in React for some use cases like focus or media playback.

I also realize the words "imperative" and "declarative" have subtle meanings, so to clarify, I'm only talking about the difference of mutating views vs describing what should be rendered.

We consider local state to be the most important feature of React. We are considering moving to a slightly more functional way to express it (conference talk if you're curious: youtube.com/watch?v=dpw9EHDh2bM) but it's still entirely local and has all the necessary imperative escape hatches. (Ironically most of the criticism of our proposal focuses on it being not "pure".)

It's not at all clear to me what the "things" that you think are "hard to do" with "imperative abstractions" are

I think they capture those exact things so if you're curious, please take a look and let me know what you think. In short: I'm talking about non-blocking rendering ("time slicing") and declarative loading states ("suspense") without committing results to the DOM until they're ready. This is something you can't do if node.property = value is your only primitive. But you can do it if your abstraction lets you describe changes without immediately applying them. (Display locking DOM proposal is a step in the right direction.)

Hope this makes some sense. Really sorry you got the impression we're purists from my post. Not my intention at all! In fact purists usually scoff at React for being too "impure".

Dan, of course React still has value with Web Components. It has value in numerous ways, in particular orchestrating the rendering of application state into a view.

That's orthogonal to Web Components. You could do it, but it's not the best tool for the job. Just like React isn't the best tool for what Web Components are for: extending HTML.

Have you still not gotten comfortable with the nuance that there's a difference between an application framework and a library of GUI components?

Or that you can very easily produce Web Components with a declarative interface?

Or that it's a low level API, like the DOM, and that's intentional so that the web community can ideate how to author Web Components declaratively (different from using them declaratively)?

Or that there are negative ramifications to putting the entirety of the view layer behind the semantics of JavaScript instead of embracing the declarative languages of HTML and CSS?

Stop staring into your bellybutton and talk to some of the web designers your community has alienated over the past 6 years. The web is for more than software engineers. Software engineers are not more important than the rest of audience, even if it's understandable that, as a fellow software engineer, you see things the same way.

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. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.

As mentioned in my post, we'd like to further improve this integration, but we'd need to be careful and get the semantics right.

Re: your point about software engineers, I'd like to hear from you about how React alienates designers and how we could improve this — perhaps you could raise an issue to spell out your concerns? We're excited about products like FramerX, and React docs include links to designer-friendly resources (reactjs.org/docs/getting-started.h...).

I know we're not doing enough for designers, and would love to do more there. Not sure how this is relevant to the WC conversation but maybe you can help me understand. But I don't believe I've heard from you before you told me to "stop staring into my belly button". That's not a very productive way to start a conversation. Is that how you talk to people in real life too? Maybe we can try again?

I am so confused; I have such trouble relating with people sometimes. I've re-read what I said a dozen times, and I can't see the problem. Though if I weren't posting anonymously the self-doubt and resulting guilt would be sufficient to shut me up for at least six months. That's why I have this account: destructive anxiety. (Though, also, yes, that's how I talk to people in real life. And yet most people, including my coworkers, like me; I can only assume because a different and authentic tone is heard than has been apparently read here.)

Sure, I could pretend that I was born just this moment and so I approach all of this with neutral, fresh-faced, joyful innocence. But that's bullshit. Instead I have a dozen years of history of seeing libraries and frameworks come and go. And four years of hearing things like what Dan said repeated uncritically by the React core team and people who appear to take their word on it like they have some biases being confirmed by it all.

Nothing I've ever said about it has made even the slightest dent in that, no matter how I said it. That's why it's ironic to have my input invited on how to fix that dialogue. I only "patronized" by assuming Dan has a subjective point of view. Which is true for literally everyone. Let's look at a contrast. Dan leveled an accusation of FUD (which means deliberate evoking of fear, uncertainty, and doubt for the purposes of propaganda) and no one chided him. I leveled an accusation of naval-gazing--and how dare I! Nothing I say has any value whatsoever!

Huh? Naval-gazing is like bike shedding; it's just a common trap for people in our industry. Is all of this because I started the comment with, "Dan, of course"? That means I agree so completely with the following statement that I don't think it's even a question! Not that I think he's stupid.

I really, really don't want to be a jerk, but at the same time... If that's all it takes, I cannot understand your perspective, since hardly a week passes when someone doesn't tell me I'm categorically unfit to be in the industry and should leave it to the real engineers. When's the last time someone told you that they hope you lose your livelihood because you don't want web client implementations to exclude a wider audience by requiring a lot of specialized programming knowledge and time spared to keeping up with the pace of the JS ecosystem? I'm not saying that excuses treating anyone else like crap, but...I can't see that I am...?

Now to what I think merits objection.

"Web components are imperative." Not to users. Not to product managers, not to designers, not to blog authors, and not to application developers consuming them. React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?

Well, because React is very focused on developer experience. Is the developer experience great? Unsurprisingly, that's subjective, but I think it's accurate to say, "React's developer experience has a great deal to recommend it to a significant audience." But it's an issue if the only votes that are counted to justify that assessment come from a privileged subset of people who work on web client development.

In response to my brief comment about that, Dan pointed at auxiliary tools that double down on framework lock-in. To me, that misses the point. We already have a standardized declarative language to create elements and set properties in the DOM. It's called HTML. Putting up a website with a specification doesn't make something a standard the way I mean a standard, by the way. The majority of web client standards represent an an agreement made between multiple competing interests and vetted by performance and accessibility specialists. "I did a thing with my own interests in mind without giving any competitors an opportunity to make significant changes or veto," isn't even remotely close.

Why do non-engineers need a separate tool that's in its infancy? In part, because you excluded them from the ground up. The only way to fix it is to create something else with them in mind. It'd still be worthwhile to build FramerX, because we really haven't seen great holistic web design and web client development tools thus far. So there are numerous things I think are great about FramerX, but bolt-on inclusion is not one of them.

There is more, but after getting this far... I fear to put any energy into writing it if I'm so blinded by my own small world that I might be doing nothing except giving readers a bad impression of people who care about the same things I do.

Hey, I'm sorry if my reply frustrated you. I'll try to clarify a few things. I don't mean to create any FUD. I think my position is very concrete. (And it's definitely not something about "real engineers" — I'd like React to be welcome to everybody.)

React uses imperative and object oriented DOM under the hood; does that make it imperative? If it is, that's not why. So why does this keep getting repeated without even a dependent clause nodding to any of that nuance?

Of course under the hood it's all imperative. The question is only about how you write the majority of your application code and how components are expressed. I already linked to this talk in my first comment but I'd be happy to link again: reactjs.org/blog/2018/03/01/sneak-...

In this talk I show a few things that I believe are very valuable from both developer and end user perspective. Features like these are not possible if your "glue code" between components is imperative. If you watch the talk I think you'll realize what I'm talking about. I'm sorry that I don't have a shorter and more condensed version of my argument than a conference talk. But I hope that if you find the time to watch it, you'll see that I'm talking about specific things and not vague FUD about imperative/declarative.

If React is not solving your problems that's cool too. No need to assume ill intent.

Your first post would have definitely been an odd opener in person. It's like talking shit before shaking hands. Not going to go over well.

A non negligible percentage of standards become standards after a company builds something and demonstrates it's worth, at which point standards bodies go through the process you described. See SPDY / QUIC. Its much easier to define and iterate on something after someone else has demonstrated success.

It's a weird situation. As Benny mentions it's a false dichotomy. Sort of. I can write Web Components or React Components, and Web Components can be used in React apps/components, but I still need React or something to "orchestrate" the app, namely data flow and app logic. Using a Web Component base element like LitElement is basically choosing a framework that makes components built with them as reusable outside of that framework as React components. This makes me think we may even see more incompatibility between components as Web Components ecosystem develops.

So when I ask, Should I start building Web Components? I don't even have a good answer for myself. Clearly I'm interested in them, but pragmatically there isn't a big enough general draw to invest in them. Plus I'm doing stuff with WASM and a lot of this gets thrown out the window.

A different question is, Should I use Web Components that have been made? Yes, if they're good enough. There doesn't seem to be a ton there yet though.

litelement components are reusable outside your app, if you write them to be. If you write them dependent on your app, they will be, but they don't have to be. The point is that you can write reusables and have them run anywhere, which you can't do with frameworks.

also, the notion that 'wcs need some framework to orchestrate them' is also applicable to react, since it's just a view layer as well.

That sounds more likely. But is it because it's so difficult? Or because using a declarative library lets component authors come up with more natural and expressive APIs instead of catering to the imperative lowest common denominator? I think it's the latter.

So maybe this means the holy grail of "code reuse between libraries" is not actually so desirable by developers? See my last two sentences. :-)

People like writing expressive code. There's a lot of expressiveness you have to give up in the component API if you're writing it for all consumers — precisely because you can't assume a declarative abstraction on top.

All you need is a dom node, the javascript boilerplate is about two lines, mount and unmount, which you can abstract if you like. If you know your way around your toolchain (webpack) you can shrink the overhead down to less than what a web components polyfill would cost you.

No you don't need a toolchain. That's the whole point. You shouldn't need one. You may add one as an optimization (which is what Google is suggesting there) and I do as well in some of my apps. But you shouldn't need one. You should be able to serve files that you edited yourself directly and they should just work in the browser. That's the web I grew up with and that's the web I want to show to my kids in a few years time.

I wonder how do you feel about writing inside <script> and <style> tags in HTML. In which ways <script> alert("hi") </script> differs from template.innerHTML = "<div> hi </div>"? (Provided that there's tooling support and that the browser knows it has to parse the latter string as HTML not JavaScript.)

is nothing more than a single function call with, you guessed it, a string

html('string',...)

No amount of word twisting and wishful thinking can change that. I really advise you to look at what lit-html does such as diligently parsing this string looking for tags and markers: github.com/Polymer/lit-html/blob/m...

And no. the browser does not know how to "parse this string as HTML". Because it's just a string, it's handled as a string, and is used a string, and nothing else.

If I build a component framework in another language via WASM, I can't see a way to make those components play well in a Web Component ecosystem. That was the extent of the meaning behind my WASM statement.

Note that iOS, Android, and other UI platforms are accessible without using HTML. While I'm not pushing for leaving the DOM, there is nothing in particular that ties accessibility to it — it's a matter of which low-level APIs are exposed and available.

I think that his comment is just too harsh on React. Yes, it is the most popular library to code web stuff right now, but we all know where was Angular a few years ago, and Meteor and Ember before it. Libs/Frameworks come and go, and that usually happens with the web itself evolving and making easier to create stuff without framework overhead. In my opinion, React will embrace Web Components as soon as we start to see professional and big web applications created with WC because they have a similar ideology. There are a few problems remaining to be solved as WC are using custom HTML tags and as @benny
mentioned a different approach to handling browser events.

After reading his comment, a reader might get the opinion that React is slowly dying, but React will not go anywhere anytime soon (MS is rewriting Skype in React, and XBOX will use React Native, among other stuff happening in React world) :) I've taken a look at WC and they are still not ready for production, but it's a very good thing to know nevertheless, who knows when you might need it :)

There are plenty of big sites out there using wcs. ING, wego, ea, others. Every McDonald's menu runs Polymer. People cite the youtube thing, but youtube is using the v0 specs with polyfills (soon chrome will also require polyfills for those old deprecated specs), so when people point to yt and say it doesn't work, it's a straw man (see my original comments)

Your take is fair and restrained, btw. My own feelings at this point are that it's impossible to be too harsh about React. React's smug, myopic fanbase made me seriously consider quitting web development for the first time in my decade+ long career.

But that's not all React users, all React fans, or all React's core team. It's just the zeitgeist and a particularly loud, obnoxious, and ignorant segment of the fanbase. So I try to take deep breaths and avoid getting involved in fruitless debate.

I'm tempted to return that dollar you just loaned me. But I'll be charitable. Despite this being the stock response of React core team members, you all probably don't mean to pass the buck of the responsibility that comes with your power along to me, a person without your power and the experience (of what's feasible) that comes with it. I genuinely believe you mean it literally and kindly. It's understandable. We put things out into the world and really lose control over what other people make of them. You are an engineer, not a sociologist or a public relations professional. If I were you, I wouldn't know what to do, either. Which is to say: it sucks, I don't know what to do, and I don't blame you for not knowing either. So I'll definitely let you know if I do have any ideas.

Have you considered psychotherapy to help with your anger and frustration, which is likely due to increasing feelings of irrelevance with regards to your skillset, rather than anything to do with the actual tech?

How come I don't see more articles about WC then? Where is WC community? Does it have some sort of ecosystem of packages and utilities?
For now, it seems just like some niche tech like Haskell, Dart, Elm, and Clojure, everyone is talking about them and admire them but I haven't seen a single practical use in production applications except for a few exceptions. Companies and corps are usually going after something that is battle tested, and once WC are battle tested with a bunch of really good examples, I'm sure we will use a new framework based on WC as usual.

That's what I came up with just off my fingertips. But also, when was the last time you attended a querySelectorConf?

so I'd like to suggest that the reason you don't see more is because you're not looking hard enough ;)

To be fair, my oft-repeated complaint in the Polymer Community Slack is that not enough resources are being directed to advocacy and community building. Lately I've been hearing subterranean rumblings that the situation on that front might improve.

It's probably the first time in the history of web standards that the new "use the platform" and the new "use the APIs" are rarely if ever mentioned in any of the resources dedicated to them.

People keep mentioning jQuery. However, as the platform develops, there's less and less need for jQuery (querySelector, fetch, etc.). The platform developed to include WebComponents, and they somehow don't reduce the need for libraries. Instead, they all but require libraries to be even remotely usable.

And that is specifically because of a new trend in web standards about which I have mixed feelings.

Specifically, more low level APIs intended to be consumed less by web client developers directly and more by web tool/framework developers.

The idea is that web standards will be able to move faster and satisfy real (vs imagined) needs better if there is more dialogue with "userland" solutions. I get the impression they don't want to spend a lot of time on API usability only to find there are major problems with or no value in the essential features. (For example, almost a decade was arguably wasted on XML as a way to extend HTML, while multiple frameworks found their own ways to do it and thereby also uncovered a dozen OTHER needs in the platform.)

So there's definitely SOME inaccuracy to the framing of using the platform being about not using libraries at all. But honestly I think this argument usually involves people talking past each other, not with each other.

I read, Google switched many of its websites to the new Polymer framework, and they became unusable with Firefox on MacOS. I'm going to use the platform when it's finally usable until then it's React for me.

Also, React plays a much bigger game than being just a front-end framework for the web. While the web is still the most significant chunk of that game, there are many more platforms the React team has in mind when planning.

I don't know what the future brings. Some people say hooks are one step on the way to make React web components ready in the future, and the React-Native team works on opening their platform for other frameworks, like NativeScript did. Maybe React-Native will stay in the game, but with something different on top, who knows.

"Intent to ship" means "not currently supported." I've been hearing about how web components are right around the corner for the entire time I've been paid to write React code.

I don't disagree with the premise; web components are likely to be a superior implementation for the "leaves" of an application. Buttons, dropdowns, checkboxes, etc, would be much easier to use if we could do <custom-checkbox onChange={handleChange} /> within React.

The YouTube performance/stability problems that I saw demonstrate to me that they're not truly usable yet, though, and I have concerns that they'll be outdated and difficult to use by the time they're supported across all modern browsers. The can I use page for them says to me that it's still a long way off.

As an employee I'm very familiar with front-end libraries and frameworks and I use them everyday (because I have to and that's how I get paid, I work on a team after all). As a developer I have an increasing disdain for these front end shiny things. I like learning how things work and how to make things. I have no idea why everyone is so obsessed with "there's a library that does that for you!". Am I the only person that actually enjoys making fast, responsive custom UI's from scratch? Am I the only person who wants to figure out what a library is doing so I can code it myself? I got into web/app development because it is enjoyable to make this stuff. Not because I wanted to get great at installing libraries that do everything for me...

Also, most large front-end frameworks are amazing. The people behind them are geniuses and the work they do is incredible. But I've personally seen, that even at an enterprise level, these frameworks simply are overkill. Most web apps being built with them could have been made with virtually nothing front-end wise but html, css and javascript. These frameworks are so robust I would compare them to a sports car/monster truck/space rocket. If you need launch off to a new planet and drive around on the surface, bingo! But if you need to get milk from a grocery store, just hop on your moped...

Business requirements ≠ the trendiest/ most hyped up tech being thrown around...

Having said all that. I move away from React/Angular/Vue and write vanilla web components every chance I get! I love'm and they are the future.

Yeah React has been great for me and has served me well in multiple different projects. But if you're telling me there's a standard spec that works cross-browser, I'll 100% go with the standard instead of a library.

It should be no surprise that React will not outlive our careers. WebComponents are simply providing the ability to create composite elements AFAIK. I tried it back in 2012 and it was too soon to switch to it. I amost subscribed to polymer and thankfully it wasn’t ready for prime time.

People are still using jQuery even though browsers support those features natively. Yes, even jQuery will succumb to the advent of the web. It is our job to stay up to date. When the time comes, React developers will adapt. The library is still evolving as it is. Facebook developers will think this through.

Watching Polymer progress has given me mixed feelings about the nature of web components. I don't know if the current implementation of web components is a good solution to the problem they are trying to fix. React and other component libraries are proving to be better solutions at the time being.

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.