dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
yes web components have advantages - but it's not the one size fits all solution you describe
web components are not as accessible as standard dom elements
web components are not as SEO friendly as standard dom elements
web components are slower for the initial rendering
web components are not universal - they are browser only
web components are worse when splitting js and css code
web components don't work well with client side routing
web components don't have typed props
web components have a smaller eco system
some but definitely not all of these issues can be fixed with a lot of additional javascript - but if you need javascript for rendering anyway - why wouldn't you just use javascript which renders standard dom elements instead?
don't pick a framework only because it's build into the browser - pick the framework which is best for your users and developers
web components are not as accessible as standard dom elements
That depends on how you build them. I create formAssociated, keyboard accessible, screen-reader friendly components.
web components are not as SEO friendly as standard dom elements
This is actually a complete reversal of the truth, assuming you use them properly. I have been promoting semantics since before Google existed. You want to know what is truly not SEO friendly, div soup, which is exactly what you end up with when using most frameworks.
web components are slower for the initial rendering
This demo page is blazing fast. Anyone can achieve this level of optimization. The only reason it does not hit a perfect score for speed is because of Google's own analytics code.
web components are not universal - they are browser only
Well yes, Web Components are for creating UI elements. It's right in the name of the APIs: Shadow DOM, Custom Elements, HTML Templates... What more do you expect?
web components are worse when splitting js and css code
What makes you think that? They are plenty flexible. You can split your markup, js, and css if you wish, or combine into a cohesive unit. You are not forced into any specific structure.
web components don't work well with client side routing
Web Components don't care what your routing method is. Hell, you can do pure CSS routing if you really wanted to.
web components don't have typed props
Neither do native HTML Elements. If you're worried about type safety, you can write your components in TypeScript. And runtime validation is definitely something you can and should do in production JS.
web components have a smaller eco system
Ok, this is a fair point. But something that is easily correctable. All we need is for more devs to start using them!
dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
Thanks for your detailed answer and maybe I am wrong and things changed already.
Could you help me to understand the following questions?
Is it still the point that web-components make frameworks obsolete?
Because if web-components also need a framework I don't see the point over using a standard dom framework..
Accessibility:
a. Can you use aria-labelledby somewhere on the page and target inside the shadow dom?
b. Given I have my inside my Is it somehow possible to help the screen reader to treat all the radio buttons as part of one group (like "2 of 5 selected") instead announcing each as its own individual group ("1 of 1 selected")?
c. Does focus delegation work now out of the box as in native DOM without additional code?
SEO:
a. Does Blink recognise the a tag in your template for Click Me although it is not part of the initial DOM?
Initial rendering:
a. Do Websites built out of web-components show a broken or empty page until Javascript connects the Custom Elements to their templates?
b. Can you load only the Web Components which are on the initial view without waterfalls?
Universal
Don't have a question - you already said it is browser only
Code Splitting
a. (Same as 3b) Can you automatically split the code per route so that a user only the loads the optimized js and css of the components on the current page without waterfalls?
Client Side Routing
a. Can you know which web-components will be on a given route before rendering it?
b. Can you load all web-components js, css and their data for a route in parallel?
Typed props
a. Would you say typing of webcomponent props is as good as other state of the art frameworks?
Smaller Eco System
Don't have a question - you already said real world adaptation is still lacking
Can you please share for what kind of projects you prefer web-components?
Maybe we are just trying to solve different problems
Web Components have not made the concept of frameworks obsolete yet, but they have made the way many frameworks work obsolete.
Custom elements have all the same capabilities that built-in elements have and literally ANYTHING a framework does can be done without one.
Each of your questions requires more explanation than a single comment could or should cover. Keep following this series and all will be made clear. I have released the next installment with several more already planned.
dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
Web Components are not a new idea. The standards evolved over time based on consensus from the browser vendors. Frameworks are competing against each other, not the standards. The standards define the features that framework authors can use. New standards will lead to new frameworks.
Can you use aria-labelledby somewhere on the page and target inside the shadow dom?
Does Blink recognise the a tag in your template for Click Me although it is not part of the initial DOM?
Again, use slots or Light DOM where appropriate. Shadow DOM is not required for Custom Elements and does not suit every use-case.
a. Do Websites built out of web-components show a broken or empty page until Javascript connects the Custom Elements to their templates?
b. Can you load only the Web Components which are on the initial view without waterfalls?
They have no more issues than any front-end framework. You must serve critical styles and components as part of the initial payload.
Universal - Don't have a question - you already said it is browser only
The JS and CSS parts of a component are browser only. But good Custom Elements can be represented with pure markup. Just go to view-source:https://bes.works. That page content is completely static. It can be viewed raw or with no stylesheet and is still represented in a meaningful way.
Can you automatically split the code per route so that a user only the loads the optimized js and css of the components on the current page
Would you say typing of webcomponent props is as good as other state of the art frameworks?
Custom Elements are defined by Classes.They can have any type of public or private property that you want. They can also have external attributes.
Can you please share for what kind of projects you prefer web-components?
I use them for all web based user interfaces on basically every project since 2017 (with polyfils). My local web dev directory contains 1184 occurrences of customElements.define. Those are not all unique, some are minified versions, or copy-pasted into other project trees, but none of them are third-party code. They include everything from pre-defined page layouts to declarable animations, custom form fields, data managers, video players, chat widgets, etc, etc, etc.
dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
Realistically, I would not even use a Custom Element to implement your idea. But if I did, I would simply use a Light DOM approach directly employing the already well defined tools the browser provides: <fieldset>, <label>, and <input type="radio">. When you follow a standards-based implementation workarounds like aria become irrelevant. In fact, the use of aria-* attributes is actually discouraged in any instance where you are able use the proper semantic elements.
However, if you really wanted to replace these elements with custom Shadow DOM versions then you would take on the full responsibility of handling all form association and accessibility features through custom scripting. You would need to make extensive use of Element Internals and ARIA Reflection inside your element definitions to emulate the behavior of the standard elements.
So, while mapping accessibility features is not simple, it can be achieved. Shoelace is one component library that has made a commitment to accessibility and they are doing a pretty decent job of it. You could try following their example or take a look at how others are handling this, or get creative and roll your own solution.
Meeting WCAG guidelines can be tricky even without involving Shadow DOM, and mastering these together will take time and effort. However, the platform is constantly improving and the developer experience will get better.
Here is a quick example of how a Web Component can be built without a Shadow DOM. These tersely typed <radio-group> elements get completely replaced by well structured, semantic HTML.
The final result that gets output to the page looks like this:
<fieldsetid="rg1"><legend> Pick One </legend><label><inputtype="radio"value="yes"name="choice"><span>Yes</span></label><label><inputtype="radio"value="no"name="choice"><span>No</span></label><label><inputtype="radio"value="maybe"name="choice"><span>Maybe</span></label></fieldset>
Just clean, SEO and screen-reader friendly markup that can be fully themed by the page's stylesheet.
Of course this is not production ready code by any means, just an example of what can be done. Every JS framework composes down to DOM in the end. I prefer to keep that end result as clean and semantic as possible. To me, the page structure is just as important as the visual representation.
dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
Okay that looks better as I expected - but I still believe this would be a lot easier to read if it was written in react.
I have an idea (maybe for a post?) - I'll create a small mini react app which uses such a radio group and you show me how you would convert it to a 1:1 web-components equivalent and explain why you believe your solution is better.
Nah, I'm not gonna waste my time writing production ready code to prove a point that you will just ignore anyway. You've made it clear that you believe React is better. Nothing I say will convince you to change your mind.
dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
That sounds like a excuse - did you overpromise web-components?
About my "believes":
I led large projects already before react and tried a lot of different technologies.
Even polymer. But everything I saw until today showed always the same result:
You can't have the same DX and UX for large projects with web-components
Here is a minimal demo - it took me 1h.
But you told web-components are superior so I guess you will be faster?
Goal is to have the following typed API for other developers:
First of all. Your example does NOT work without javascript. It "looks" the same sure, but it doesn't work. Go try it yourself with noscript if you don't believe me.
Personally, I don't put too much effort into supporting browsers with JS disabled. But well built web components fall back to plain text/css anyway so it's not an issue that I lose any sleep over. However, your example can be accomplished through pure css anyway, no JS at all, if that really matters for your use-case.
But the real reason why your example is bad is because you need an entire framework to implement one little feature. Here is a similar component that I built years ago. The source is here. No framework necessary, no compiling, no dependencies it all. And, if you view the markup for that demo page, you will see that the usage is elegant. It's not just a bunch of divs with inline styles applied. It's meaningful, semantic, HTML. Readable even without a browser, let alone JS or CSS.
And what happens if you want to use it dynamically? With a web component, you just include the module and add the element anywhere want to use it. Need another one, just append it. Need more items, just add them on the fly. Good luck doing that with your React component without a whole bunch more added complexity.
dad living in Switzerland 🇨🇭 mainly working on typescript, css and compiler related frontend topics - maybe you know me from html-webpack-plugin, text-box-trim or next-yak
You are right - the prev/next button does not work - only the swipe and mouse wheel interactions
Most of the time that's good enough for me as I am optimizing for UIs which can be initially rendered without javascript.
This helps when javascript which is not under my control takes precious time during the initial rendering (like analytics scripts or bot detection scripts)
Also it allows me to keep the same DOM without needing to modify it during startup which can be quite slow - especially on Android budget phones for pages with a lot of features
My users don't read the HTML - so I don't understand that point.
However what is important for me is Accessibility tree - check it out if you haven't already: Acessibility tree
These slides aren't divs - why do you say that?
A screen reader even reads out loud on what slide you are and how many there are in total because of the markup:
The inline styles are only for the sake of the demo - but if those colors where dynamic (e.g. from a database) it might be totally fine to use inline styles.
I guess what I like about my version over yours is that it can be developed by different teams.
Maybe you work mostly alone but for larger projects it is really helpful to have good APIs - probably that's also why I like typescript.
And the team which created the component is still able to change the implementation details and fix bugs.
This alone justifies the cost of the framework as long as I can provide real world best of class loading performance (e.g. better LCP than competitors).
Do you usually work on large projects with multiple teams or rather on small / solo projects?
yes web components have advantages - but it's not the one size fits all solution you describe
some but definitely not all of these issues can be fixed with a lot of additional javascript - but if you need javascript for rendering anyway - why wouldn't you just use javascript which renders standard dom elements instead?
don't pick a framework only because it's build into the browser - pick the framework which is best for your users and developers
That depends on how you build them. I create
formAssociated, keyboard accessible, screen-reader friendly components.This is actually a complete reversal of the truth, assuming you use them properly. I have been promoting semantics since before Google existed. You want to know what is truly not SEO friendly, div soup, which is exactly what you end up with when using most frameworks.
This demo page is blazing fast. Anyone can achieve this level of optimization. The only reason it does not hit a perfect score for speed is because of Google's own analytics code.
Well yes, Web Components are for creating UI elements. It's right in the name of the APIs: Shadow DOM, Custom Elements, HTML Templates... What more do you expect?
What makes you think that? They are plenty flexible. You can split your markup, js, and css if you wish, or combine into a cohesive unit. You are not forced into any specific structure.
Web Components don't care what your routing method is. Hell, you can do pure CSS routing if you really wanted to.
Neither do native HTML Elements. If you're worried about type safety, you can write your components in TypeScript. And runtime validation is definitely something you can and should do in production JS.
Ok, this is a fair point. But something that is easily correctable. All we need is for more devs to start using them!
Thanks for your detailed answer and maybe I am wrong and things changed already.
Could you help me to understand the following questions?
Is it still the point that web-components make frameworks obsolete?
Because if web-components also need a framework I don't see the point over using a standard dom framework..
Accessibility:
a. Can you use
aria-labelledbysomewhere on the page and target inside the shadow dom?b. Given I have my inside my Is it somehow possible to help the screen reader to treat all the radio buttons as part of one group (like "2 of 5 selected") instead announcing each as its own individual group ("1 of 1 selected")?
c. Does focus delegation work now out of the box as in native DOM without additional code?
SEO:
a. Does Blink recognise the
atag in your template for Click Me although it is not part of the initial DOM?Initial rendering:
a. Do Websites built out of web-components show a broken or empty page until Javascript connects the Custom Elements to their templates?
b. Can you load only the Web Components which are on the initial view without waterfalls?
Universal
Don't have a question - you already said it is browser only
Code Splitting
a. (Same as 3b) Can you automatically split the code per route so that a user only the loads the optimized js and css of the components on the current page without waterfalls?
Client Side Routing
a. Can you know which web-components will be on a given route before rendering it?
b. Can you load all web-components js, css and their data for a route in parallel?
Typed props
a. Would you say typing of webcomponent props is as good as other state of the art frameworks?
Smaller Eco System
Don't have a question - you already said real world adaptation is still lacking
Can you please share for what kind of projects you prefer web-components?
Maybe we are just trying to solve different problems
Web Components have not made the concept of frameworks obsolete yet, but they have made the way many frameworks work obsolete.
Custom elements have all the same capabilities that built-in elements have and literally ANYTHING a framework does can be done without one.
Each of your questions requires more explanation than a single comment could or should cover. Keep following this series and all will be made clear. I have released the next installment with several more already planned.
So it's just a new framework like this? 😉
I am really looking forward to read your follow up articles
For now could you please give a short yes/no answer to those questions?
Web Components are not a new idea. The standards evolved over time based on consensus from the browser vendors. Frameworks are competing against each other, not the standards. The standards define the features that framework authors can use. New standards will lead to new frameworks.
Not exactly, but also you probably should use Light DOM or slotted content instead.
Yes
Yes
Again, use slots or Light DOM where appropriate. Shadow DOM is not required for Custom Elements and does not suit every use-case.
They have no more issues than any front-end framework. You must serve critical styles and components as part of the initial payload.
The JS and CSS parts of a component are browser only. But good Custom Elements can be represented with pure markup. Just go to
view-source:https://bes.works. That page content is completely static. It can be viewed raw or with no stylesheet and is still represented in a meaningful way.Yes
Yes
Yes
Custom Elements are defined by Classes.They can have any type of public or private property that you want. They can also have external attributes.
I use them for all web based user interfaces on basically every project since 2017 (with polyfils). My local web dev directory contains 1184 occurrences of
customElements.define. Those are not all unique, some are minified versions, or copy-pasted into other project trees, but none of them are third-party code. They include everything from pre-defined page layouts to declarable animations, custom form fields, data managers, video players, chat widgets, etc, etc, etc.Thanks - I guess you are right it goes way to much into detail
Maybe you can cover the accessibility aspect in a post - I quickly tested the ElementInternals API and it did not work for me:
codepen.io/jantimon-the-sans/pen/M...
You can see that VoiceOver says it is 1/1 not 2/3:
Also I personally don't agree with other answers you gave - if you like to discuss more let me know
Realistically, I would not even use a Custom Element to implement your idea. But if I did, I would simply use a Light DOM approach directly employing the already well defined tools the browser provides:
<fieldset>,<label>, and<input type="radio">. When you follow a standards-based implementation workarounds like aria become irrelevant. In fact, the use ofaria-*attributes is actually discouraged in any instance where you are able use the proper semantic elements.However, if you really wanted to replace these elements with custom Shadow DOM versions then you would take on the full responsibility of handling all form association and accessibility features through custom scripting. You would need to make extensive use of Element Internals and ARIA Reflection inside your element definitions to emulate the behavior of the standard elements.
So, while mapping accessibility features is not simple, it can be achieved. Shoelace is one component library that has made a commitment to accessibility and they are doing a pretty decent job of it. You could try following their example or take a look at how others are handling this, or get creative and roll your own solution.
Meeting WCAG guidelines can be tricky even without involving Shadow DOM, and mastering these together will take time and effort. However, the platform is constantly improving and the developer experience will get better.
Here is a quick example of how a Web Component can be built without a Shadow DOM. These tersely typed
<radio-group>elements get completely replaced by well structured, semantic HTML.The final result that gets output to the page looks like this:
Just clean, SEO and screen-reader friendly markup that can be fully themed by the page's stylesheet.
Of course this is not production ready code by any means, just an example of what can be done. Every JS framework composes down to DOM in the end. I prefer to keep that end result as clean and semantic as possible. To me, the page structure is just as important as the visual representation.
Okay that looks better as I expected - but I still believe this would be a lot easier to read if it was written in react.
I have an idea (maybe for a post?) - I'll create a small mini react app which uses such a radio group and you show me how you would convert it to a 1:1 web-components equivalent and explain why you believe your solution is better.
What do you think?
Nah, I'm not gonna waste my time writing production ready code to prove a point that you will just ignore anyway. You've made it clear that you believe React is better. Nothing I say will convince you to change your mind.
That sounds like a excuse - did you overpromise web-components?
About my "believes":
I led large projects already before react and tried a lot of different technologies.
Even polymer. But everything I saw until today showed always the same result:
You can't have the same DX and UX for large projects with web-components
Here is a minimal demo - it took me 1h.
But you told web-components are superior so I guess you will be faster?
Goal is to have the following typed API for other developers:
It should look the same with and without JavaScript
demo-peek-carousel.vercel.app/
Code: github.com/jantimon/demo-peek-caro...
Surprise me - proof me wrong and show me how much better you can develop it with web-components
First of all. Your example does NOT work without javascript. It "looks" the same sure, but it doesn't work. Go try it yourself with noscript if you don't believe me.
Personally, I don't put too much effort into supporting browsers with JS disabled. But well built web components fall back to plain text/css anyway so it's not an issue that I lose any sleep over. However, your example can be accomplished through pure css anyway, no JS at all, if that really matters for your use-case.
But the real reason why your example is bad is because you need an entire framework to implement one little feature. Here is a similar component that I built years ago. The source is here. No framework necessary, no compiling, no dependencies it all. And, if you view the markup for that demo page, you will see that the usage is elegant. It's not just a bunch of divs with inline styles applied. It's meaningful, semantic, HTML. Readable even without a browser, let alone JS or CSS.
And what happens if you want to use it dynamically? With a web component, you just include the module and add the element anywhere want to use it. Need another one, just append it. Need more items, just add them on the fly. Good luck doing that with your React component without a whole bunch more added complexity.
You will never convince me that React is better.
You are right - the prev/next button does not work - only the swipe and mouse wheel interactions
Most of the time that's good enough for me as I am optimizing for UIs which can be initially rendered without javascript.
This helps when javascript which is not under my control takes precious time during the initial rendering (like analytics scripts or bot detection scripts)
Also it allows me to keep the same DOM without needing to modify it during startup which can be quite slow - especially on Android budget phones for pages with a lot of features
My users don't read the HTML - so I don't understand that point.
However what is important for me is Accessibility tree - check it out if you haven't already: Acessibility tree
These slides aren't divs - why do you say that?
A screen reader even reads out loud on what slide you are and how many there are in total because of the markup:
The inline styles are only for the sake of the demo - but if those colors where dynamic (e.g. from a database) it might be totally fine to use inline styles.
I guess what I like about my version over yours is that it can be developed by different teams.
Maybe you work mostly alone but for larger projects it is really helpful to have good APIs - probably that's also why I like typescript.
Think about it multiple teams can just write:
And the team which created the component is still able to change the implementation details and fix bugs.
This alone justifies the cost of the framework as long as I can provide real world best of class loading performance (e.g. better LCP than competitors).
Do you usually work on large projects with multiple teams or rather on small / solo projects?
Is that being open-minded as you asked of me?
You're right. The ironic part of your argument is that your React component actually composes down to an unregistered Custom Element.
To which I say...