I'm a big web components guy, but calling these web components is a massive stretch of the word component.
The word "component" has to mean something ultimately, and to me the defining feature of a web component is that it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS, etc. Web components shouldn't require an external framework or external CSS (except for customization by the user) - those things should be implementation details depended on directly by the component.
This here is just CSS using tag names for selectors. The element is doing nothing on its own.
That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. Too many HTML elements can slow the page to a crawl.
Use classes:
<a class="button" href="">Learn more</a>
They're meant for this, lighter weight, and highly optimized.
Almost 15,000 elements! I do agree that too many elements can slow a page but from my experience that starts to happen a few hundred thousand elements, at least that's what we'd run into making data visualizations for network topologies (often millions of nodes + edges) but the trick for that was to just render in canvas.
This is a wonderful example how people live in the inverse-world.
Marketing is in the end a way of trying to get people to listen, even if you have nothing substantial to say (or if you have something to say, potentially multiply the effect of that message). That means you have to invent a lot of packaging and fluff surrounding the thing you want to sell to change peoples impression independent of the actual substance they will encounter.
This to me is entirely backwards. If you want people to listen focus on your content, then make sure it is presented in a way that serves that content. And if we are talking about text, that is really, really small in terms of data and people will be happy if they can access it quickly and without 10 popups in their face.
Not that I accuse any person in this thread of towing that line, but the web as of today seems to be 99% of unneeded crap, with a tiny sprinkle of irrelevant content.
HTML elements can style themselves now using the @scope rule. (It's Baseline Newly Available.) Unlike the "style" attribute, @scope blocks can include @media and other @ rules. You can't get more self-contained than this.
The reason approaches like this continue to draw crowds is that Web Components™ as a term is a confluence of the Custom Elements JS API and Shadow DOM.
Shadow DOM is awful. Nobody should be using it for anything, ever. (It's required for putting child-element "slots" in custom elements, and so nobody should use those, either.) Shadow DOM is like an iframe in your page; styles can't escape the shadow root and they can't get into the shadow root, either. IDs are scoped in shadow roots, too, so the aria-labelledby attribute can't get in or out, either.
@scope is the right abstraction: parent styles can cascade in, but the component's styles won't escape the element, giving you all of the (limited) performance advantages of Shadow DOM with none of the drawbacks.
That's styling itself sure, but it's not self-evidently self-contained. Does every component emit those styles? Are they in the page stylesheet? How do they get loaded?
Counterpoint: Shadow DOM is great. People should be using it more. It's the only DOM primitive that allows for interoperable composition. Without it you're at the mercy of frameworks for being able to compose container components out of internal structure and external children.
Sort by negative sentiment; Shadow DOM is at the top of the list, the most hated feature in Web Components. You can read the comments, too, and they're almost all negative, and 100% correct.
"Accessibility nightmare"
"always hard to comprehend, and it doesn't get easier with time"
"most components don't need it"
"The big issue is you need some better way to some better way to incorporate styling from outside the shadow dom"
> It's the only DOM primitive that allows for interoperable composition.
There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.
As a result, you can only mix-and-match container components between frameworks with different reactivity workflows by giving up on fine-grained reactivity, blowing away the internals when you cross boundaries between frameworks. (And Shadow DOM makes it harder, not easier, to coordinate workflows between frameworks.)
Shadow DOM sucks at the only thing it's supposed to be for. Please, listen to the wisdom of the crowd here.
Yeah but most people don't need or want 'interoperable composition', they want sites with a consistent look-and-feel. Shadow DOM makes this much more difficult.
> it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS
> Also, don't do this [...] That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. To many HTML elements can slow the page to a crawl.
A static JS-less page can handle a lot of HTML elements - "HTML bloat" isn't really a thing unless those HTML elements come with performance-impacting behaviour. Which "self-contained" web-components "bringing along their own dependencies" absolutely will.
> shouldn't require an external framework
If you're "bringing along your own dependencies" & you don't have any external framework to manage those dependencies, you're effectively loading each component instance as a kind of "statically linked" entity, whereby those links are in-memory. That's going to bloat your page enormously in all but the simplest of applications.
I disagree on the number of elements actually approaching problematic territory, but agree this just isn’t something you can’t do already without web components
I might toss it out there that upcoming changes to attr() [0] as well as typed properties [1] will add some interesting features. Being able to provide a value that's subbed into a stylesheet from the HTML itself is neat.
You can try to get by with auto-generated selectors for every possible value today, ([background="#FFFFFF"]{background: #FFFFFF}[background="#FFFFFE"]{background: #FFFFFE}...) but just mapping attributes to styles 1:1 does begin to feel like a very lightweight component.
(Note... I'm not convinced this is a great idea... but it could be interesting to mess around with.)
According to the dictionary, the word component means "a part or element of a larger whole" which I think goes to the opposite direction of "self contained"
Author of the blog post here! Since this blog post, I put this idea to practice on the VS Code website (https://code.visualstudio.com/) to create all the interactive graphics on the homepage. Which is a slightly different use case than what I described in the post, but cool and effective none-the-less.
What woud have been a soup of `div` elements with various class names are now more meaningfully named elements like `<top-bar>`, `<chat-container>`, etc. that were mixed and remixed to create all the graphics.
Also no issues regarding performance that we've seen up to this point, which makes sense; browsers are very good and fast at rendering HTML elements (native or custom).
I have flirted with this in the past and an important note that you are missing from the post, that this type of custom element should only replace divs and spans. These new elements will have no meaning to the document outline or for accessibility.
I like that the author came to the idea by cross pollination via web components.
However, it's basically describing the "modifiers" part of BEM, which is a pattern that emerged from structuring CSS. Neither custom element or attributes are needed, even though they might feel different.
If you like that kind of pattern to structure CSS, then combining it with custom CSS properties (often called "variables", example: --block-spacing: 2rem) makes it even more modular. These properties follow the cascade rule.
The reason fixing ads from the inside won’t work is that they are designed to disrupt. An ad that ruins your scrolling for three seconds is preferable to one that ruins your scrolling for 2.5 seconds. All ads are designed to wreck the environment that they are in, to create a space for irrationality to enter.
I'm not a fan of these custom elements. Unless you do something really interactive, dynamic and reusable (an element with complex behavior), I don't think it's worth to use them. The SEO / accessibility becomes more challenging. Also, worth to noting, web components require JS, so they are not pure "CSS" web components. Web components are useful for isolation, when used with shadow DOM.
Using custom elements as the article suggests doesn't require JavaScript, so they are "pure" HTML and CSS (though whether they count as "web components" is up to you). More to the point, all of the technologies that the term "web components" includes — custom elements, <template> tags, shadow DOM — can be used without JavaScript.
<div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
My point is that defining a complex behavior for a custom tag is not possible without js.
For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>. I mean you can use something like <host-element> (html5 allows that), but it will just be an inline element, almost like <span>, but without semantics. It's not a full web component.
> "shadow DOM — can be used without JavaScript"
Yes, shadow DOM can be used without JS, but I was talking about web components.
> "I'm not sure what SEO and accessibility challenges custom elements would introduce?"
If you replace standard elements (such as 'p', 'a', 'button', etc) with custom ones it can hurt SEO and accessibility. There are very few reasons to use custom element names and attributes if they are not full web components.
What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
Why not use CSS without the custom element? From this post I don't see the benefit of using <swim-lanes> over <section class="swim-lanes"> for example.
Arguably, that would be misuse of the semantic meaning of "section." While <section> is nearly as generic as <div>, they should always have a heading of their own. The author's <swim-lane> already has a nested <section> with its own <h2>, but the <swim-lane> itself doesn't get (or need) its own even-higher heading.
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
1. Specificity - swim-line.buttons vs .swin-lines.buttons vs .buttons.swim-lanes.
2. Future pathing - Maybe you don't need a Web Component today, but you might need one tomorrow.
3. Cleaner - <swim-lane /> is just better than <div class="swim-lane" />
"Clean" is the biggest lie in software development. It's an aesthetic opinion dressed up as objective fact. You think components are clean, someone else thinks classes are clean, and neither of you are wrong, except for believing that "clean" is a property of the code and not something entirely in your own mind.
I'm a big web components guy, but calling these web components is a massive stretch of the word component.
The word "component" has to mean something ultimately, and to me the defining feature of a web component is that it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS, etc. Web components shouldn't require an external framework or external CSS (except for customization by the user) - those things should be implementation details depended on directly by the component.
This here is just CSS using tag names for selectors. The element is doing nothing on its own.
Which is fine! It's just not web components.
edit: Also, don't do this:
That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. Too many HTML elements can slow the page to a crawl.Use classes:
They're meant for this, lighter weight, and highly optimized.> To many HTML elements can slow the page to a crawl.
You can read the entirety of War and Peace in a single HTML file: https://standardebooks.org/ebooks/leo-tolstoy/war-and-peace/...
A marketing page, SaaS app landing, etc., will not even begin to approach that size, whether or not you add an extra wrapper around your <a>s.
Thank you for this example. I'm going to keep it in mind the next time I asked myself if there are too many elements or not.
Almost 15,000 elements! I do agree that too many elements can slow a page but from my experience that starts to happen a few hundred thousand elements, at least that's what we'd run into making data visualizations for network topologies (often millions of nodes + edges) but the trick for that was to just render in canvas.
This is a wonderful example how people live in the inverse-world.
Marketing is in the end a way of trying to get people to listen, even if you have nothing substantial to say (or if you have something to say, potentially multiply the effect of that message). That means you have to invent a lot of packaging and fluff surrounding the thing you want to sell to change peoples impression independent of the actual substance they will encounter.
This to me is entirely backwards. If you want people to listen focus on your content, then make sure it is presented in a way that serves that content. And if we are talking about text, that is really, really small in terms of data and people will be happy if they can access it quickly and without 10 popups in their face.
Not that I accuse any person in this thread of towing that line, but the web as of today seems to be 99% of unneeded crap, with a tiny sprinkle of irrelevant content.
The experience also depends on the desired outcome, and who's outcome that is. The marketers? or the readers? Which comes first? How far should it go?
nice, Firefox Reader Mode tells me i need 2968 to 3774 minutes
HTML elements can style themselves now using the @scope rule. (It's Baseline Newly Available.) Unlike the "style" attribute, @scope blocks can include @media and other @ rules. You can't get more self-contained than this.
You can also extract them to a CSS file, instead. The reason approaches like this continue to draw crowds is that Web Components™ as a term is a confluence of the Custom Elements JS API and Shadow DOM.Shadow DOM is awful. Nobody should be using it for anything, ever. (It's required for putting child-element "slots" in custom elements, and so nobody should use those, either.) Shadow DOM is like an iframe in your page; styles can't escape the shadow root and they can't get into the shadow root, either. IDs are scoped in shadow roots, too, so the aria-labelledby attribute can't get in or out, either.
@scope is the right abstraction: parent styles can cascade in, but the component's styles won't escape the element, giving you all of the (limited) performance advantages of Shadow DOM with none of the drawbacks.
That's styling itself sure, but it's not self-evidently self-contained. Does every component emit those styles? Are they in the page stylesheet? How do they get loaded?
Counterpoint: Shadow DOM is great. People should be using it more. It's the only DOM primitive that allows for interoperable composition. Without it you're at the mercy of frameworks for being able to compose container components out of internal structure and external children.
https://2025.stateofhtml.com/en-US/features/web_components/
Sort by negative sentiment; Shadow DOM is at the top of the list, the most hated feature in Web Components. You can read the comments, too, and they're almost all negative, and 100% correct.
"Accessibility nightmare"
"always hard to comprehend, and it doesn't get easier with time"
"most components don't need it"
"The big issue is you need some better way to some better way to incorporate styling from outside the shadow dom"
> It's the only DOM primitive that allows for interoperable composition.
There is no DOM primitive that allows for interoperable composition with fine-grained reactivity. Your framework offers fine-grained reactivity (Virtual DOM for React/Preact, signals for Angular, runes for Svelte, etc.) and any component that contains another component has to coordinate with it.
As a result, you can only mix-and-match container components between frameworks with different reactivity workflows by giving up on fine-grained reactivity, blowing away the internals when you cross boundaries between frameworks. (And Shadow DOM makes it harder, not easier, to coordinate workflows between frameworks.)
Shadow DOM sucks at the only thing it's supposed to be for. Please, listen to the wisdom of the crowd here.
Yeah but most people don't need or want 'interoperable composition', they want sites with a consistent look-and-feel. Shadow DOM makes this much more difficult.
There's a lot of contradictions in this comment.
> it's self-contained: it brings along its own dependencies, whether that's JavaScript, templates, CSS
> Also, don't do this [...] That just adds HTML bloat to the page, something people with a singular focus on eliminating JavaScript often forget to worry about. To many HTML elements can slow the page to a crawl.
A static JS-less page can handle a lot of HTML elements - "HTML bloat" isn't really a thing unless those HTML elements come with performance-impacting behaviour. Which "self-contained" web-components "bringing along their own dependencies" absolutely will.
> shouldn't require an external framework
If you're "bringing along your own dependencies" & you don't have any external framework to manage those dependencies, you're effectively loading each component instance as a kind of "statically linked" entity, whereby those links are in-memory. That's going to bloat your page enormously in all but the simplest of applications.
I disagree on the number of elements actually approaching problematic territory, but agree this just isn’t something you can’t do already without web components
I might toss it out there that upcoming changes to attr() [0] as well as typed properties [1] will add some interesting features. Being able to provide a value that's subbed into a stylesheet from the HTML itself is neat.
You can try to get by with auto-generated selectors for every possible value today, ([background="#FFFFFF"]{background: #FFFFFF}[background="#FFFFFE"]{background: #FFFFFE}...) but just mapping attributes to styles 1:1 does begin to feel like a very lightweight component.
(Note... I'm not convinced this is a great idea... but it could be interesting to mess around with.)
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/V...
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
According to the dictionary, the word component means "a part or element of a larger whole" which I think goes to the opposite direction of "self contained"
Author of the blog post here! Since this blog post, I put this idea to practice on the VS Code website (https://code.visualstudio.com/) to create all the interactive graphics on the homepage. Which is a slightly different use case than what I described in the post, but cool and effective none-the-less.
What woud have been a soup of `div` elements with various class names are now more meaningfully named elements like `<top-bar>`, `<chat-container>`, etc. that were mixed and remixed to create all the graphics.
Also no issues regarding performance that we've seen up to this point, which makes sense; browsers are very good and fast at rendering HTML elements (native or custom).
I have flirted with this in the past and an important note that you are missing from the post, that this type of custom element should only replace divs and spans. These new elements will have no meaning to the document outline or for accessibility.
Is this not exactly what DaisyUI (https://daisyui.com) is?
I like that the author came to the idea by cross pollination via web components.
However, it's basically describing the "modifiers" part of BEM, which is a pattern that emerged from structuring CSS. Neither custom element or attributes are needed, even though they might feel different.
If you like that kind of pattern to structure CSS, then combining it with custom CSS properties (often called "variables", example: --block-spacing: 2rem) makes it even more modular. These properties follow the cascade rule.
The reason fixing ads from the inside won’t work is that they are designed to disrupt. An ad that ruins your scrolling for three seconds is preferable to one that ruins your scrolling for 2.5 seconds. All ads are designed to wreck the environment that they are in, to create a space for irrationality to enter.
I've never been deep into XSLT, but I kind of have the impression, that this would have solved the issue.
I'm not a fan of these custom elements. Unless you do something really interactive, dynamic and reusable (an element with complex behavior), I don't think it's worth to use them. The SEO / accessibility becomes more challenging. Also, worth to noting, web components require JS, so they are not pure "CSS" web components. Web components are useful for isolation, when used with shadow DOM.
Using custom elements as the article suggests doesn't require JavaScript, so they are "pure" HTML and CSS (though whether they count as "web components" is up to you). More to the point, all of the technologies that the term "web components" includes — custom elements, <template> tags, shadow DOM — can be used without JavaScript.
<div> and <span> are semantically neutral, so I'm not sure what SEO and accessibility challenges custom elements would introduce?
My point is that defining a complex behavior for a custom tag is not possible without js. For example, you can't define a reusable 'host-element' tag and expect some additional elements (or some behavior) to automatically appear inside it each time your html includes or you create <host-element> ... </host-element>. I mean you can use something like <host-element> (html5 allows that), but it will just be an inline element, almost like <span>, but without semantics. It's not a full web component.
> "shadow DOM — can be used without JavaScript" Yes, shadow DOM can be used without JS, but I was talking about web components.
> "I'm not sure what SEO and accessibility challenges custom elements would introduce?" If you replace standard elements (such as 'p', 'a', 'button', etc) with custom ones it can hurt SEO and accessibility. There are very few reasons to use custom element names and attributes if they are not full web components.
What's the point of using selector 'link-button[size="large"] a {...}' when you could do the same with '.link-button.large a {...}'?
Using a expression from Spain : Es mas viejo que el cagar.
Why not just use CSS?
It is using CSS.
Why not use CSS without the custom element? From this post I don't see the benefit of using <swim-lanes> over <section class="swim-lanes"> for example.
Arguably, that would be misuse of the semantic meaning of "section." While <section> is nearly as generic as <div>, they should always have a heading of their own. The author's <swim-lane> already has a nested <section> with its own <h2>, but the <swim-lane> itself doesn't get (or need) its own even-higher heading.
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
Web components come with additional complexity, heavy use of custom element definitions are more complicated to manage.
It’s more than just an aesthetic preference
But if you’re not really using web components it’s harmless but it’s a bit odd and pointless.
HTML had custom elements before Web Components (the complex modern JavaScript & Shadow DOM thing) came into being. https://www.w3.org/TR/2016/WD-custom-elements-20160523/
A handful of benefits:
1. Specificity - swim-line.buttons vs .swin-lines.buttons vs .buttons.swim-lanes. 2. Future pathing - Maybe you don't need a Web Component today, but you might need one tomorrow. 3. Cleaner - <swim-lane /> is just better than <div class="swim-lane" />
"Clean" is the biggest lie in software development. It's an aesthetic opinion dressed up as objective fact. You think components are clean, someone else thinks classes are clean, and neither of you are wrong, except for believing that "clean" is a property of the code and not something entirely in your own mind.