I am aware of the opinions of framework creators on this subject and I have not seen a single argument that has swayed my own opinion. Nothing about Web Components precludes you from using a framework. The choice to use one is completely a matter of preference and suitability for the current project. Most examples of "why Web Components are bad" usually boil down to not using them to their full potential or using them to solve problems they were never intended to solve.

I don't get your point about declarative vs imperative. As I mentioned in the article, Custom Elements can be used completely declaratively. Furthermore, there is nothing imperative about their use at all. They are not required in any way but are simply a tool to make Web Development easier.

The real problem I was trying to point out is that companies treat React as imperative. Like nothing else could do the job. Which is simply not true. The same kind of sentiments existed about jQuery. It was almost impossible to convince an execubot that a web app could be built without it, even though plenty of developers did so every day. And look how that went in the long run.

We must look to the past to design the future. And the past has shown us the same patterns over and over again. It would be crazy to dismiss this knowledge. The Web Components standard wasn't haphazardly designed. It was carefully forged to provide maximum benefit with minimal disruption. No one is forcing you or anyone to change their habits, but true growth requires stepping out of your comfort zone to explore alternatives.

Ryan creates Solid, Rich creates Svelte

All Cool-Framework-Authors dislike what the WHATWG (Apple, Google, Microsoft, Mozilla) comes up with.

It is not general consensus that declarative is better than imperative. At best, you have a vocal subset that FEEL that declarative is better than imperative. That nuanced distinction is why there are always escape hatches in any of the "declarative" frameworks. At some point you have to stop describing the work and actually DO the work. That's either in YOUR code, or it's in the framework code, and often times it's strewn throughout both.

React started by Declaring the UI given your state. Today it's more common to Declare your data management given your actions (UI being a derivative of both with cross cutting concerns)

Frameworks implement some functionality meant to set up a particular mental model, ease some tasks, and produce things of value. They do this at the cost of overhead, abstraction, and impedance mismatch when you need to do something that doesn't neatly fit into the provided abstractions.

React in particular has a history of slowing teams down compared to using native JS and HTML. I die a little inside every time I see a basic crud application loading a large js-bundle just to have to reimplement the browser's navigation on order to avoid a page load. The performance ends up measurably worse and business logic leaks into the frontend. I've made a reputation for coming into projects that are wildly off track in terms of time and budget, and getting them back on schedule by ditching react and having the team reimplement the UI from scratch in a basic server-side rendered library. I've done it several times and every time it has resulted in significant time savings and simpler implementations. KISS applies to the WHOLE stack

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?

Thank you for sharing your experience! This is the kind of thing I want to draw attention to.

Hiring becomes hard because there are just a bunch of react developers and not JavaScript developers.

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.

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 div or input right now.

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.

Yes! I have been using web components in production since 2017. Many of those projects still hold up today. And as the platform stabilized, the need for polyfills faded away. Because I had planned for the future, simply removing the supporting libraries was usually all that was necessary to modernize these projects, aside from the occasional update to improve them based on new features or better techniques that I learned over the years.

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.

If we started using this kind of reasoning in 4000 bc, we'd still be using sticks and stones to solve every problem...

Right now, React solves many problems, but the past few years a lot has changed in webdev, as a result, React has also changed. There will be a point where it can no longer keep up with other more modern tools to fix problems and eventually it will become obsolete.

I know people who had that mentality about jQuery, who when realizing it was actually obsolete, moved on from software development to project management. I'm not saying anyone should stop using React today (I make heavy use of Angular, so this conversation is making me nervous and realizing I have yet another thing to learn), but just as has already happened earlier in my career, I realize that the tools I use today may need to be replaced - and that's either with other tools or actually something more foundational like web components.

It's not about jumping to another tool. It's about stepping down from the illusion of safety on the island of React into the raging river of the platform itself. The river keeps flowing whether you want it to or not. Pretty soon you won't even be able to see the ones riding the current from your position. Do you really want to be left behind?

