Use web components for what they’re good at

Recent and related:<p><i>If Web Components are so great, why am I not using them?</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36976670">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36976670</a> - Aug 2023 (181 comments)

I’ve actually done that “web components as the interoperability layer”!<p>It was this old angular 1.8 app with new features being written in angular-hybrid-ized angular 8. Ripping out angular-hybrid and separating the angular 1.8 routes from the modern angular routes was difficult, but now they were totally separate.<p>The only thing linking them together was an object with some RXJS streams in it for state, and a little in-house wrapper “app” which just loaded one component or the other with some attributes depending on the URL and a hash of routes for config. (I’d probably use SingleSPA [1] now. Same thing really.)<p>We could deploy them separately since the build just ends up being another JS file somewhere that just gets included with a script tag at runtime. No version bumping! No big mega build!<p>We started replacing the remaining “old” routes 1 by 1 with a “new” counter part. That was the easiest part, and went at a pace devs were comfortable with (fast enough) and business folk could tolerate. (modular enough to not HAVE to be done all at once)<p>Last I checked, the angular 1.8 stuff is gone years ago. :)<p>[1] <a href="https:&#x2F;&#x2F;single-spa.js.org&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;single-spa.js.org&#x2F;</a>

I’m aware of web components, but I’ve never seen them in person (as a dev). Honestly I assumed they were dead.<p>I never see them discussed or suggested to solve problems. I see libraries of components&#x2F;widgets offer versions for React and Vue and other things, never a web component version. No matter how good they may be they seem to have almost no mindshare.<p>All major browsers appear to have supported autonomous custom elements since ~2019.<p>That said based on this page this is a nonstarter at my company.<p>If it doesn’t work easily React, it’s dead. The fact you can’t pass objects or functions would be a huge pain. Of course you can’t pass objects to traditional HTML elements either (outside react) or functions (basically) so I’m not sure why I’m surprised at that. But being able to do that is what makes using React components so easy. Having to add listeners sounds like going back to the battle days of early jquery to me.<p>Additionally having poor accessibility support in 2023 is also a non-starter. We’re required to provide that in everything we do.<p>It’s not web components’ fault if React doesn’t fit their model, or browsers have poor accessibility support when web components are involved. But it’s still a blocker.<p>I can think of a at least one thing we do that being able to ship it as a web component would be very useful for. But we need to be able to pass objects in and out, which I guess would require marshaling and unmarshalling JSON. And that destroys ease of use.<p>Others have already mentioned the bundler problem.<p>Unfortunately the tone of this piece kind of reads as “come on, they’re not that bad, really“ instead of the cheerleading piece I was expecting. It had to mention a number of big caveats up front. I’m glad it did to provide an accurate picture. But unfortunately I think it actually reinforced to me the exact feeling they were trying to argue against.

I appreciate the author&#x27;s attempt to contextualize web components, but I have a few bones to pick, having seen web components used to a pathological extent in various projects<p>First, the idea that one of web components&#x27; strengths is bypassing serverside rendering is a bit misleading. SSR has been foundational to reducing time to first meaningful paint, ensuring accessibility, and improving seo. to argue that bypassing it is an advantage seems antithetical to best practices, even when using client-side tech like web components.<p>Second, the transition example from react to svelte highlights the use of web components as a bridge, but I fear it oversimplifies the reality of such transitions. Its true that web components might provide a superficial level of interoperability, underneath, the application architecture, state management, and data flow can differ vastly between frameworks. Simply plopping an old component with a new one doesn’t mean they’ll play nice without substantial architectural considerations.<p>Finally, the mention of &quot;no bundler, no transpiler&quot; as an advantage is curious. in practice, the modern web development ecosystem has moved towards using tools like bundlers and transpilers to optimize delivery, reduce overhead, and facilitate modular development. this isn&#x27;t about complexity, but rather about efficiency and best practices.<p>Web components certainly have their place and, used judiciously, can certainly add value. It&#x27;s just essential to approach them with a nuanced understanding and not as a silver bullet.

Well this is shocking<p>&gt; It might also surprise you to learn that, by some measures, React is used on roughly 8% of page loads, whereas web components are used on 20%.<p><a href="https:&#x2F;&#x2F;mastodon.social&#x2F;@westbrook&#x2F;110774427407999573" rel="nofollow noreferrer">https:&#x2F;&#x2F;mastodon.social&#x2F;@westbrook&#x2F;110774427407999573</a><p>I suppose it’s because you can probably use web components on top of frameworks.

I haven&#x27;t done any serious webdev since 2013. I thought Knockout.js was pretty slick at the time. I don&#x27;t know how react works. I don&#x27;t know how svelte works. This article is so basic to me that I makes me wonder wtf these frameworks are actually doing and why this article even came to exist.

There have always been interesting aspects to custom elements seamlessly integrated into the DOM of browsers, but let&#x27;s be honest, the current API is… shall we say somewhat unwieldy.<p>Little known fact: adding one line of code turns your Svelte component into a custom element (aka web component).<p><a href="https:&#x2F;&#x2F;svelte.dev&#x2F;docs&#x2F;custom-elements-api" rel="nofollow noreferrer">https:&#x2F;&#x2F;svelte.dev&#x2F;docs&#x2F;custom-elements-api</a>

Web components can be used without a front-end JS framework (Vue, React, etc.) which I think is one of its best features. There is a mild complexity to it since it encompasses the javascript and HTML including creating the HTML element type (or whatever it&#x27;s called).<p>&gt; This is about as close as you can get to the original vision for web components, which is that using &lt;fancy-element&gt; should be as easy as using built-in HTML elements.

My preference in web dev is to lean into standards. Web components give us a way to structure and re-use dynamic (client side) rendering and event handling.<p>However two things are bad about them:<p>1. They break the otherwise consistent dynamism of JS. You can’t re-register custom elements. This is incredibly disappointing.<p>2. The shadow dom is a separate concept lumped together with the rest, which is painful. A typical case of people anticipating specific usage instead of making a modular, simple design.

&gt; Now, some people get squeamish at the idea of two frameworks living on the same page<p>Yes, yes. Years of trying to cut off the long tail of a migration will make you a bit squeamish.

Just as a side info, the profile card in Microsoft Teams does use Web Components.