The good web standards are like jQuery to querySelector. They take something people were doing anyway and make it faster and builtin.
Web Components predate React and were a speculative API about what might be nice. It didn’t pan out and turned out to be the wrong solution. They hang on to life because a lot of people want them to be “framework free” and “standard” but they aren’t really framework free and it’s not a standard in a meaningful sense, so they don’t catch on. It just exists in this perpetual limbo of “thing internet people advocate for but isn’t very popular anyway.”
I think the way forward is to look at what people are doing now (VDOM reconciliation, reactive values, for two examples) and see how to make those faster and easier. Just clinging to customElement forever and waiting for it to be a thing is a dead end.
The biggest win I always wanted from Web Components was non global CSS. It’s admittedly a niche concern though for people who work on really large sites with a lot of dynamic HTML where the global nature of CSS becomes hard to manage. Web Components give us options that are superior in may ways to the solutions of most frameworks.
Whether or not Web Components were a good solution to “large-scale CSS”, people have had success with (1) using atomic styles to keep the stylesheet size bounded regardless of # of components and (2) completely remove the cascade, e.g. using component-scoped stylesheets.
Aside: I’m a huge fan of cascade layers which go a long way to making medium-scale CSS work well.
This scales up to a certain point but when your site serves literally billions of people a second with thousands upon thousands of individual features/experiments running at any given time it isn’t quite enough. This is admittedly a somewhat unique usecase but there was once hope that shadow dom could help.
I don’t think anything has been proven to handle that scale yet.
That said, what I described scales to hundreds of millions of daily-active-users, thousands of developers, and thousands of experiments, because it solves the biggest hindrances to scale (bounded stylesheet size and lexical-only reasoning).
I would appreciate shadow dom as encapsulation more if we had import maps equivalent. A good fetch map would solve a lot of the painpoint. This was offered but noone with the time and knowledge hold that flag so far.
I also would love better mixins to help this problem, but that also never found someone to wear that flag.
Maybe you were referring to it, but in case you didn’t know, Element.attachShadow() is supported pretty much everywhere and offers total CSS isolation. The API was developed for WebComponents, but you can call the function on any old Element.
Yes I’m aware of it :-) In another life I implemented Web Components in an internal framework. At the time we ultimately decided it didn’t hold it’s weight but the primary motivation was the CSS encapsulation of shadowDom.
Shadow DOM absolutely does not offer “total CSS isolation”. Fonts and CSS variables leak through the shadow barrier. It’s an example of a half baked API.
I think one of the biggest contributing factors was that to use web components before 2022/2023 meant having a build system. That deterred those of us in the no build/simple build camps from adopting web components. I may not have this entirely correct, but it was the perception (someone please correct me if I got it wrong).
Shadow DOM was also bad branding from the start. It sounds gimmicky and not like something serious developers trying to get things done need to learn. The name is also a misnomer. It attempts to be self-explanatory, but “shadow DOM” is an extremely poor explanation of what the shadow DOM actually is. This is probably only a very minor reason why web components aren’t widely used yet, but one I find bothersome.
Web components never strictly speaking required a build system. They just made certain parts of it easier. If you were wiling to you could just source a javascript file that would do everything you needed to do. But as with most modern web stuff the easy path was always use this framework which presupposes that you are using this build tool.
This is true, but all of the marketing was internally conflicted. “Use them because they are browser-native!” but also “It is dangerous to go alone! Take this build tool.”
I wish they would have made simple web components… simpler. A lot of people could find a use for creating their own elements which are essentially parameterised html templates. Without worrying about lifecycles or the shadow DOM or anything like that.
I started looking at web components, but a really simple example behaved differently than its equivalent without web components. There was a flash in the page where the web component javascript was catching up after the html loaded. This indicated to me that it was fundamentally flawed and could not be trusted.
Web Components aren’t really compatible with “progressive enhancement”. People are working on it, but they really want to run client side, so you get a pop in as they load after the JS kicks in.
Ignore interaction. How would browsers know what to do with the elements without JS? Are you just proposing that <my-element> is treated as a div? Does it have any ARIA roles? Is it templated somehow? If it is templated, what is the template language?
Bear in mind that browsers still support XLST, so you could just make a page out of XML with custom elements and style it with XLST if you wanted to. :-)
It’s an interesting idea. I think it’s probably too late for that to happen now, but it’s an interesting What-If to think about what if when HTML5 supplanted XHTML 2.0, they had started working on a lite version of XLST. :-)
Doesn’t want it to be a Google thing but wants to kill Firefox?
The good web standards are like jQuery to querySelector. They take something people were doing anyway and make it faster and builtin.
Web Components predate React and were a speculative API about what might be nice. It didn’t pan out and turned out to be the wrong solution. They hang on to life because a lot of people want them to be “framework free” and “standard” but they aren’t really framework free and it’s not a standard in a meaningful sense, so they don’t catch on. It just exists in this perpetual limbo of “thing internet people advocate for but isn’t very popular anyway.”
I think the way forward is to look at what people are doing now (VDOM reconciliation, reactive values, for two examples) and see how to make those faster and easier. Just clinging to customElement forever and waiting for it to be a thing is a dead end.
The biggest win I always wanted from Web Components was non global CSS. It’s admittedly a niche concern though for people who work on really large sites with a lot of dynamic HTML where the global nature of CSS becomes hard to manage. Web Components give us options that are superior in may ways to the solutions of most frameworks.
Whether or not Web Components were a good solution to “large-scale CSS”, people have had success with (1) using atomic styles to keep the stylesheet size bounded regardless of # of components and (2) completely remove the cascade, e.g. using component-scoped stylesheets.
Aside: I’m a huge fan of cascade layers which go a long way to making medium-scale CSS work well.
This scales up to a certain point but when your site serves literally billions of people a second with thousands upon thousands of individual features/experiments running at any given time it isn’t quite enough. This is admittedly a somewhat unique usecase but there was once hope that shadow dom could help.
I don’t think anything has been proven to handle that scale yet.
That said, what I described scales to hundreds of millions of daily-active-users, thousands of developers, and thousands of experiments, because it solves the biggest hindrances to scale (bounded stylesheet size and lexical-only reasoning).
I have hope for the scoped css proposal.
I would appreciate shadow dom as encapsulation more if we had import maps equivalent. A good fetch map would solve a lot of the painpoint. This was offered but noone with the time and knowledge hold that flag so far.
I also would love better mixins to help this problem, but that also never found someone to wear that flag.
Maybe you were referring to it, but in case you didn’t know,
Element.attachShadow()is supported pretty much everywhere and offers total CSS isolation. The API was developed for WebComponents, but you can call the function on any old Element.Yes I’m aware of it :-) In another life I implemented Web Components in an internal framework. At the time we ultimately decided it didn’t hold it’s weight but the primary motivation was the CSS encapsulation of shadowDom.
Shadow DOM absolutely does not offer “total CSS isolation”. Fonts and CSS variables leak through the shadow barrier. It’s an example of a half baked API.
Woops. Guess I haven’t used it enough.
I felt sort of crazy the first time I used it for real and then saw the host page font leaking into my node.
All the energy gone into web components and shoehorning them into html should’ve been put into an application layer around html.
React already solves the problem better and isn’t hobbled by string typing.
I think one of the biggest contributing factors was that to use web components before 2022/2023 meant having a build system. That deterred those of us in the no build/simple build camps from adopting web components. I may not have this entirely correct, but it was the perception (someone please correct me if I got it wrong).
Shadow DOM was also bad branding from the start. It sounds gimmicky and not like something serious developers trying to get things done need to learn. The name is also a misnomer. It attempts to be self-explanatory, but “shadow DOM” is an extremely poor explanation of what the shadow DOM actually is. This is probably only a very minor reason why web components aren’t widely used yet, but one I find bothersome.
Web components never strictly speaking required a build system. They just made certain parts of it easier. If you were wiling to you could just source a javascript file that would do everything you needed to do. But as with most modern web stuff the easy path was always use this framework which presupposes that you are using this build tool.
This is true, but all of the marketing was internally conflicted. “Use them because they are browser-native!” but also “It is dangerous to go alone! Take this build tool.”
That’s not unique to with components though. That’s the entire browser ecosystem. The culture is away with layer upon layer of tooling.
That sounds more accurate, thanks!
[Comment removed by author]
I wish they would have made simple web components… simpler. A lot of people could find a use for creating their own elements which are essentially parameterised html templates. Without worrying about lifecycles or the shadow DOM or anything like that.
I started looking at web components, but a really simple example behaved differently than its equivalent without web components. There was a flash in the page where the web component javascript was catching up after the html loaded. This indicated to me that it was fundamentally flawed and could not be trusted.
Web Components aren’t really compatible with “progressive enhancement”. People are working on it, but they really want to run client side, so you get a pop in as they load after the JS kicks in.
If you could declare, import and use your own elements in HTML (without JS being a requirement) it would be popular IMO.
How would browsers know what to do with the elements without JS?
‘without JS being a requirement’ does not imply ‘without JS’.
If a custom element is interactive on the client side use JS, if it isn’t no JS should be required.
Ignore interaction. How would browsers know what to do with the elements without JS? Are you just proposing that
<my-element>is treated as a div? Does it have any ARIA roles? Is it templated somehow? If it is templated, what is the template language?Bear in mind that browsers still support XLST, so you could just make a page out of XML with custom elements and style it with XLST if you wanted to. :-)
Yes something similar to XSLT, but as a first class citizen for HTML5, with a simpler syntax.
It’s an interesting idea. I think it’s probably too late for that to happen now, but it’s an interesting What-If to think about what if when HTML5 supplanted XHTML 2.0, they had started working on a lite version of XLST. :-)
Yeah, I agree that it is too late for that to happen :)