To be frank, I never needed them at all. Ever. Not once in my career have I ever felt that any library or framework was essential to completing the job.

The entire point of web components is to reduce boilerplate. You solve a problem once and it is solved forever. You can then use that solution in any project. If you discover an issue or want to improve the component you do so once and, if you are loading your component library from CDN, all instances will be instantly updated.

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.

👎 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:

1. CSS properties
2. constructed stylesheets
3. ::part and exportparts

You still need JS to load the components

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.

Encapsulation of app logic is a nono

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.

leading to more complex pages

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.

With the shadow dom you can't, easily, style from outside

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.

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.

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.

The web platform is universal. It can run on basically any device with no compilation or abstractions (other than an available browser). It is far easier to embed a webview into a basic mobile app template. And the core Web APIs have gotten much more advanced lately. You can access hardware devices and do many of the things that native apps can do directly. And for features that are not available there is always WASM compiled native code as an option.

Make Web Components, not War

Everything we need to build robust, modern apps without heavy abstractions

You make an excellent point. I have changed to wording of the article to "modern components".

While Web Components are powerful, they don’t provide built-in state management

Correct. Browsers have other APIs to handle this. My views on state management are available in another comment below.

It’s sometimes rough for a junior or someone new to development to step outside of react

This is not a valid excuse in this age of AI assisted programming. We senior devs learned the hard way. All these juniors need to do is ask a bot for help and their questions will be answered. Mind you, the assistants tend to have outdated information regarding web standards and much has stabilized in the last couple years. I have given this feedback to the Copilot team already. I'm sure this will be addressed in due time. Regardless, they still hold enough information to get started. The core Web Components API has been stable and widely available for years.

Most real-world apps do use build steps e.g. TypeScript

I get the benefits of type safety from a shared codebase standpoint but JS benefits more from runtime validation that strict typing at the source. The use of TypeScript is purely a team/project decision and in no way affects the overall structure of a Web Components based approach.

you’d need to build/integrate a lot of additional tooling

I'm not saying that we should all throw away our favorite frameworks or build processes. All I'm trying to point out is that we have the ability to create amazing new toolkits around modern standards-based methods instead of sticking to aging third-party vendor alternatives.

Some of the issues we face today actual come from these supposed front-end frameworks taking up too much responsibility for things that should be handled on the back-end. Like routing as you mentioned yourself. I'll admit that when Single Page Applications first became popular I jumped right in full force but over the years I have since re-learned the lessons of the past and now prefer a hybrid approach.

Here's an example of a declarative framework that I built using this methodology. It is composed entirely of static html with custom elements served through an extremely simple (3kb) index.php templating engine. With bfcache this feels just as fluid as any SPA with none of the drawbacks. Any back-end could just as easily be subbed in because absolutely nothing in the stack is locked to any specific vendor. An equivalent Express router would be trivial to implement and migrate to. The entire structure is just a flat filesystem of valid HTML and associated assets. With a few minor modifications, the whole site could even be served statically.

While this may not be the most amazing or versatile web application ever built, it is lean, clean and blazing fast. Also, I have not touched this code in 4 years. The type of components featured there have been possible to build for at least that long, yet we are still having this discussion about what this technology can do today.

I mean, I never needed them. I've been writing JS since 1995 and not once did I ever actively choose to use one of these tools. I was stuck working with them on jobs where they were implemented but not one single personal project or one where I chose the stack ever used them.

Would love to see more examples or case studies showing how teams are using Web Components at scale today.

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.

imagine if browser vendors took the lead on a native Web Components IDE

You just reminded me of Netscape Composer.

Many would argue that React is a library and not a framework. Some others would even argue that the Web APIs are a framework in and of themselves. JS can certainly be run in other environments besides the web with no access to these features. Whether it's apples-to-apples or not, React Components and Web Components are still directly comparable enough.

