DEV Community 👩‍💻👨‍💻

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

Collapse
oenonono profile image
Junk • Edited on

They're used by Google, Apple, Microsoft, GitHub, Salesforce, ING Bank, Atlassian, and more. Giant software companies and banks? That's mainstream to me. In part. The other part is how popular.

They're not exactly popular. They may never be really popular in themselves due to the shift toward framework and away from platform level development. They may only become popular under the hood of or via wide compatibility with frameworks and libraries. They may actually already have this type of popularity, but it depends on what and how you're counting.

My opinion is that the community acceptance of web components has seemed to go worse than most successful standards. I think the above is part of why.

I also think there are other reasons. The evangelists got discouraged; when they first did the marketing push it was a bit too early and they had to deal with a lot of hostility about web components. For a while after that there were technical annoyances (like Custom Elements relied on native JS class support and Shadow DOM polyfills had challenging limitations) and as soon as someone senior got that far, they saw how much other standards were needed to realize the full potential (such as AOM, constructable stylesheets, participation). Worst of all, there has been a huge industry "pendulum swing" away from valuing web standards as people who have never experienced a world without a web or the browser wars began to outnumber those who had (also, of course, $$ monetization opportunities of walled gardens). I also can't ignore the massive impact of the fact that the most popular UI library is still uniquely incompatible with web components. Other frameworks and libraries are doing okay with compatibility and many are experimenting with the additional potential. But the most popular one is not, which has disproportionate impact on overall web component popularity.

But despite all that, Shadow DOM is now viable for CSS scoping for some use cases (design system libraries, ads, and some others).

Thread Thread
alekseiberezkin profile image
Aleksei Berezkin Author

Thanks for such an insightful comment essay 🙂 I completely agree that Web Components will benefit a lot from deep integration with frameworks. For the moment seems there's little to no interest from frameworks, like if they don't see any value of incorporating Web Components, i.e. they don't see how frameworks will benefit from that. Do they miss something? What are your thoughts?

Thread Thread
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 custom-elements-everywhere.com/
  • 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.
blog.logrocket.com/what-happened-t...

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.)