Web Components were supposed to be the future of web development. Browser-native custom elements, shadow DOM for encapsulation, and HTML templates for reusability. No frameworks needed—just standards-based components that work everywhere. It hasn’t turned out that way.

The core technologies are fully standardized and supported across all major browsers. Custom Elements, Shadow DOM, and HTML templates work in Chrome, Firefox, Safari, and Edge. The technical foundation is solid. Yet Web Components remain niche compared to framework-based component systems like React, Vue, or Svelte.

Developer experience is a major factor. Creating a Web Component requires more boilerplate than creating a React component. You’re working directly with DOM APIs rather than through a framework’s abstraction layer. For simple components, this is manageable. For complex stateful components, it gets tedious fast.

State management is particularly clunky. Frameworks provide elegant ways to handle component state, props, and reactive updates. Web Components require you to implement these patterns yourself using vanilla JavaScript. You can build sophisticated state management, but you’re essentially recreating what frameworks provide out of the box.

The styling story is complicated. Shadow DOM provides style encapsulation, which is good for preventing style conflicts. But it makes global styling harder and creates friction with design systems. If you want your Web Components to inherit styles from the parent page in some ways but not others, you end up with complex CSS custom property cascades.

Framework integration is better than it used to be but still not seamless. React had issues with custom events and properties that have been mostly resolved. Vue and Angular play more nicely with Web Components. But there’s still impedance mismatch when mixing Web Components with framework components.

If you’re already using React throughout your application, the value proposition of switching some components to Web Components is unclear. You gain framework independence but lose the tight integration with React’s ecosystem. For most teams, that’s not a worthwhile trade.

The promise of framework-agnostic components matters most when you’re sharing components across multiple applications with different frameworks. In practice, most organizations standardize on one framework for their web applications. The interoperability benefit doesn’t matter if you’re not actually using multiple frameworks.

Tooling has been a persistent problem. Frameworks come with mature build tools, dev servers, testing utilities, and debugging extensions. Web Components tooling exists but it’s more fragmented. You can use Lit or other libraries that improve the development experience, but then you’re not really using pure Web Components anymore—you’re using a library that generates Web Components.

This points to a deeper issue: Web Components are a low-level primitive, not a complete development solution. They provide the building blocks for component systems, but you still need conventions for state management, event handling, async operations, and all the other concerns that frameworks address.

The JavaScript community generally prefers higher-level abstractions. Web Components ask developers to work closer to the metal, which appeals to some but feels like a step backward to developers accustomed to framework ergonomics.

Performance is sometimes cited as a Web Component advantage because there’s no framework overhead. In practice, this advantage is small for most applications. Modern frameworks are highly optimized, and the performance difference between a well-written framework component and a Web Component is usually negligible for typical use cases.

Server-side rendering was initially difficult with Web Components because they rely on JavaScript running in the browser. Declarative Shadow DOM has addressed some of this, but SSR with Web Components is still less mature than with frameworks that were designed with SSR in mind from the start.

This matters for SEO, initial load performance, and progressive enhancement. Frameworks have sophisticated SSR solutions. Web Components are catching up, but they’re behind.

The ecosystem effect is powerful. React has a massive ecosystem of libraries, UI component libraries, tutorials, Stack Overflow answers, and developers who know it. Web Components have a much smaller ecosystem. When you choose a technology, you’re choosing an ecosystem, not just a technical capability.

This creates a self-reinforcing cycle. Fewer developers learn Web Components because fewer jobs require them. Fewer companies use Web Components because fewer developers know them. The ecosystem stays small, which perpetuates the cycle.

Big framework migrations are hard, which makes Web Components more attractive in theory. If you could build components that survive framework changes, you wouldn’t need to rewrite everything when you switch from React to the next popular framework. But framework migrations are rare enough that preparing for them by using Web Components seems like premature optimization for most teams.

Design systems are one area where Web Components have found success. If you’re a large organization with multiple web properties using different frameworks, creating a shared component library as Web Components makes sense. You build once, use everywhere, regardless of each application’s framework choice.

Companies like Adobe, ING, and Salesforce have built design systems with Web Components for exactly this reason. It’s a real use case, but it’s not the typical developer’s situation.

The Web Components specification itself is relatively stable, which is good for longevity but means less innovation at the platform level. Frameworks iterate rapidly, adding new features and patterns. Web Components get incremental improvements but nothing revolutionary.

Scoped CSS, better lifecycle hooks, and improved event handling would help Web Components compete better with frameworks. Some of these are being worked on through various proposals, but standards move slowly compared to framework innovation.

Lit, by Google, is probably the most successful Web Components library. It adds a better templating system, reactive properties, and improved developer experience while still generating standards-compliant Web Components. It demonstrates what Web Components need to be ergonomic, which ironically shows why pure Web Components struggle.

If the best Web Components development experience comes from using a library that abstracts the underlying APIs, are you really using Web Components, or are you using a lightweight framework? The line gets blurry.

Developer sentiment matters. Web Components don’t generate the enthusiasm that new frameworks do. There’s no equivalent to React’s hooks announcement or Svelte’s reactivity model that got developers excited about Web Components recently. The technology feels mature and stable, which can read as stagnant.

Framework fatigue hasn’t driven people to Web Components the way some predicted. Developers tired of framework churn often stick with mature frameworks like React rather than dropping down to Web Components. The grass isn’t always greener at the standards level.

For certain use cases, Web Components are excellent. Embedding third-party widgets, creating shareable UI components for distribution, building design systems for multi-framework environments. These niches value framework independence and are willing to accept the development experience trade-offs.

For typical application development, frameworks continue to win. The productivity benefits, ecosystem richness, and mature tooling outweigh the theoretical purity of standards-based components.

The future might involve more hybrid approaches. Frameworks that compile to Web Components, or applications that use frameworks for application structure but Web Components for certain shared components. The boundaries don’t have to be absolute.

What seems unlikely is Web Components replacing frameworks as the dominant way to build web applications. The standardization happened, the browser support is there, but the developer experience gap remains. Until Web Components can match framework productivity without requiring extensive abstraction libraries, they’ll remain a tool for specific situations rather than the default choice.

The lesson might be that standardization isn’t sufficient for technology adoption. You also need compelling developer experience, robust tooling, and a thriving ecosystem. Web Components have the standards part, but frameworks still lead in everything else. That’s why adoption stalled despite successful standardization.