Static HTML can be used for so much more than just serving simple content that doesn't change. For the majority of my projects I use a component ↭ socket ↭ service model to build realtime apps using statically hosted assets. With this technique it is even possible to serve an app UI entirely from CDN. Add a Service Worker cache in between and now you have an app capable of working fully offline. Completely modular. Zero frameworks involved.

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.

OP simply hasn’t done any work with web components

Except for the numerous examples which I have provided in the comments. And those are only a sampling of components which I have published for demonstration purposes out of many more that I have built since Shadow DOM v1 was first introduced.

this blog really lack of pragmatic points

Obviously the article was intentionally sensational to spark discussion. If you are looking for pragmatic points, read through the comments.

I have my own component library but this definitely looks like a nice, minimal abstraction layer. Very similar to Lit. Out of all the libraries I have seen, these two are the closest to native. Thanks for sharing! I'm sure someone here will find this useful.

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!

let's agree that writing codes in declarative way is much better

I agree. As a component creator I aim to design interfaces that can easily be used in a declarative way. Both for my own benefit and for anyone maintaining my work later.

STOP it's too much abstractions

I do not agree. Abstractions are good. All code is abstraction. Web Components are great because you only ever need to solve a problem once. Then you can re-use that component any time you need it.

The content becomes decoupled from it's components. You describe the parts of the page in pure HTML and implement the logic in an abstracted way. If you want to populate the content server-side, that's no problem. If you want to change the behavior, all the code is encapsulated into modules. You can drop a component into a simple test page with no framework or build steps required to work on it.

everyday we see a new libraries doing magical things in the front stack, for example form validation, scroll behavior, even library for pagination

You still need back-end validation but additional front-end form validation makes for a better user experience, especially when added to a custom form field.

Modifying scroll behavior is certainly not something you would want to do on a typical informational website but it can create a much more immersive app-like experience. Check out the source of that page to see how abstracting this behavior can be done in a clean and elegant way.

Pagination is actually a unique scenario. It's definitely easier to implement server-side, but you could absolutely package the behavior into a re-usable component. Something like this:

<paged-content page="1" lastpage="10">
  <article> ... </article>
  <article> ... </article>
  <article> ... </article>
</paged-content>

In this example, you would populate the initial content and attributes in a server-side render. The page navigation would be part of the Shadow DOM just like how a <video> element adds it's own controls that are not part of your markup. This would allow you to declare your content and the component handles the heavy lifting. If you ever want to improve or even replace your component, it becomes a simple drop-in, plug-and-play change that automatically affects all instances.

I mentioned Lit in another reply. For me it's an an abstraction layer that I don't need, but it definitely would be a good place to take your first steps into the world of Custom Elements if you're coming from React. You'll find similar syntax and concepts as well as excellent tutorials.

There's also a solid library of components called Shoelace that's based on Lit which you can load via CDN. This would give you a good set of starter elements to work with if you don't feel like building your own toolkit from scratch.

I am really hoping to change that. I've been pitching a series of articles entitled Mastering Web Components to try and get paid for creating this content. If anyone reading this would like to discuss sponsoring this endeavor please contact me.

You're welcome!

This is a misleading comment because not once did I ever say that Web Components alone are a magic bullet or that frameworks add no value to a stack. I have also addressed all of these points in other replies.

If you read the entire discussion you will see that this post was just a precursor to a series of articles intended to debunk misinformation and misunderstanding on this subject with history, statistics, facts and tutorials.

Yes, Safari refused to implement is=, but browser vendors have agreed to work together to come up with an alternative. Meanwhile, that attribute was never necessary, customizing built in elements can be done by extending their classes.

class MyButton extends HTMLButtonElement {}
customElements.define('my-button', MyButton)

And sure you can use Web Components with React. But why add the extra complexity? There are much lighter alternatives as have been pointed out in these comment numerous times.