A few years ago I wrote an article suggesting that Web Components might not be the most beneficial direction for Web development to head.
...
For further actions, you may consider blocking this person and/or reporting abuse
Hmmm... I'm not convinced. I think you're trying to make web components more than what they are - custom elements with sandboxed styles and some js logic to them.
I, for one, thinks that the frameworks might not be the future. The sentiment I get more and more is that frontend is in a complete mess because of frameworks and the overwhelming abstraction, keeping us away from web standards. Web standards which are closing the gap and offer native solutions to challenges framework came to solve.
I say it is time to consider going back to square one.
He doesn't, but other people do, and that this can become a problem is the point of this whole article.
On the contrary, it seems that a lot of frameworks seem to converge on the same pattern of state signals effecting DOM changes through composable components.
And here you're making the same mistake that becomes a problem. Web components are an abstraction that can be used for such solutions, but they are not a solution in itself. Also, their previous design decisions now become a burden to development in other directions.
Frameworks are always the future because people will always build abstractions on top of what they have to make their lives easier.
You don't get to claim I'm making them out to be more than they are and then claim they are a native solution to challenges frameworks came to solve. That is trying to make them more than what they are.
More accurately I'm saying they aren't more than what they are and they don't solve what frameworks set out to. If anything they are more of a hindrance. Which is why when going back to square one I'd consider if they have any worth at all. Many frameworks were on board early days. As I said they were why I created Solid.
But in hindsight I better understand the degree I was mistaken. I grew from seeing them as a useful tool to something unnecessary. But now I think them detrimental to the web on average. We already built frameworks in a world Web Components were the future. I wish I could turn back the clock and try again in a world they were not.
In what ways? The whole point of this article was that web components are not solving the same problems frameworks are, so is there any other standard you are referring to which is closing the gap?
“If anything with compilers and advancements in build tools, we are moving more in the direction away from components being anything more than a Developer Experience consideration.”
If component obsession is the core issue then it doesn't matter if it's part of a framework or a web standard.
It depends™, but web components are a blessing when building any kind of universal UI that should be used across frameworks, vanilla JS, whatever. Personally, I don't like the native custom elements API (or API family, realistically). And, I'm really happy that things like solid-element exist since I get to compile down from a DX I like to something I can use across the board. Does it always translate well? No. Not by a longshot. Does it matter? I don't think so (again, depending on what you're building). It comes with a bunch of tradeoffs - type declarations are awkward, imports are awkward... But it works.
Here's a practical scenario: supertokens.com, in general, has two ways of integrating with anything—our pre-built UI (currently in React, with a compiled universal version) or DIY (just use the SDK). We'd like to support everything out there, and some users like having a set of pre-made components to just drop in and call it a day. So, we're faced with a choice - either try to support every framework under the sun in their native "language" (which requires an army of engineers), or go for something like web components. I think that for those use cases, it's an easy compromise to make. There are other, IMO, very valid uses of web components -shoelace.style comes to mind.
But! I don't think frameworks should standardize on web components (in any sense). Provide a way to use them, sure. The less awkward the better. Each should ideally also have a path to produce them if needed (as Solid does, for example). As much as I love standards, Web Components aren't the silver bullet some of us hoped them to be.
Excellent read, thanks :)
Thank you for your response. A lot of this sprung from my realization just how much of a cost supporting Web Components properly has had on the library. And how it is basically endless. We doubled the size and complexity of our event delegation code in the last release (1.9) just to handle Shadow DOM better and it still falls flat for many cases because of how Shadow DOM is designed. It's not within our means to fix, but when we say we support Web Components people come to expect it. I could delete pages of code if I didn't care to support Web Components I could simplify many things.
Instead we are here. I can just picture when the push for SSR web components becomes a thing at the detriment of performance/code complexity there. Are there no limits to pushing something which brings us no direct benefits and pushes the cost on to all our users?
Great post
I use web components more as a progressive enhancement, usually. I steer clear of the shadow DOM completely. What I would prefer is a
traitsattribute that I could put on an element to enhance that element.So, if I had a
dialogelement I could addtraits="x-modal"that would make it so once I add thedialogelement to the page it would be treated as a modal without me actually having to callshowModal()on the element.Or maybe something like
<select multiple traits="fancy-select">that would turn myselectinto a fancyselectelement that you could see above it all the items you've chosen and could x them out easily in a more UI friendly manner.What is annoying about frameworks is that you have all these cool libraries that are locked behind the frameworks themselves, but can't use if you want to use a different framework or no framework at all.
Also, with frameworks, especially ones like React, they don't play nicely if you want to outside the box. Maybe I would part of the page to work with HTMX. Well, that will be pretty tough to do with React (I've tried it).
So, that's typically how I use web components. I use them to progressively enhance my page with an HTMX-like framework. It works pretty nicely. Now, if you have a page that requires to have a lot of local state and changes I'm all for frameworks and I will not likely reach for web components. But most of my pages are pretty simple and I try to keep them that way.
Granted, recently I did build a little app with just web components that could also use a framework (the framework came in with 150 lines less than the web component solution - I just like the control).
Yeah there is "is" for native element extension, but I get "traits" would be more powerful. That all being said I agree that would have been less obtrusive. Doesn't handle all the cases WCs envision though. Slotting and handling of DOM children is a difficult problem so I get why the Shadow DOM exists even if it is the source of a lot of the problems.
I think it is ok React wants to control its area of the page. It gives it incredible power there that otherwise would be very difficult to accomplish. Not every one needs that power but the boundary is clear and thus swappable.
I can get why an HTML interface with something like HTMX is desirable. It is less visual overhead than adding an id to a div and running a small script. No argument with the ergonomics. Just the impact it has had on the rest of the platform has been significant and that concerns me.
Now replace "Web Components" with "Microservices".
Wait a minute...
So because Web Components are a standard, I have to use them?
What's next? I have to use
proxiesandgenerator functionsin my applications?I totally disagree with your post. With hindsight I shouldn't have read it.
Sounds to me you are a disgruntled "My-Web-Component-wrapper-is-better" creator who sees Web Awesome coming at the horizon. And sees all his efforts wasted.
And no, I have no stock in Web Awesome; been doing standard JavaScript Web Components for the past 7 years, without any 3rd part s*, almost full-time.
You don't have use them, but generic tools now have to account for the edge case that come from them. How things like event delegation are handled, or async upgrade of webcomponents, or how attribute/properties need to be considered for elements that define their own interface. Or how their timing works different when cloned between cloneNode and importNode. Or a million other little details.
You don't have to use them but any tool now has to consider them if they want to support the whole web platform which means extra complexity, code, and runtime overhead for everyone.
Not to mention how their very existence influences how newer features are approached. They now need to work with Custom Elements and the other web component specs.
The cost of decisions that extend the capabilities of a platform go beyond isolation of a single feature or featureset. That's the thing more people should recognize.
From the looks of it, you're the disgruntled one
O yes, I am,
For the past years I have mainly read complaints from people who then create _A-better-Web-Components-wrapper
Stopped counting at 50+: webcomponents.dev/blog/all-the-way...
And now they blame the technology for their mistake??
Ryan his post is about his mistake to write a wrapper around Web Components technology.
Nothing new, happened in the MooTools/ExtJS/Zepto years too. When jQuery became de defacto standard, many coding hours using the "wrong" tool had to be dumped in the bin.
We will see a lot more of these posts in the coming year, 50+ authors can delete their GitHub repo
Custom Elements and Shadow DOM are available a la carte. Some don't realize that non-Shadow DOM Custom Elements are common. GitHub has a collection, some of which don't have a shadow DOM. Here is one: github.com/github/text-expander-el...
I am bullish on Web Components, because I see them mixing better than two non-Web Components frameworks. I don't see any obstacles to it being widely adopted. If you're careful to use slots, you can put the desired elements in the light DOM, even if they're wrapped in several components containing shadow DOMs.
If you think that Web Components are being adopted very slowly due to their limitations, I encourage you to take a look at some libraries like from Salesforce and SAP. You may not like the workarounds, and think it's just hype driving them, but it gives me the feeling that Web Components are at least a big part of the future. Here's a label web component with for=id being handled by a click event: github.com/SAP/ui5-webcomponents/b...
But is mixing multiple frameworks ever a place you want to be. Sometimes friction to bad ideas is a good thing. Sometimes limitations breed innovation.
As I said in the post there are always solutions to problems but ever so often you need to ask what you are gaining from it.
I am not criticizing their adoption, or claiming people aren't using them. Or suggesting even that they are implemented completely terrible. I'm stating that they bring a cost to the platform that is regrettable over a benefit that is mostly superficial. I feel they now they were the wrong abstraction but that ship has sailed from a standards perspective. The world they promote is no less bloated than what we have today except we pretend things are fine.
It's rarely a matter of "want", more like of "have". Meaning I can't reuse a React component in an Angular application: I have to recreate it.
Heck, I'm not even certain that the same component will work with different versions of the same framework!
That's not the case for Web Components, and that's a clear winner.
“The Rule of Three” (Biggerstaff, T. and Richter, C. (1987) Reusability Framework, Assessment, and Directions):
• You must have looked at at least three systems to understand what is common across them (and therefore reusable)
• It takes three times as much effort to make something reusable as to make it usable
• You will receive payback after the third release.
In 2013 Jeff Atwood added:
Component culture is a phenomenon linked to the obsession with perceived and anticipated reuse and productivity regardless of the downstream effects much like the past obsession with class-orientation (where criticism started mounting back in 2014).
Mass production in software is a solved problem; you want another copy of a program—you just copy it. You need something a little bit different—then you have to “mod” it.
The Elm community observed that “components” don't work for them. They always ended up with a Model-View-Update triplet, i.e. three related but distinct compositional units.
Any attempt to encapsulate these three inside a unifying component wrapper always resulted in unacceptable downsides in terms of maintenance and runtime behaviour.
More universally, inappropriate (component) boundaries will always impose an unnecessary cost, as they are the wrong abstraction (talk).
And as Chad Fowler (“Professional Systems Euthanizer”) observed back in 2014(, 2016 and 2017):
Impermanence: the ironic key to systems that survive—disposable components
i.e. boundaries dictated by areas of high rate of change are preferable to those implied by potential areas of reuse.
Replace-ability > Reuse
The other issue is that almost nobody wants to build Web Components from scratch. Lit is positioning itself to be the “blessed” framework for building Web Components.
But there are countless ways of building Web Components so each independently sourced WC has the potential of dragging in yet another WC framework/library, using a completely different integration style (attributes/props, or custom events).
Not something you should subject your visitors to.
In the web space tools and approaches become “popular” because they are convenient, not because they represent excellence. To achieve excellence it's often necessary to do what is inconvenient.
I'm impressed how, in your 372 words of an answer, I've found exactly zero valid points that could tip the balance in a way or the other. In other words, I absolutely have no idea of what you were trying to say, especially in relation to my answer.
If different versions of a framework can't co-exist Web Components isn't changing that when it comes to authoring them in said framework.
I'd understand how I might have this perspective if I hadn't spent to time to do both Web Component wrappers in frameworks and attempting framework in framework without them. Both require decent amount of work. On one hand the framework maintainers takes the brunt of it when it is with webcomponents because they build towards a standard, but on the other hand the hoops you need to jump through are more limiting than if you just put one framework in another.
A perfect example of this is something like Context APIs which serve as an internal mechanism to provide shared state. You can do similar APIs with Web Components (I was involved in early discussions in WC Community group on this topic). But making a frameworks Context API work across WCs is actually a bigger pain.
Timing becomes an awkward consideration and Context needs to exist and persist beyond DOM elements. Now I've worked with different tools to figure out how to create patterns around this. These frameworks generally aren't designed to work in isolation. They get incredible benefit from coordination. It is actually easier at times to have the frameworks have an interface between that suits each of them rather than try to force a standard interface that impedes.
So on one hand they could never accept a WC only mechanism because their needs transcend them but on the other hand WCs actually get in the way.
Back to the beginning. You can't use a React Component in Angular app. You probably could. Kind of like how you use a Web Component in an Angular app. But you are doing both frameworks a disservice unless we are talking that one off type case. You limit their ability to be the best versions of themselves.
I say this knowing this fact alone would get in the way of the adoption of my own framework. But how could I ever recommend a path that didn't give people the best chance to build the best possible sites and apps.
The main driver of your motivation is reuse.
That is a problematic motivation when it comes to software design and implementation, largely because it requires clairvoyance on the part of the designer/developer (unless it's already been done several times before, i.e. experience); relevant reuse is mostly discovered, not designed up front.
So it makes perfect sense to first design a component in React, then in Angular if need be. Once you also have to create one for Vue it may make sense to try to extract one common implementation, one that works equally well in all three cases (though often the result is just equally awkward in all three).
A more optimal solution may be extracting some framework agnostic logic that can be shared among all three but doesn't fit the definition of a convenient “component”.
And the notion of “doing the right thing the first time” doesn't wash in most cases because most knowledge only exists once you are done. It's only once you've built the React, Angular, and Vue version that you have a much clearer picture of what can be effectively and efficiently shared.
One important criticism to React is:
“… that's like React's biggest simplification, its biggest flaw—they are basically equating your data tree with your view tree …”
This can apply equally to WCs where what is ostensibly a DOM element takes on application responsibilities while having to somehow interact with the rest of the application in some bespoke manner.
The thinking behind WCs is rooted in 2010-era thinking of object reuse and client side rendering and ultimately limited by it.
Declarative Shadow DOM is just the latest layer of complexity introduced to the WC standard (and by extension browsers) in an attempt to address the shortcomings locked-in by the assumptions made back in that climate.
And in terms of solution architecture starting with hexagonal architecture (2005) the wisdom has been that a sound, maintainable solution should dictate the interfaces it depends on (narrowing API or pattern of usage API), rather than accepting the interfaces already exposed by the dependencies.
So anything reusable may incur the overhead of a DMZ or anti-corruption layer.
This is all purely academic and scarcely applies to reality; and it's also jarringly distant by the concepts we've been talking about. OOP isn't even a discussed issue here.
You end up justifying rewriting components because "third time's the charm". From a business point of view, this is suicidal. Are you going to pay for that?
Also, some statements are factually wrong. Web Components have always been a "work in progress" so far. The issue of server side rendering has been known since the inception: HTML Imports would have been the solution, but then different paths have been taken so far.
Components are an embodiment of OO. Always have been, always will be. Perhaps this is a “can't see the forest for the trees” situation. Also: Document Object Model.
That's a commonly held belief. That's why I brought up Chad Fowler. By adopting a “so small, it's trivial to rewrite” approach eventually at Wunderlist they got to a point where they could continually change without having to wait for the next “big rewrite”.
Now if you have hundreds of components, supporting yet another framework can sting but if everything is “trivial to rewrite“ maybe its doable, especially if there are numerous areas that are independent enough to be built concurrently.
Now the Porsche Design System v3 seems to be largely WC based but explicit support of React/Angular/Next JS/Remix/Vue will still result in the “write once, test everywhere” syndrome.
They aspire to be “components” mounted to the DOM. The boundary implied by that is locked-in. Customizing built-in elements is one thing, components are a different animal altogether.
They could be functions, they could be numbers, they could be Easter bunnies. Nobody cares. It's academic trivia.
I.e.: absolutely nobody.
"No rewrite" is always less work than "trivial to rewrite".
This is historically inaccurate. The conception of Web Components predates React, and the time when Angular JS started calling them like that. Nowadays, the term has been tainted by the success of React et al. and it's widely recognized that it doesn't fit the definition of Web Components. But Web Components have never changed their nature.
You chose to solve problems with your own solution, even though there was an option to improve the existing Web Components in the platform. You're simply experiencing the consequences of that choice. If you want to reduce the price you're paying, contribute to improving WC.
I did go the fully embracing web components direction. It just isn't the right abstraction. Asking Web Components to change to meet the needs of modern frameworks is sort of pointless because it would require fundamentally changing what they are.
It feels to me that this article compares frameworks and web components like comparing a monkey and a fish and saying that the monkey doesn't have a future because it would lose in a swimming contest.
A lot of the components you speak of, or those "micro-frontend" bits, are often pieces of logic, a way to organize frontend code, "functions" in a way. For that reason, they're very JS-oriented, and they align well with SSR and build tools, and they need abstractions like fine-grained reactivity (swimming).
This is all good, and indeed not the sweet spot of web components. "Widgets" like ZenDesk is indeed a better example, but also more importantly a set of UI components (design system) rather than app components. A button or a calendar doesn't need microfrontends, doesn't need "fine-grained reactivity", and might not need a full-fledged full-stack framework that isomorphically converts JSON to HTML to render. It needs good encapsulation around styles and DOM (e.g. namespace), be portable and somewhat detached from how the organization builds "apps" or "frontends".
Web components still have ways to go, and I don't know what the future is... Perhaps ever-evolving frameworks would continue to be the future of frontend development and web components will be, well, a component in how people integrate widgets and design systems?
I think your own article highlights how to construct a web UI in a composable manner without necessarily resorting to “components”.
Great article
Please also write an article about WebForms Core technology. WebForms Core is a technology where HTML tags are managed from the server.
WebForms Core article:
dev.to/elanatframework/using-webfo...
Video of how WebForms Core works:
youtube.com/watch?v=zl4sxjIkBwU
I think it's great that library authors have the option to distribute their code in a form that can be used with any of the popular UI frameworks. The SSR/SSG issue is currently the biggest drawback, but declarative Shadow DOM will fix that eventually.
I think the main issue is that Web Components were standardised according to the prevailing paradigms 10 years ago and Frontend development has moved past those ideas. Then, Web Components couldn't live up to the expectations people had they would fulfil. Now, they are widely supported, but things like Shadow DOM complicate development rather than being helpful, if you don't need that strong encapsulation. Also, back then, most frameworks embraced client-side rendering as the way to go. This was clearly a mistake, but frameworks pioneered this approach, Web Components followed, and frameworks moved away again in the last decade. Web Components stayed there, at least in the mental model of developers and framework authors. Those mental models are the cost Web Components impose on the community.
But that aside, one can definitely use Web Components in a beneficial way. Just don't use Shadow DOM if multiple components come from the same trusted source and should have little barriers for sharing styles. Custom Element tag names with light DOM are a great way to have unique block scopes for styles.
Server-side rendering of Web Components is possible with any backend technology. Just render HTML and bundle assets as we used to do 20 years ago. No JS framework has such minimal requirements and such an easy interoperability with all sorts of backend technologies. Nobody forces us to do client-side rendering.
Web Components don't have a state management solution. But it's possible to build one that converts observed attributes to signals, sets them on user interaction and does only the necessary fine-grained updates in the DOM with effects. It takes about 1 to 2 kB of gzipped library code to do so. You simply can't have such a minimal footprint AND the full power of reactive frameworks with a full-blown JS framework that implement all the features Web Components already provide in JavaScript again.
Funny how somehow Web Components and Blockchain tech give me the same kind of "vibe" - both feel like "solutions in search of a problem" ;-)
Next year, surely!
Interesting perspective! While opinions on web components vary, tools like Unlimited Web Tools can help developers streamline their workflow with features like minifiers and formatters, regardless of the technologies they use. Worth exploring!