It’s disappointing that some of the most outspoken individuals against Web Components are framework maintainers. These individuals are, after all, in some of the best positions to provide valuable feedback. They have a lot of great ideas!
Alas, there’s little incentive for them because standards evolve independently and don’t necessarily align with framework opinions. How could they? Opinions are one of the things that make frameworks unique.
And therein lies the problem. If you’re convinced that your way is the best and only way, it’s natural to feel disenchanted when a decision is made that you don’t fully agree with.
This is my open response to Ryan Carniato’s post from yesterday called “Web Components Are Not the Future.”
WTF is a component anyway?
The word component is a loaded term, but I like to think of it in relation to interoperability. If I write a component in Framework A, I would like to be able to use it in Framework B, C, and D without having to rewrite it or include its entire framework.
I don’t think many will disagree with that objective.
We’re not there yet, but the road has been paved and instead of learning to drive on it, frameworks are building…different roads.
Ryan states:
If the sheer number of JavaScript frameworks is any indicator we are nowhere near reaching a consensus on how one should author components on the web. And even if we were a bit closer today we were nowhere near there a decade ago.
The thing is, we don’t need to agree on how to write components, we just need to agree on the underlying implementation, then you can use classes, hooks, or whatever flavor you want to create them.
Turns out, we have a very well-known, ubiquitous technology that we’ve chosen to do this with: HTML.
But it also can have a negative effect. If too many assumptions are made it becomes harder to explore alternative space because everything gravitates around the establishment. What is more established than a web standard that can never change?
If the concern is premature standardization, well, it’s a bit late for that. So let’s figure out how to get from where we are now to where we want to be. The solution isn’t to start over at the specification level, it’s to rethink how front end frameworks engage with current and emerging standards and work to improve them.
Respectfully, it’s time to stop complaining, move on, and fix the things folks perceive as suboptimal.
The definition of component
That said, we also need to realize that Web Components aren’t a 1:1 replacement for framework components. They’re tangentially related things, and I think a lot of confusion stems from this. We should really fix the definition of component.
So the fundamental problem with Web Components is that they are built on Custom Elements. Elements !== Components. More specifically, Elements are a subset of Components. One could argue that every Element could be a Component but not all Components are Elements.
To be fair, I’ve never really liked the term “Web Components” because it competes with the concept of framework components, but that’s what caught on and that's what most people are familiar with these days.
Alas, there is a very important distinction here. Sure, a button and a text field can be components, but there are other types. For example, many frameworks support a concept of renderless components that exist in your code, but not in the final HTML. You can’t do that with Web Components, because every custom element results in an actual DOM element. (FWIW I don’t think this is a bad thing — but I digress…)
As to why Web components don’t do all the things framework components do, that’s because they’re a lower level implementation of an interoperable element. They’re not trying to do everything framework components do. That’s what frameworks are for.
It’s ok to be shiny
In fact, this is where frameworks excel. They let you go above and beyond what the platform can do on its own. I fully support this trial-and-error way of doing things.
After all, it’s fun to explore new ideas and live on the bleeding edge. We got a lot of cool stuff from doing that. We got document.querySelector() from jQuery. CSS Custom Properties were inspired by Sass. Tagged template literals were inspired by JSX. Soon we’re getting signals from Preact.
And from all the component-based frameworks that came before them, we got Web Components: custom HTML elements that can be authored in many different ways (because we know people like choices) and are fully interoperable (if frameworks and metaframeworks would continue to move towards the standard instead of protecting their own).
Frameworks are a testbed for new ideas that may or may not work out. We all need to be OK with that. Even framework authors. Especially framework authors. More importantly, we all need to stop being salty when our way isn’t what makes it into the browser.
There will always be a better way to do something, but none of us have the foresight to know what a perfect solution looks like right now. Hindsight is 20/20. As humans, we’re constantly striving to make things better. We’re really good at it, by the way. But we must have the discipline to reach various checkpoints to pause, reflect, and gather feedback before continuing.
Even the cheapest cars on the road today will outperform the Model T in every way. I’m sure Ford could have made the original Model T way better if they had spent another decade working on it, but do you know what made the next version even better than 10 more years? The feedback they got from actual users who bought them, sat in them, and drove them around on actual roads.
Web Standards offer a promise of stability and we need to move forward to improve them together. Using one’s influence to rally users against the very platform you’ve built your success on is damaging to both the platform and the community.
We need these incredible minds to be less divisive and more collaborative.
The right direction
Imagine if we applied the same arguments against HTML early on. What if we never standardized it at all? Would the Web be a better place if every site required a specific browser? (Narrator: it wasn't.) Would it be better if every site was Flash or a Java applet? (Remember Silverlight? lol)
Sure, there are often better alternatives for every use case, but we have to pick something that works for the majority, then we can iterate on it. Web Components are a huge step in the direction of standardization and we should all be excited about that.
But the Web Component implementation isn’t compatible with existing frameworks, and therein lies an existential problem.
Web Components are a threat to the peaceful, proprietary way of life for frameworks that have amassed millions of users — the majority of web developers. Because opinions vary so wildly, when a new standard emerges frameworks can’t often adapt to them without breaking changes. And breaking changes can be detrimental to a user base.
Have you spotted the issue? You can’t possibly champion Web Standards when you’ve built a non-standard thing that will break if you align with the emerging standard. It’s easier to oppose the threat than to adapt to it.
And of course Web Components don’t do everything a framework does. How can the platform possibly add all the features every framework added last week? That would be absolutely reckless.
And no, the platform doesn’t move as fast as your framework and that’s sometimes painful. But it’s by design. This process is what gives us APIs that continue to work for decades.
As users, we need to get over this hurdle and start thinking about how frameworks can adapt to current standards and how to evolve them as new ones emerge. Let’s identify shortcomings in the spec and work together to improve the ecosystem instead of arguing about who’s shit smells worse.
Reinventing the wheel isn’t the answer. Lock-in isn’t the answer.
This is why I believe that the next generation of frameworks will converge on custom elements as an interoperable component model, enhance that model by sprinkling in awesome features of their own, and focus more on flavors (class-based, functional, signals, etc.) and higher level functionality. As for today's frameworks? How they adapt will determine how relevant they remain.
Living dangerously
Ryan concludes:
So in a sense there are nothing wrong with Web Components as they are only able to be what they are. It's the promise that they are something that they aren't which is so dangerous. The way their existence warps everything around them that puts the whole web at risk. It's a price everyone has to pay.
So Web Components aren’t the specific vision you had for components. That's fine. But that's how it is.
They're not Solid components. They’re not React components. They’re not Svelte components. They’re not Vue components. They’re standards-based Web Components that work in all of the above. And they could work even better in all of the above if all of the above were interested in advancing the platform instead of locking users in.
I’m not a conspiracy theorist, but I find interesting the number of people who are and have been sponsored and/or hired by for-profit companies whose platforms rely heavily on said frameworks. Do you think it’s in their best interest to follow Web Standards if that means making their service less relevant and less lucrative? Of course not.
If you’ve built an empire on top of something, there’s absolutely zero incentive to tear it down for the betterment of humanity. That’s not how capitalism works. It’s far more profitable to lock users in and keep them paying. But you know what…?
Web Standards don't give a fuck about monetization.
Longevity supersedes ingenuity
The last thing I’d like to talk about is this line here.
Web Components possibly pose the biggest risk to the future of the web that I can see.
Of course, this is from the perspective of a framework author, not from the people actually shipping and maintaining software built using these frameworks. And the people actually shipping software are the majority, but that’s not prestigious so they rarely get the high follower counts.
The people actually shipping software are tired of framework churn. They're tired of shit they wrote last month being outdated already. They want stability. They want to know that the stuff they build today will work tomorrow.
As history has proven, no framework can promise that.
You know what framework I want to use? I want a framework that aligns with the platform, not one that replaces it. I want a framework that values incremental innovation over user lock-in. I want a framework that says it's OK to break things if it means making the Web a better place for everyone. Yes, that comes at a cost, but almost every good investment does, and I would argue that cost will be less expensive than learning a new framework and rebuilding buttons for the umpteenth time.
The Web platform may not be perfect, but it continuously gets better. I don’t think frameworks are bad but, as a community, we need to recognize that a fundamental piece of the platform has changed and it's time to embrace the interoperable component model that Web Component APIs have given us…even if that means breaking things to get there.
The component war is over.
Top comments (5)
My cheeky response was going to be I agree with the title.
You might be interested to read an article I wrote 6 years ago about some work I started 11 years ago. ryansolid.medium.com/b-y-o-f-part-....
So much of this response focuses on motives and maybe that is why the communication misses. Instead of viewing framework authors as some sort of villains, view them as disillusioned churned customers. They are your early adopters. They aren't the ones who never tried but the ones who tried too hard, kept up hope past what made sense and finally had to conclude they weren't doing it for them. And ultimately outgrew them.
Why would you think an author of a less popular framework want lock in? It's illogical on the surface. How can one gain adoption against more popular "locked in" options? But some things are like that. Writing DRY code appears logical until one realizes that is often an oversimplification and sometimes DRY is not very good at all.
Monetization isn't my motivation either. It's why my article probably struck a nerve with some people, because those who know, know it comes from how much I care. It opens up the possibility that atleast some of it could have merit.
For all the quotes you grabbed the one I most hoped would come across is:
If we can't readjust expectations then there is a problem. You say that I'm disappointed that web components don't fit my view for components. Fair. But then fall immediately into the trap I warn about.
And sadly nothing can promise that. Suggesting otherwise is the fundamental lie. This misguided belief is a large part of the danger. Because it sounds good but lacks nuance. Why I could write for pages on the subject.
As I said they don't fit my model not because they are something new that I need to adjust my thinking to. It's the contrary. To me they are something pretty old. Web Components are already very much here in the present. They were there before I ever wrote SolidJS. But I always have my outlook facing the future.
You put your finger in the right wound:
Finally, Web components are just a way to organize your code, and they live side by side with other approaches. They may be beneficial, but they bring their own level of complexity and some overhead to the development.
Does this pay back? Or does it confuse you to use different technologies side by side?
I think, it depends much on your style and the way you use WC. If you want to have some fancy buttons in your app, It is probably not relevant which technology you choose. But I feel, WC do not solve the big challenges you face with app development.
We've indeed deviate and have seen a lot of progress from the days of JQuery where we have majorly one way of building the web. I've always wondered how we can go back to write once run everywhere in the web, while Web Components needs to get better, I think more than any suggested solution, they look like the best approach for the present by which we can build the next solution for the standardization of the web.
Signals from Preact? lol
Nah, that's sounds like a conspiracy theory to me. How does following web standards make a product less relevant?
Not wrong but Preact was influenced by SolidJS to adopt signals primitive.