This article is not meant to give you a complete guide or a final answer about Web Components (WCs) future or present. Instead, think of it as a notebook. I’m collecting assumptions, doubts, and random thoughts I’ve had while reading and experimenting with them.
Some of these points come from articles I’ve read, others from my own experience & perspective. Sometimes they might even contradict each other. That’s fine, the goal isn’t to settle the debate, but to explore the space.
So if you came here expecting a “how-to” or a solid argument for or against Web Components, this isn’t it. What you’ll find here is more like a list of questions, half-formed opinions, and little sparks that might point to further discussion.
Future or Flop?
If you search for “Web Components future,” you’ll quickly find articles and posts that completely disagree with each other. Some are titled “Web Components Are the Future”, others just as confidently say “Web Components Are Not the Future”, & others as "Web Components are Dead: Long Live Web Components." There are even posts trying to find middle ground like “Web Components Are Not the Future — They're the Present”.
This split isn't just about technical details, it's about how people feel. On Reddit, someone summed it up perfectly with this line:
Comment
byu/treedor from discussion
inwebdev
That kind of sarcasm shows how tired some developers are of hearing promises that don’t quite match their daily reality.
And this isn’t new. More than a decade ago, someone on r/webdev complained:
they just keep telling everybody, ‘this is the future of the web, it’s gonna fix everything’.
Comment
byu/shadowdomdeloise from discussion
inwebdev
So clearly, the phrase “Web Components are the future” has been floating around for a long time. But saying that might not really make sense anymore. Maybe it’s better to stop repeating the slogan and instead look at what they actually do well, and where they still fall short! That’s what I’ll try to do.
The Rise of Web Components?
Early Days and First Libraries/Technologies
When talking about Web Components, it helps to step back and look at where they came from. According to Wikipedia, the first introduction of the idea was around 2011, and the W3C published an early draft in 2012 describing them as a standard way to build reusable custom HTML elements. That’s over a decade ago, which makes them not exactly “new,” but also not “old” in the sense of technologies that have been widely adopted for 20+ years. At that point, Web Components were more of a concept than a practical tool most developers could use.
Things started moving in 2015 when Google released Polymer, the first major library aimed at making Web Components easier to use. Polymer helped push adoption, even though it went through different stages and eventually gave way to LitElement (or just Lit today), which is now the recommended successor. Depending on which source you check, Polymer’s first stable release is listed as either 2016 or 2019, but either way, it was the first time Web Components really started to gather a community.
Another important milestone was Stencil.js, introduced by the Ionic team around 2017 as “a Web Components compiler.” Unlike Polymer/Lit, which provide utilities to build components directly, Stencil compiles your code down to Web Components. This opened another path for developers, especially those coming from a framework-heavy world.
Adoption and Growth
To get a sense of whether the community has been growing, we can look at npm download stats for Lit and Stencil. It’s not a perfect measure of Web Component adoption, but since most developers don’t use raw APIs directly, the libraries can be a good proxy.
The numbers tell an interesting story. Back in early 2021, Lit barely had any traction, while Stencil was already seeing around 36k weekly downloads. By early 2022, Stencil had grown to 212k per week, while Lit was catching up at 21k. The real shift came later: in early 2023 Lit had overtaken Stencil (516k vs 355k), and by early 2024 it had exploded past 1.4 million per week. As of September 2025, Lit sits at roughly 3.4 million weekly downloads, while Stencil has climbed steadily to around 800k.
What this shows is not just competition between two libraries, but that the ecosystem as a whole has been growing. The numbers are going up year after year, and especially in the last 8 months Lit has jumped by more than a million weekly downloads. That’s a clear signal that interest in Web Components has been accelerating, even if the growth is uneven across different tools.
My Journey with Web Components
I started reading and learning about Web Components in beginning of 2024. The idea was amazing for me, build a component once (a custom element) and reuse it everywhere. If I am building a WordPress monolithic theme, I can use them. If I am using React, I can use them. Next, Vue, or even just HTML + vanilla JS, all can use them. That looked like a big deal.
But then I was confused: if this is such a great idea, why isn’t it more popular or well known? At that stage I was really hesitating. That hesitation stayed with me for a while. Was I investing in something useful, or just wasting time on a technology that never really took off?
Finally I decided to continue, and I picked Stencil.js as the main tool. The reason was just that it feels closer to React which I already know. I did also try Lit, but in the end I chose Stencil. My learning process was tied to a master’s thesis project on “Component-Driven Approach to Enhance Reusability and Testability in Frontend Web Applications.” Over a year, I went through three different iterations of a component library:
- First attempt: very simple, lots of issues, bad performance, and I was struggling with both the WC specs (Custom Elements, Shadow DOM) and also with Stencil itself.
- Second attempt: a bit better but still not ready for real use.
- Third attempt: attempt ready and stable. This was the one we used for actual metrics and results in the thesis.
From this experience, here are the main points I faced (again, this is mostly with Stencil, maybe others have different story):
1. Learning curve
Even if you use a technology to build WCs, it doesn’t suddenly become easy like building plain components with a JS framework. For example, in React if I want to build a component library (not a whole project), I find it simpler because of hooks (hooks reflect the modern React lifecycle with functions instead of the old class methods).
In Stencil, they also provide a good public API for state management, props, events, etc., and the WCs lifecycle callbacks but "for me" it was not as easy as learning React.
2. Development
Trying to create components that will run in many environments feels nice in theory, but in practice it is heavy. For a company with design system and many projects it can save time. For a small team or just one developer it looks like waste of time. Updating and publishing components for different projects is not comfortable.
Imagine you build a component, then later you discover it doesn’t really fit the use in one project. You then need to go back, update the component, republish it, and update it again in the project. Honestly, this process is not comfortable.
3. Performance
Something I did not expect: rendering perf. In my tests, React components were faster than Stencil components. I don’t think native Web Components are slower by definition, so maybe it was my code or Stencil itself, but anyway the result was not good surprise.
4. Integration & reusability
This was the hardest. When I tried to use my library in a React project, the components didn’t behave same as in Storybook while developing. There were differences, especially related to Shadow DOM and slots. The biggest issue though was SSR integration. At that time, SSR just wasn’t supported properly. From what I’ve seen, support is improving with newer releases in 2025, but when I tested earlier it was a big blocker.
So overall, these things made me step back a bit from Web Components. I don’t think I am the only one who had these struggles, however, I still want to work with WCs, but I won’t give them my full focus. They’re valuable, but they come with trade-offs that are too big to ignore for now.
