More accurately, I’m over everyone treating it like the only answer.
I'm a devout supporter of Web Components and have been preaching the gospel of web standards for decades. That guy you always hear muttering "Why use a library when the browser gives you everything you need?"
I have lived through five versions of HTML (2,3,4,XHTML,5) and watched as libraries like jQuery and frameworks like Angular have come and gone from the spotlight. And I'm here now to tell you that you never NEEDED any of them and this has never been more true than it is today.
Custom Elements, Shadow DOM, HTML Templates. These tools provide everything we need to build robust, modern components without relying on heavy abstractions. But still, in 2025, the web development world clings tightly to libraries like React.
The Standard Approach
I'll admit that React played a huge role in shaping modern front-end development. Its component model, reactive updates, and rich ecosystem were groundbreaking when they emerged. But React’s reliance on third-party extensions like JSX, its synthetic event system, performance overhead, and tendency to blur styling and logic inside components all fall short of the standards set for the web.
Web Components — by contrast — are a core part of the web standards, embrace the browser’s strengths, benefit from baked in optimizations, and promote separation of concerns. All without the need for build pipelines or runtime libraries. You’re working with the platform, not against it.
Universal by Design
Perhaps the most underappreciated strength of Web Components is their inherent interoperability. Build a standards-compliant component, and you can drop it into any toolkit. Whether you’re using Vue, Svelte, whatever the flavor-of-the-year framework is, or just static HTML, Web Components fit right in.
With React, moving components between frameworks often means rewrites, dependency tangles, and awkward integration. Why lock your work into a single ecosystem when the browser already provides a universal language? And don't even get me started on stateful rendering in an environment that was intentionally designed to be stateless.
Well designed Custom Elements can be used completely declaratively, blend seamlessly into Server Side Rendering, can be styled through standard CSS, are naturally encapsulated, and the list of capabilities goes on and on and on...
The State of Things
I’m not here to say React is evil or useless. It’s a mature, powerful tool with plenty of successful projects under its belt. But in 2025, when developers continue to reach for it by default, that seems more like a bad habit — a reflex that hasn’t caught up to the evolution of the platform.
For those of us who’ve been building with Web Components for years, the continued use of vendor-specific solutions feels increasingly out of sync with the realities of the web platform. Most of the problems that React once solved have been addressed at the platform level long ago. Web Components have been mature for years. It's time to stop solving today's problems with yesterday’s tools. Imagine if we never stopped using tables for layout just because "That's how we've always done it".
Building for The Future
Obviously we all use the tools we know and trust. But sometimes we need to challenge ourselves to re-examine whether those tools are still the best fit for today’s (and tomorrow’s) needs. That's exactly why the standards exist and continue to evolve. And exactly why I will stick with them as I always have. Because one day, React will fade into obscurity just like jQuery while Web Components will live on as long as the web itself.
Top comments (138)
Not sure about this homie... you might, for example, add an example. Here is a data table component with back and frontend pagination/filter/sorting/search built in web components vs. React. Then you could prove your thesis rather than just stating opinion. One should remain objective when analyzing architectures. I built all this stuff 100 times before react existed, and 100 times after, I still use react ATM but open to be convinced that another is better.
It's not better, it's something completely different. Web components are isolated units that are not designed to be managed by some app wide state manager like in React, although you can certainly do that and there are frameworks out there who make it easier, like atomicojs for example. Web components are all about isolation and reusability. Consider them as independently published building blocks, that you can use inside a bigger application where you'd use them the same way you're using
divorinputright now.Exactly. Or just build your own component library. The point is that they can be used just like native HTML Elements. They blend seamlessly into the fabric of the web.
That is basically the point of React, reactive components. Same with angular really. I do agree though, generally if you 'need' a framework to program than your language sucks... and JS and HTML has sucked. Problem with react, its strict on component composition and most devs get it entirely wrong so they fall back on global states and useMemo, which becomes unmaintainable fast. But if you focus on component composition and 'lifting state' to the lowest needed level, it basically guarantees optimized renders if you do it correct. TS helps to achieve it in react. Angular is more open and less strict, easier to achieve but harder to enforce. Web components does sound like a potential replacement, like silverlight vs. HTML5 canvas, which would be ideal... but if it can't replace a framework we all find critical, I don't know if I'll use it or for what.
The only optimized rendering is that which is done by the browser itself through compositing. Every DOM update is expensive. React components are notorious for causing unnecessary re-renders of the entire component for a small change in state. Add to that the Virtual DOM and now you have added significant performance overhead.
By contrast, an efficiently designed custom element would update only the single part of itself that needs to be changed. If positional changes are handled via transforms only then there are no modifications made to the DOM at all and you enter the realm of true rendering optimization.
Not sure what you guys are building, maybe video games, but I've never had any issues with render speed in react unless the architecture is horrendous. A component will only rerender in react when it's props change, or it's parent changes. What often happens is devs fail to use proper component composition (I.e. children prop) so that the component hierarchy actually matches the intended rendering tree. Some devs rely entirely on global state, they've already lost usually when they do that. Often apps aren't built asynchronous properly, that also hurts in react. Generally only the user object and constants should be global in my react apps, I.e. when the user changes, that's the only time everything should rerender generally. When you do that, no reason you can't make a react component with zero props, so it only rerenders itself... the challenge for the architect is finding which layer in which to use each strategy. But when done right, man react just purrs.
Yes games, that is one good example where rendering performance is crucial. But really, any animation heavy UI elements. Here is one example that animates an SVG image, and another which manipulates a clip-path, or if you would like to see a more complete example, here's a full app demo built completely from web components.
But anything like that I would traditionally use the canvas and math, which has zero to do with react which could onky be a wrapper at most. I can't see the code for your demo site, or I'm missing it, but I'm getting the impression your doing that without the canvas. Css animation I think is cheap in react, but yeah I could see js based animations in a component, constantly resetting state, would be costly. I've used three.js I'm angular and react before no issues I recall, but its all canvas. Basically was a parts drill down gui, ordering, maintenance procures, etc. Funny though I tell you, I have seen some pretty basic react apps that should be fast, hose to hell, more often than not. Angular and most other frameworks are harder to screw up. And react and libs have responded in ways that discourage proper react. In the end, you need components... can call it a producer, provider, factory whatever... the rest is really just the vendors implementation preferences.
view-source:https://bes.works/bits/or Ctrl+uThat's right, there is no canvas involved. Here's a much more advanced example. This app was built entirely from custom elements and involves a significant amount of complex state handling and rendering optimizations in tandem.
erm apologie @gunslingor but React isn't reactive... at least out the box.
You would need to use something like MobX
Really? A state manager that follows mutability pattern suddenly changes something about the reactivity of React? I think what you mean to say is React follows a different rendering strategy with the vdom, instead of the signals based fine-grained dom updates that something like SolidJS uses. The effect is the same though, you only update the dom nodes that actually changed. React just has an extra step to calculate what changed.
Btw mutability (mobx/valtio) is an anti-pattern in functional programming.
Yeah interesting views... maybe explain them to the React team?
legacy.reactjs.org/docs/design-pri...
and they only exposes a mutable interface to the developer...
yikes.
Reactive Programming is just an esoteric term that attempts to redefine something that doesn't need to be redefined. JS is event-driven by nature and always has been. When using React you actually reduce reactivity by inverting this model. Not only this but you break the promise of asynchronicity and have to jump through hoops to get it back. Why even bother?
Every DOM Node and many other objects derive from EventTarget which means that they can receive and emit events. You can also easily create your own objects that extend EventTarget, and with EventSource or Web Sockets you can even listen for server generated events. All the reactivity you should ever need is baked right into the language.
I don't need to explain anything to the React team, however you could benefit greatly from understanding what mutability is, so in the future you might understand that it doesn't change anything about the rendering strategy of React.
Ah ok I went and learnt mutability is it something like this?
immerjs.github.io/immer/
the rendering strategy or react? it only has one strategy ever internally.
Good thing JS isn't a rigid functional language. It's a dynamic, multi-paradigm language, just like the web itself. Mutability is a core feature not something to shy away from. It's essential to creating a rich, interactive user experience.
If you need immutability you absolutely can accomplish that in various ways. The most obvious being the
constkeyword but also through use of private properties or getters without setters orObject.freeze.Having the power to dynamically change almost anything comes with the responsibility to understand how the browser handles reflow and repaint. React's Virtual DOM is their way of batching updates. The standard way to accomplish this is by using a DocumentFragment.
Don't worry, I will be writing more articles on this subject. However, in this one I linked to a page with dozens of examples of components that I have built. Feel free to view the source of any one of them to see how a well designed custom element should be structured.
Took a look. Need that intro and code 🙃. I would love it if these frameworks vanished overnight for native language features... I really kinda miss the days before even git was a thing, lol, I'm old.
I'm not a react expert, but I've used it. I don't think it's worth new coders learning, because there are much better solutions to the problems it solves now, and a lot of it appears to be baggage solving problems that no longer exist.
I agree. The problems React once solved are no longer problems. At this stage it just adds complexity that is not necessary.
I think you're wrong, why wouldn't every new developer learn it? is the most used framework and can open many more doors than any other one. Not using it is not easier, in my opinion.
New web developers should be learning JavaScript fundamentals not filling their head with ideas that do not align with the web standards. One should choose a library or framework based on experience and need. Otherwise it's like trying to build a pyramid upside down, eventually the weight of language will topple their fragile framework-based understanding. Better to start with a strong foundation.
I agree, and then, learn React because it will open a lot of doors for them.
Are there really opportunities for inexperienced devs in the React ecosystem? Why would a company hire a brand new dev who just learned React when the market is already saturated with those who have been using it for years? Better to learn something new and fresh and be poised to take advantage of the inevitable shift in the landscape.
inevitable shift? React has been the go to library for a long time and since the beginning people have been saying that it won't last long. People WILL hire a junior dev that knows React over one that doesn't, React teams will hire junior devs and someone that already knows react will have a door open, what are you talking about?
React's popularity has been in steady decline for several years.
It still holds a significant market share but... people also still use jQuery in 2025.
So will React ever disappear completely? No.
Is it worth learning today? That's debatable.
Is it the only option? Absolutely not!
To be fair, that crop is a little misleading. The full graph shows it better, but even so it's a terrible graphic in terms of conveying information to the user!
The thing it ends up showing is that React has an overall more positive opinion from actual users than any other framework it's competing with. The site you link to also states in the accompanying blurb that this is the common pattern for frameworks, so it's not really behaving any differently to others, it was just more popular to start with.
That being said, I'll work on legacy React projects but I will not start any new ones by choice.
Yes, a common pattern that was exactly the point. All the graph shows is that a lot of people have used React and that its popularity took a nosedive right around when web components started stabilizing. The other links further illustrate this pattern as predictable.
React did to web dev the exact same thing that Facebook itself did to the web. It attracted the average person. But just because a few billion jump on a bandwagon doesn't mean they have any idea where that wagon has been or where it is going.
The majority of Facebook users don't know anything about the nature of the web as a whole, and an alarming number of React users don't know anything about the platform it's built on. They simply accept their narrow spoon-fed viewpoint as axiomatic.
Zuck recently admitted that Facebook no longer really serves its original purpose. Many of its original users abandoned it long ago. React seems to be heading in the same direction. For anyone who has been watching the trends since the beginning, this is entirely expected.
you're living in the clouds mate, ANY developer should know React, and any dev should learn it first.
And I have an excellent aerial view of the landscape from up here. The fact of the matter is that many React users don't want to use it, they do so because they have to.
I don't expect to sway any of that segment who do want to use it. Just as I don't expect die-hard Windows fans to jump ship for Linux. If you're happy with React, then by all means continue using it. But don't try and pretend that it is the best simply because it has the highest body count.
Telling beginners to learn React first is like pointing them at a forklift when they don’t even know how to drive a car. Sure there’s some overlap, but it’s heavy, specialized, and won’t teach them the everyday skills they need to maneuver in traffic.
React is required in 80% of the positions I'm applying to when I look for a job, period.
I know. And I'm sick of it. Especially when some hiring manager with no clue about how the web actually works tries to imply that I am somehow less knowledgeable about web development for not wanting to use React.
The thing is though, the vast majority of jobs that insist on using it are not ones that I would even want to get involved with anyway. But the real problem is that companies just assume that the most popular option always equates to the best option. So it ends up being a requirement even for jobs where it completely over-complicates the scope.
And because of this mentality, experts on web standards are being squeezed out of our own industry in favor of juniors straight out of code bootcamps. Where will that leave the web in 10 years? And what will all these React only devs do when the bubble pops? 🤷
The only way I can see to fix this is to keep building a better web, one component and changed mind at a time. We as developers need to stand up for the standards and show companies how they can enable us to build better apps faster and easier without all the extra baggage.
However, we can't do it with rhetoric, we need real results. I'm doing my part, but I'm only one guy and I'm sure that I'm not the only one struggling in this economy. If I had the backing I could train an army of standards-first developers. I have the skills, knowledge and voice to do so. But instead, as a standards-only freelancer, I'm stuck competing with my peers over scraps. So, if anyone would like to collaborate on changing the world, please let me know.
fuck React
I have been using web components since 2018 and since 2022 currently working on a high profile project at work using web components. I was told by other developers I should use react. Turns out using web components was the best decision I made. Someone tried to poach my project by building it in react but nobody can match the speed, loading time and the low file size of the whole project. There is no updating npm dependencies, updating frameworks and migrations etc. We have established design patterns and have not needed to do anything different. We use all kinds of web components libraries and we can mix them no problem. It's so easy to work with, super easy to debug. It stinks because there aren't many or any companies using it, but there also isn't a lot of proper documentation to solve and offer corporate solutions. The downside is the learning curve for web components, you really need to understand JavaScript. Hiring becomes hard because there are just a bunch of react developers and not JavaScript developers. As this trend continues we have no choice but to know react to get jobs with the majority. At least I can say from experience of having done both, web components was amazing and a missed opportunity for blazing fast development.
Thank you for sharing your experience! This is the kind of thing I want to draw attention to.
This is a crucial point. Many framework-centric developers simply do not fully understand the underlying platform. My goal here is to share deep understanding of these misunderstood tools.
y'know what I wanna know? How to write profiles to hire devs that know web components (and I don't mean "has written a lit hello world app"). Like, with react I can write "5y exp. with react, react hooks, etc". What do I write for CEs? "5y HTML exp"? Then I'll get someone who still recreates the <details> element and such...
As much as I hate it, I think the web platform needs some sort of bullshit bingo :/
I think there are two key phrases that would be ideal to use:
This will likely scare away the average framework-centric dev. You could quiz the rest to be sure. And I don't mean a written or multiple choice test. Just a simple live conversation about the standards. If they don't have even a rough idea off the top of their head then they definitely don't have the deep experience you are looking for.
Or you could just reach out to me and we can discuss your project. I am available for work right now if you need help.
Dude I wanna learn more on how you do it. I'm a react user but web components impress me so much. How do I convert?
Stay tuned for more articles on this subject including tutorials. I intend to write about everything from the basics of how to get started, to advanced techniques that I have both learned and invented, to building fully functional web applications entirely from web components.
React and web components answer slightly different questions. There certainly has been some blurring of lines over the years.
I'd agree that there is merit in creating reusable gui elements as web components to allow them to work everywhere but I struggle to see any real benefit beyond that.
I really liked web components when they were new and even built a few polymer apps but I just found myself using them less and less and they weren't that useful in practice.
👎 You still need JS to load the components
🎯 DSD - Declaractive shadowDOM creates Components without JS
👎Encapsulation of app logic is a nono, leading to more complex pages (and more prop drilling).
🎯 Its just POJ (plain old javascript) add any state management library you need
👎With the shadow dom you can't, easily, style from outside leading to multiple variants of the same component.
🎯 RTFM:
Thanks for your response but none of these really answer my concerns.
Declaractive shadowDOM is no better than just using HTML, you can't have any interactivity, why add the complexity?
The just use JS argument is a little odd, as you can just use React, Preact, Angular or whatever you like, why add the complexity?
Your response to the styling from outside is complex is here are the complex methods you can use to style it from outside.
Whilst I don't have an issue with web components they rarely seem worth the effort (even if they effort really isn't that great).
Encapsulation.
Shadow DOM is not at all required but solves a litany of issues that have plagued the web for years. Personally I think div soup is disgusting and CSS frameworks like bootstrap and it's derivatives were a step backwards.
External styling does not need to be complicated. When designed properly, a Custom Element is just as easy to style as any native element. With CSS you can target the custom element and it's slotted descendants just like any built in element.
And within your Shadow DOM you can modify internal styles based on the state of the
:host.It's simple, elegant and effective.
As for your bullet about prop drilling, I was thinking that you could still make web components that use some sort of state management - just not a State Management library tied to a specific framework like Angular's NgRx. However, at that point you have undermined the portability promise. I suppose you could make plenty of reusable components not tied to such a library (like your own input component or color picker, etc), but if you're using web components to make pages, those would have to be tied to app logic and would not be reusable across other apps and even frameworks. Basically the primitive components would be reusable, but the app specific ones would not.
Point being, you could probably avoid using a framework and use popular patterns found in various frameworks such as dependency, injection, State Management, services, etc - but you would have to be careful to separate your portable web components from the project-specific ones.
Exactly, state management is a job for the app itself not the components it's built from. You don't expect a form field to manage it's own state beyond the specific features that it provides. You wrap extra logic around it to suit your specific use case then you wrap an app around that. Simple separation of concerns.
React is a state management library that happens to be able to supply dom elements (with react dom) I think you're more fight against bad react usage rather than react as a whole.
Actually, I would argue against any bad usage of web technologies regardless of the library or framework involved. The core Web APIs provide a finely-tuned, meticulously-documented, consensus-based framework without the need for any additional libraries.
Browsers are perfectly capable of maintaining state through Session Storage, Local Storage, IndexedDB, cookies, bfcache, and service workers (anything I missed?) each with their own specific use cases. And because of the open nature of the web you can NEVER trust the client anyway, so the one and only true state should be that held by the server itself. With Web Sockets this can be synced in real time to the client. I don't see why a third-party state management solution would ever be necessary.
100% you can use what ever you want to handle state but it raises the question what wins do the effort of using web components (as opposed to just straight up HTML) get you.
Custom Elements === HTML Elements
That is the true benefit. They are not opposed to straight up HTML they are a direct extension of it.
Actually, that is not entirely true. You can create custom elements through markup and css alone. They will not have any complex logic but JS is not technically required.
Then don't encapsulate your app logic. The point of components is to abstract and encapsulate the parts of your app that should be kept separate. You are building your app on top of the components—using them. Each component should only be responsible for it's specific behavior.
A properly designed app built from web components is actually less complex. The extra complexity generally associated with web components is almost always a byproduct of using them wrong.
But this is exactly the point of Shadow DOM. To encapsulate your styles away from the host page so that they don't get clobbered by page's CSS or that of another library or component. A properly designed custom element has only bare-bones structure and styling similar to that of a native element that can overridden by standard CSS.
I jest I truly didn't know how far creating components without JS had come but I still don't think it's good enough, I'd much rather just have raw HTML/CSS.
You could imagine having a component that loads in some data, having a loading state until the data is loaded, show the data and then allows you to modify the data again with a loading state as it saves.
This component doesn't need separating as it's all one concern, the form data (or whatever), but to make this work with web components I'd have to jump through some hoops, again not the end of the world but it feels like an extra layer of complexity.
OK, that feels like the answer of someone that doesn't have to work in teams of varying skill very often but perhaps it really is that simple 😊
A properly designed app built with CSS in mind doesn't need styles encap.... 😀
I personally use CSS modules to prevent clashes but I know that means a build step which you might want to avoid
I should probably say I'm not again web components and think everything has its place and every dev has their preferred way of working. For me the simplicity of react handling state and handling render based on that state allows me to work quicker without having to worry about all that. Sure there are foot gun and misuses of the platform but I'm sure that's true with all app building methodology.
Using Custom Elements in your project actually helps in a team of varying skill. Because someone with the knowledge to solve a particular problem can do so and share that with the team in the form of an easy to use component. The user of the component only needs to know basic HTML and CSS.
Encapsulation is important because not all apps are built in a homogeneous ecosystem. Polluting the global scope has long since been considered a bad practice in the JS world. Shadow DOM further enforces this and extends the ability to CSS to ensure that third-party libraries or even the work of your own team don't clash. Sure this can be mitigated with careful CSS scoping but you can never be guaranteed that your nicely designed widget won't break some day because of careless changes outside of your control. Why risk it when this problem can be completely avoided?
Web components solve a few of react's issues while introducing a lot of their own. However, any of those issues only arise if it matters in the context of your usage.
If your use case fits web components perfectly, congratulations! But what is great in your case might not work for everyone else (the same is true about frameworks, too).
React is overused because a lot of developers can use it, so HR can select from a larger pool and hires can more easily be replaced.
Indeed, and it's a self-perpetuating problem. Because after years of this behavior breaking out of the React ecosystem becomes a business crippling problem. Companies are heavily invested and locked into the React stack for existing implementations. Obviously I don't expect every existing React based app to be replaced. But any opportunity to get away from it should be seized and new projects started now should adhere to the standards. Doing so will eliminate this issue from future endeavors. It's simply a better business decision in the log run.
Of course Web Components alone are not a panacea. Switching to them will certainly require architectural changes. But most of those changes lead to simpler, more maintainable systems. There is nothing truly new or exotic about their use. They just extend the old ways to be more flexible. All the problems that will arise from ditching React have well accepted best practices for dealing with them. There is no need to re-invent the wheel. And adhering to standards does not mean avoiding frameworks, there are already players in this space and surely more to come.
There is lit, which fixes a few of TFW issues with WC. Whether the other issues become a show stopper depends on the use case. WC are certainly not a silver bullet.
I would like to see web components being used more for design systems, but I understand why most companies don't. They have a bunch of "x framework devs" employed, so it's just easier to do everything in "x framework".
Hopefully it'll get better now that React has support for web components 🥳
This is a really great point. Often I've seen people do hiring without even talking to the team about needed skills. "We're hiring a front-end developer". Nothing more specific, and entirely vague. Sure, if the project uses a specific framework, anyone can learn it, but there's a lot of ramp up time there, let alone learning the application logic itself. Sometimes someone with skill in only a different framework has been brought on board, and it was a nightmare as they tried to import all sorts of patterns and practices that didn't even make sense in the current framework. But frameworks aside, I like your idea about hiring people just to make custom web components - in the past I've even taken it a step further. I'm far better at programming than I am with design, and I'd be totally on board with a CSS wizard being hired, even if the person doesn't have strong programming skills.
But it seems that there's a disconnect between what skills a team needs, and project managers' desire to throw more developers at a project, regardless of skill set.
This is something that always bothered me. Non-technical policy makers controlling the technical landscape through anti-progressive decisions whether intentionally or not. One cannot measure a product's true worth by market share alone.
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...
As a developer that spends probably 75% of my time in react, I've found web components to be a breathe of fresh air. I've settled on a very simple in-house global state solution coupled with lit to be extremely powerful. That said, I've struggled with how to implement css libraries across components. Bundle sizes are a fraction of the size of react builds.
Sharing CSS across components is an advanced topic that I plan to cover in a future article. The simplest way is to just use a
<link rel="stylesheet">inside your ShadowDOM. But there are other techniques I will share that can be used to mitigate the need for this.Almost every React app could easily be replaced with AlpineJS or any micro state manager. Most people just don't know JavaScript, they simply learned React. No different than a "PHP Developer" who only knows Laravel or WordPress functions, but not how PHP actually establishes a DB connection. React is simply an "easy" to use framework that most frontend "developers" learned because they Googled "Best JS framework" and picked from Vue, React, or some Hipster 3rd option
You're absolutely right that Web Components have come a long way and deserve more attention than they get. That said, I think some developers still lean on React not out of habit, but because of the tooling, ecosystem, and community that come with it - especially in larger teams. Would love to see more examples or case studies showing how teams are using Web Components at scale today. Still, this is a good reminder to reconsider our defaults. Also, imagine if browser vendors took the lead on a native Web Components IDE with built-in tooling and integrations - that could speed up adoption even faster. Thanks for posting.
Here's an interesting example: Reddit. There is no literature on this but their UI is built from Custom Elements and in addition to this, their developer framework Devvit is inspired by React. So that is kind of a unique blend of these approaches.
I would be interested if you come across any actual case studies or even quiet examples where these tools are already powering the web right under our noses.
You just reminded me of Netscape Composer.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.