DEV Community 👩‍💻👨‍💻

Discussion on: Why I left CSS-in-JS and returned to good old CSS preprocessors

oenonono profile image
Junk • Edited on

Sure: that's not true enough. I mentioned this aspect near the end. There are only two frameworks whose maintainers have made official anti-web-component statements, as I recall. There is only one framework that is intransigent about supporting web components.

  • Check out
  • Angular 2.x did its own sorta-polyfill of a pseudo Shadow DOM and initially did take some intentional inspiration from web components. Then got super into Typescript and functional reactive. But under the hood, modern Angular's ViewEncapsulation is driven by either that psuedo-Shadow-DOM implementation or by native Shadow DOM, depending on settings.
  • Polymer, Lit, and Stencil are based on web components. All of them are fascinating projects in different ways, IMO.
  • Despite the infamous blog post, Svelte has made the effort to be a pretty good tool for authoring web components, although it doesn't use them by default for components. Still, parts of its API are based on them. (What the post doesn't sufficiently acknowledge is that some of the issues are only issues if you are insistent on having a JS-first-and-focused DX. That's factually not how the web works. Chasing that DX is a major reason for startup performance issues in most existing frameworks and for their issues with accessibility and SEO. The industry didn't wait for those problems to be solved before jumping onto the framework bandwagon; it took years to solve them to some extent and they're still issues today. Confirmation bias is a hell of a drug. Web components aren't unique in some of their JS-design-caused issues, they have some of those issues because of they're not entirely HTML. They still embrace HTML more than many other solutions. You're creating an HTML-or-DOM interface, just like standard HTML has. IMO, the pragmatic and reasonable choice by the standards to focus on the JS interfaces has nevertheless hurt their potential in this respect.)
  • Most pre-existing frameworks will probably need to await features that (last I checked) are called "declarative Shadow DOM" and "constructable stylesheets" for it to be sufficiently desirable to disrupt their design to production-ize a web component foundation. You see that more in new tools than old ones with a lot of prior investment. There are experiments being done and discussed between open source maintainers and standards people about web components. I don't know exactly how or how much, because not everything in standards or open source is actually entirely out in public, sadly. But I've at least seen some productive threads on Twitter and GitHub with those kinds of conversations and participants, for example. That's interest. But also, most of them (especially the major ones) allow you to create and integrate web components already. They didn't make that effort for no reason. They did it because they acknowledge the value of producing and integrating web components. That is interest by definition, clearly expressed by hours of work.
  • Application frameworks for UIs ain't shit without UI libraries. And UI libraries based on web components are already prolific and on the rise. Those are a perfect example of the web component value proposition and is something the current state of the standards supports well enough (though those additional standards, "named parts", and "form participation" will still improve it). The adoption reflects that.

This is a pretty good article that while less optimistic than me I still think is pretty accurate and unbiased.

The main things I recommend web components for reflect current status and adoption. I recommend publishing web components via a framework/library for some use cases. Those components can be used with multiple frameworks with less painful lifecycle synchronization. The use cases where that becomes high value include UI libraries, widely shared but strongly encapsulated components (like customer service support chats), and microfrontend components that don't need SEO. (It's possible to have good SEO with web components, but it's an art and has limitations on nesting levels for now.)