A few years ago I wrote an article suggesting that Web Components might not be the most beneficial direction for Web development to head.
It was a soft-handed look at where they made sense and where things fall apart. It wasn't geared as a "us against them" argument and I hoped people would come to reasonable conclusions for themselves.
But over the past few years, I've only seen the situation worsen. Some may have never taken Web Components seriously, but I always have. I used them in production for 7 years. I wrote several polyfills in the early days for things like the Shadow DOM to use them before they hit prime time.
But my experience then and my experience since only points me to a single conclusion. Web Components possibly pose the biggest risk to the future of the web that I can see.
Visions of Utopia
I admit that statement comes off a bit heavy-handed. But many reasons lie below the surface as to why I believe this. And it starts with understanding the proposed benefit of Web Components.
The vision of Web Components is that one day regardless of what tool you use to author them you can have components that feel as native as DOM elements that can be added to any website without consideration of how the website is authored. No concerns about specific build tools, specific runtime mechanisms, or the way one would ever interface with these components would ever change.
In a sense, a portable interoperable web. One that can mitigate the future need for migration. One that sets you up for any possible future. The perfect way to future-proof your sites and applications.
A compelling prospect is it not? This is exactly why the promise of Web Components is so alluring and so dangerous.
Competing Standards
I didn't need to pull up the old xkcd comic for you to know the challenge with standards. The more ambitious the standard the more likely it will have opposition or alternative approaches to accomplish it. This doesn't go away when something is standardized. It just suggests that there is one blessed way. You can take it or leave it.
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 introduction of higher-level primitives can have a positive effect. Suddenly something harder to do becomes easier. Which initially leads to more exploration. Web Components caused an increase in the number of JavaScript frameworks in the mid 2010s. It was an important inspiration for why I created SolidJS. A similar example would be the increase in Metaframeworks being built thanks to Vite.
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?
I've struggled with this a ton outside of web standards. JSX according to the spec has no established semantics but try to convince the wide range of tooling out there they are assuming too much. I can only imagine the nightmare it would have been if JSX had been standardized in the browser. Forgetting how frameworks like Inferno, Solid, and Million, have done way more optimal things with their JSX transform, even React has changed their transform over time.
This is but one example of many. Things that help us, can effectively tie our hands. We must tread carefully when standardizing any higher-level mechanism because it assumes a lot. It is insufficient to say not everyone has to use it when its existence influences how we look at the platform in general.
Opportunity Cost is Real
As a framework author, I understand this too well. I often say that in this field things are discovered as much as they are invented. What I mean by that is there is a certain truth/physics, if you will, to design decisions that when followed lead us all to similar places. It isn't that these tools copy each other blatantly. They fall into the grooves.
And for the same reason once a discovery is made that changes our outlook, the damage is done before we write a single line of code. If your job is to design a system you don't want redundant parts. You want clear purposeful boundaries. Instead of making a million variations on the same thing you try to re-use one thing. More so recognizing that to accomplish common tasks you need multiple things these pieces become intertwined.
For example, React developers definitely felt how long it was between the announcement of Suspense in 2017 and when we finally got a data-fetching story for RSCs in 2022. Why did this take 5 years? Because it wasn't a straight line. It took a while to understand how all the pieces fit. That in itself is reasonable. But more, React didn't want to release it piecewise until they knew they had an answer for the whole story. As they looked more and more, all these pieces were related and while they could be broken up they needed each other to paint the picture.
RSCs do not fit everyone's idea of how data fetching with Suspense should work in React. Maybe people could have benefited from a client data-fetching primitive. React chose to be ambitious here which is their right as a tool and decided what was best, but this could have played out a number of ways.
As a developer, I can always choose not to use React. And while I can choose not to use certain React features it is clear everything in React has shifted to their current mental model. I might even be wishing I could easily migrate off React.
But there is a big difference here. React is a library and it isn't a Standard. Those options aren't the same when it comes to Standards. If all I wanted was scoped styles and now I have to deal with the Shadow DOM because that was the abstraction that best fit with having a single way to do things due to Web Components, well that is what I'm stuck with.
When primitives overstep their desired usage, when they over abstract, you don't get to come back from that. You've already paid the cost. And as anyone who has done major architectural refactoring of a project can attest, the hardest part is adjusting boundaries. If things fall under the same logical grouping they are easier to update. It's when you need to break things apart that it gets truly challenging. You can always add another layer of abstraction to solve a problem but removing one can be difficult.
The Cost of Abstraction
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.
So what? It means that every interface needs to go through the DOM. Some in well-defined ways that aren't a perfect fit, and some in newly defined ways that augment or change how one would deal with Elements to accommodate extended functionality.
To begin, DOM elements have attributes and properties. This is so that they can be represented as HTML. Attributes accept only strings while properties being a JS interface can handle any value. Native DOM elements have many rules around specific attributes/properties like how some are boolean (existence means they apply) while others are psuedo-boolean (needs an explicit "true"/"false"). Some properties reflect to attributes and others do not.
A goal of templating languages is to solve this in a uniform way. We can make special rules around known elements and attributes. But with custom elements we don't know. So this is why some templating libraries have interesting prefixes to indicate how things should be set. Even Solid's JSX we have attr:, prop: and bool: prefixes for this reason. Now every runtime location and compiler hook needs to be aware of this.
You might be thinking we need better templating as a Standard. But like JSX above you need to consider the implications of that decision. A few years ago most people would have probably agreed that the way something like LitHTML did template rendering was something was a good approach. Other solutions could output it. However, in the interim, we realized that reactive rendering, like what Solid does, outperforms it. It does so by changing the semantics of the templating. If we had moved ahead we would have a standard that would not be the best way to do templating.
It doesn't end there. DOM elements can be cloned. But Custom Elements have different behavior which means they should be imported instead. They have DOM-based lifecycles that can trigger synchronously or asynchronously depending on when they upgrade. This wreaks havoc on things like Reactivity tracking and Context APIs. However, these details are important to interface with native DOM behaviors and events. These are also all things that a JavaScript Component doesn't worry about.
There are other idiosyncrasies like the way event targeting works in the Shadow DOM. Some events don't "compose" ie don't bubble beyond Shadow DOM boundaries. Some events don't bubble consistently because they don't recognize a different target, like in "focusin", because the Shadow Host is always made the target no matter which child element gains focus. We could talk about these for days but I don't want to divert to much attention here. Some things are today's shortcomings and some are by design. But the commonality here is they all require specific consideration that otherwise wouldn't be necessary.
And of course this has a performance overhead:
But even if you consider this performance cost minimal, where does it leave us when going to the server for things like SSR? Yes, you can completely do SSR with Web Components. Hydration is completely achievable. But they are a DOM interface in a place with no DOM. You can make a minimal wrapper to handle most things but this is all extra overhead. All because we tried to make Components something they aren't.
On the server there is no such standard. We are back to having specific solutions. It is just another type of framework with no more guarantees than if I chose Vue or React for my next project. There is nothing wrong with that, but we need to recognize that fact.
The Real Cost of Web Components
The complete picture is one where the complexity of dealing with native elements increases to account for the new found flexibility of web components. It is something that as tools support them better, not only is the user of them paying the price of but all users of that tool. More code to ship and more code to execute to check these edge cases. It's a hidden tax that impacts everyone.
I've talked about where early standardization would have been catastrophic. But it also has the potential to stifle future innovation along certain paths because it assumes too much. Improvements to hydration, things like Resumability, Partial or Selective Hydration depend on event delegation to work. But if Shadow DOM messes with that then how could Web Components fit that model? SSR some might say was an oversight because we didn't think about that much in 2013, but this gap only continues to grow over time.
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. Something you have at authoring time that vanish from the final output. For optimal user experience we optimize away the components.
I'm not saying someone couldn't find some interesting solutions to these problems but they all imply taking on the hidden cost due to the foundational misalignment of having the wrong abstraction. This is what makes the dialog here so difficult. It isn't something you improve. It's just a mistake for a number of things.
Now we can all say different solutions have different tradeoffs. And maybe something like Web Components could only possibly succeed with support of things like Standards bodies because of how pervasive it would need to be to work. It's an ideal we are working towards and just aren't quite there yet.
But is it actually ideal?
Utopia Revisited
We often hit a similar debate when talking about Micro-frontends or Microservices. It is beneficial for organizational purposes to align projects with your developers. It follows Conway's Law.
The isolation or portability afforded by Web Components means that one could have multiple different components on the page from different sources. Now like the others prudence is in order. Similar to not wanting to write all your Microservices in different languages you might not want to author all your components in different frameworks.
But frontend is a much more restrictive space. The cost of each kilobyte of JS is not insignificant. It isn't only maintenance why you wouldn't want to mix and match but to reduce payload. And this is where the wheels start coming off.
If your goal is to future-proof then you need to be prepared to keep different versions of even the same library on the same page. This is no different for Lit as it is for React. You could choose to never update anything, but that is an option without Web Components too. There are no additional guarantees here. To future-proof the only the choice to freeze things, maintain multiple versions, and load more JS on your page.
Realistically you will update your libraries in lockstep which is also the same with any library. And in those cases if you only have a single library on your page Web Components aren't doing anything for you but adding more overhead. Possibly getting in the way of features that the library provides now and in the future. You might as well use the library without the Web Components.
The second consideration is granularity. If you have a Microfrontend then that is a contained swappable piece. If in the future you decide it isn't the best way to handle things you swap it out. But once you adopt web components everywhere you will need to address each of these touchpoints. Web Components differ from MicroFrontends and Microservices because they can be used cross-sectionally. This is good for standardization, but I've never seen a company that uses jQuery ever completely be able to get rid of it.
The most compelling uses for Web Components are as a sort of Microfrontend container. In that case, you don't pay the scaling costs, the outside communication is minimal, and they are easy to swap in/out. The one-off scenario. In those cases though the friction is low enough that having Web Components isn't necessary. I'd take them for the ergonomics to put a Zendesk widget on my page, but is the abstraction worth the cost?
Conclusion
And that is what it comes down to. I could not argue that there are not ergonomic benefits to using Web Components in some scenarios. But the cost it imposes everywhere is steep. While I shouldn't be quick to disavow a technology for the types of poor patterns it enables one to do, it is difficult to stand behind it when it never fits in the ideal scenario. At best it is a nominal overhead.
Web Components are a compromise through and through. As we know sometimes we need compromises. But that is nothing to get excited about. And some compromises are better than others.
It was presented to me that in 10 years from now it's possible no one would be using Solid but a Web Component would still be there with the same interface as today. But I thought for a moment and responded I'd still build it with Solid because that would be the best choice for today. In 10 years even if I had to use a 10-year-old version of Solid it would be better than the Web Component version. 10 years doesn't erase that. And hopefully in 10 years I'd be using something better.
The decision is completely orthogonal. 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.
Top comments (86)
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.
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?
Have you seen conversations in the Web Components Community Group discord (which by the way has a different logo than the one the article is catching on fire)? We're very much solving similar problems, but user land frameworks are, of course, always a step ahead in helping figure out those problems.
Of course. I've been involved on a few of those discussions on the past. I want to quote this from my article.
I have no doubt that in many cases similar systems to those in frameworks can be made. Context API is perfect example. But due to the constraints of being DOM Elements the implementation differs in ways that make them less portable or difficult to make compatible with what the frameworks are doing. So we are stuck with something that can't be adopted by the framework and is generally incompatible.
But if an abstraction is not compatible with Solid's, it's ok, maybe it is compatible with WCs. Yeah Solid context API is not designed for Custom Elements, but that doesn't preclude a nice context API from existing for custom elements.
It is true that Solid context API is not portable for custom elements in general, but that's ok. Even without a context API, custom elements are useful. And there are context APIs that work with custom elements in general, and also context APIs specific to custom element frameworks.
At the end of the day, maybe no pattern can work for everything. A context API for custom elements may definitely not be compatible with Solid or vice versa.
Following some conventions for example, Lit's context API, or this simple context example I made in the Skate.js days, can work reasonably well when sticking to the same convention in a single app.
It's not like everyone needs the same context implementation. Solid's is only good for Solid users, it will never be good for other frameworks or even custom elements. The custom element contexts at least have a chance of working across multiple frameworks, but that's still not good enough across multiple CEs with differing context APIs, and maybe that'll be impossible forever.
Ultimately custom elements are more compatible than you are making them out to be.
For example Lume 3D elements work in Solid, React, Vue, etc, and even provide faster declarative data management than react-three-fiber. The abilities it unlocks across all frameworks now and in the future is magnificent, and truly is a testament to what is possible with them.
Like just because I cannot use a Solid context with Lume custom elements is nowhere near a problem that can outweigh benefits.
Making react-three-fiber work in Solid is a lot more difficult, and vice versa for solid-three.
If Lume gains a killer feature everyone wants, it'll automatically work everywhere and the cost will be small compared to the gain in abilities.
Completely slamming Custom Elements is too heavy handed. They're already here to stay and the best frameworks will ensure they work well in their systems (not saying non-custom-element frameworks needs to output custom elements, just that custom elements need to be easily consumable in them, that's where the major benefits are because there are already other frameworks for writing them).
The user experience matters the most, and if I can out together a 3D application in any non-CE framework and it works out fine by all standards of what a fine app is, then it means the custom elements did their job.
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.
ā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.
I mostly second this; I see why frameworks are cool, but they are specifically built to hide the browser APIs in a world where said APIs are becoming more and more powerful.
Web Standards are ever evolving, but they are nowhere near to reach the DX of frameworks like Solid or React. Authoring reusable pieces of content using only DOM APIs is laborious and scattered.
I demonstrated this few years ago to a client having the same opinion as you by writing the same app in Web Components, HTML templates and React. Needless to say the comparison of framework vs non-framework is not pretty nor something an average developer would like to maintain, even though I tried to make it as declarative as possible.
If we went to square one, we would immediately start creating abstractions to simplify operating the DOM APIs and move to a more declarative fashion. Eventually, we'd end up at the same place we find ourselves in currently. It's not a perfect state, but miles ahead from 10 years ago with frameworks providing much of the needed support.
"I demonstrated this few years...", I kinda lost you in "a few years ago" ;)
The web standards are constantly and rapidly evolving. Yes, you can always abstract them for better DX but I'm talking more about the concepts of SPA's vs. MPA, reactvity, SSR and more... The place frameworks take in these areas today, moving away from the native apis the platform supplys will be diminished over time, IMO.
Not much has changed in the past few years with respect to the DX of custom elements. From what I've seen over the past decade, custom elements have actually been very slow to evolve. Care to elaborate?
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?
I don't think this is a strong argument against Web Components because you can easily flip the statement and still holds true: "We doubled the size and complexity of our event delegation code [...] just to handle Shadow DOM better and it still falls flat for many cases because of how Solid.js is designed."
I get that it's a lot of work for the Solid team to make WCs work, but you're also the one who created a mental model that is dramatically different than a piece of the web platform. You have absolutely the choice not to support WCs, but I don't think it's a case against WCs as much it is a case against frameworks.
FWIW, I personally avoid the Shadow DOM. Sure, it solves some problems but opens an entire set of new problems (and not just problems specific to frameworks). I won't even pretend I can fully understand the struggles that FW authors have when trying to support it. But, as a user of both Solid and web components, may I suggest that this may be made easier by setting users' expectations more explicitly?
For me, what's currently in Solid works well enough - I can use web components inside Solid and can author web components with Solid. I don't imagine that's everyone's experience, but maybe that can be improved by better docs and examples (thus, hopefully reducing the burden of having to support every edge case under the sun). The "golden path", for me, would be something like (and I'm taking Solid as an example here, but I imagine this can be applied across the board):
Ultimately, I realize there's a point when all of this complexity stops making sense to support due to the amount of work authors pay, and the bundle price users would pay. I'd be happy to help in making this better, however. To put my money where my mouth is, I'll start working on this one github.com/solidjs/solid-docs/issu... starting tomorrow.
This is a really interesting point and one that I wish I hadn't missed when I first read this. I take it Solid does automatic event delegation because of the perf benefits? I know there was some debate about this in
js-framework-benchmark.In LWC we definitely don't attempt to solve this problem, which makes our implementation simpler at the expense of forcing the component author to do event delegation themselves if they want to improve perf. OTOH I crunched the numbers a few years ago, and event delegation is still a clear perf win, although on the order of ~30ms for 10k elements, so not necessarily huge.
I think this is true from a 10000 foot view. It may appear to work, but when you look closer you will find that it may not work well, or at all. This is particularly true with React.
Consider a custom nav element,
<custom-nav-item>with a built-in<a>tag. If you try to use this element with Remix, React Router, Next.js, Gatsby, etc... you will quickly find that the internal<a>tag is incompatible with most of these. They each use a specific<Link>component that is responsible for enabling clientside routing (i.e. SPA mode). You can't nest an<a>tag inside another<a>tag, so something like<Link><custom-nav-item /></Link>is not a viable approach. I actually don't think there is a viable approach that doesn't result in invalid HTML. In this case, the main issue is nesting an<a>tag inside another<a>tag.I would argue that this is not working, and therefore not viable. And this is but one of many issues when it comes to integrating web components in modern frameworks.
While I get your point, you can still just attach an onClick and pass make the
custom-nav-itemjust triggernavigate, right? That said, I don't think I'd ever go for a custom nav item when using a framework. It just doesn't feel like the kind of a problem that WCs are good for.The onClick approach is an issue for several reasons:
<a>tag already covers for us.Completely agreed. I am wary of evangelists that are extremely pro web components (or for that matter, any technology) to the point of blind dogmatism. This is not healthy for any engineering team. They are not the best fit for many use cases, particularly with frameworks, and that's what the author is getting at.
Then, I don't think we disagree? :D
The point I was trying (perhaps unsuccessfully) to make is that WCs do have some good use cases. They aren't many, and they come with compromises - but those cases exist. Two come to mind (there are probably more):
Agreed haha.
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.
Yes, and the developers at Apple have said they won't implement the
isattribute so you have to always have a polyfill for it. Yes, I agree that web components are much more powerful. I just want something simpler. WithtraitsI could have multiple different enhancements on a singe element.Thank you for your reply!
Please take this as just another perspective, not an attempt of arguing that yours is less valid, but while reading this post I've found myself repeatedly just thinking "what are they even talking about?"
"web components" are definitely trying to be a somewhat generic API that doesn't lock people into one very specific paradigm; they're designed to be more of an in-between layer serving as a transpilation target or lower-level API for more high-level component systems.
But they're still not a catch-all system for building "components" in the broadest sense. Maybe the name web components was somewhat poorly chosen in that regard; colloquial names for web technologies have a habit of doing that (looking at you, CSS variables š).
The API that sits at their centre, "Custom Elements" is probably a much better name if you want to be specific. That's the use-case they're trying to cover. When whatever you're trying to build fits neatly into the concept of a single independent HTML element, but none of the built-in ones have you covered, then you can simply build your own using a custom element; and once you've done that, you can even share it for other people to use them.
"Components" are really a much broader concept, that's very loosely defined. It's somewhat more granular than a "view" but generally more complex than an element. Are rails partials "components"? Hard to say, specially if they have inline javascript.
There's also no rule that components need to be limited to a single top-level element; maybe some implementations impose limitations like this, but that's an aspect of those systems, not of components as a concept. Some browser APIs even allow for this:
<template>elements can have many child nodes that simply get inserted next to each other. Remember: "web components" is an umbrella term for the combination of several features,<template>s being one of those as well.I've been using and misusing custom elements for lots of things myself, and whatĀ I can say is this:
The design is clearly centred around simple, re-usable and generic custom elements of similar or just slightly larger scope than most built-in elements.
They can be used for larger scope stuff, like user cards, calculator components, etc. but they clearly weren't built with that in mind. Therefore there will also be a lot more friction when trying to use them for these situations. You can, and they certainly do work for that, but that's not their exact intended purpose, and it shows.
So it feels a bit weird to hear criticism of web components based on this; your post reads a bit like a complaint that a sushi knife struggles to cut through freshly baked bread.
Maybe I misunderstand your criticism, and am just missing how it also applies to smaller components, but the way I understand it, the real problem isn't web components, but the lack of a built-in mechanism for larger scope compositions. Personally, I'm not quite convinced that browsers should even provide those; frameworks are probably way better at implementing something like that.
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.
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.
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.
This may not have been intended to be taken broadly (e.g. may be specific to mixing frameworks or overhead of just using WC instead of a particular framework, etc).
So, with that out of the way, I'll just list a few major use cases for WC which have proven to be very beneficial for my small team at eBay. 1.) Enhancing existing legacy websites which are non-JS on the server-side and 2.) Code sharing across completely separate platforms and vendors. The simplicity and composability of defining a tag with a simple API to define the tags state (i.e. it's attributes and contents/slots) interfaces quite naturally with server-rendered languages like PHP. You can also leverage it to share code in situations where you can neatly package up your UI component for use on third party vendor sites (like those which, ahem... wrap their entire page in a giant
<form>tag...) so that your own site search<form>doesn't break everything. šMuch of what you said is still true with respect to some of the introduced complexity! Some of the tradeoffs however make it still worth it, especially if it is carefully architected.
Did microfrontends ever come in full-swing at eBay? I remember giving a talk about them there where the Marko team had come up with a mechanism to do server microfrontends in an attempt to improve performance and convince people that Module Federation was a terrible idea.
Web Components are sort of the same. I think people probably have a real need for something in this category. There is too many organizational(people) coordination concerns that get in the way of being able to do the best possible thing. This is what I mean when I talk about "mixing" not being ever where you want to be. Obviously it is a place you are forced to be. I just don't think we should welcome it. We should like with microfrontends try to find any solution that works until we absolutely need it.
Web Components can be a great tool that we could get excited about when it solves are organizational problems. But it should not be a solution we should be excited about to solve our technical problems.
Yeah, while I don't write any Marko code, I think this is it: github.com/marko-js/micro-frame. I remember attending a talk internally about it.
Understood(organizational vs. technical). Two completely different and difficult issues, particularly in larger organizations, to be sure! I'd add "legacy" as another technical challenge here as well. Legacy salted with a bit of "not a lot of time" (b/c otherwise you can technically solve it by scrapping and rewriting). I think pure frameworks offer a better overall technical approach, particularly when you can roll everything together. You end up with overall far better and more cohesive solutions. My current heavy use of WC's is in the realm of using them as a portal for a sort of middleware to help glue things together; it is part of the technical solution in the "real world" of multiple competing challenges (yes, particularly organizational and of course legacy).
This is a reality for some businesses, @ryansolid - especially for SMBs in the enterprise sector. Not everything is a greenfield startup and OP correctly points to SAP, Salesforce, and friends. I have multiple clients who serve a niche industry in those ecosystems where components are used in all kinds of custom development projects and are made available as a library to their customers if they want to do the implementation themselves. I work with those clients to get their UI library from React-only to Web Components - exactly because they cannot reimplement their incredibly specific stuff over and over again.
A lot of React code has been written in the enterprise world - and it doesn't seem to slow down. The cost you're describing is basically one way to open the door for other frameworks, like Solid, Svelte, or Vue. That's the benefit: allow enterprise to be something other than React. As OP pointed out, libraries like SAP UI5 are an example of that: "Here's how the world looks and behaves according to SAP, now use it in any framework you like".
It's ok for a framework not to care about Web Components, but then at least my little corner of the enterprise development world won't care about this framework either. My clients would rather use React until the end of days before rewriting their stuff again - because similar to what you say about Web Components, the cost of rewriting stuff in a new framework is regrettable over a benefit that is mostly superficial.
End note: I only speak for my corner of the enterprise world, I'm sure other corners have a different view. I also use Solid on a greenfield project with another client - and it's amazing. Love your work!
Precisely. I think we can all actually agree that there is indeed a cost there, particularly in that compatibility layer or in the tooling in order to glue things together.
In fact, I use WC as a portal/API to implement components my way (which just happens to be Svelte in my case). I can still use slots and I have some basic component lifecycle stuff that I hook into. Then you can roll what I built wherever WC's are supported.
Regarding using slots in the light DOM: My library
svelte-retagintegrates Svelte slots using web components in the light DOM (with some support in shadow DOM as well). It's very composable and even supports Svelte's context as well.That said: I will say that using slots in the light DOM isn't anywhere near as robust as native shadow DOM slots. Without diving too much into detail, one example is how things "just work" when you manipulate slot contents and those contents are reflected as you might expect in the host element, whereas doing that in a light DOM implementation may not always work as expected (or even be feasible in some scenarios). This is because modifications to slot contents after mount could cause unexpected results. So, in that sense, the isolation that the shadow DOM brings is very much a feature when working in a more native (i.e. framework agnostic) context.
Now replace "Web Components" with "Microservices".
I've written 4 sites in uncompiled LitHTML and it's a relief:
How does Dependency Injection work?
Great post
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.
Its called standards.
Web Components is not about technology, but about 4 major companies working together.
But I will happily transport you back 20 years in time when we had to develop for 4 different Browsers.
No I was there. I don't want to go back. I don't have an issue with Standards in general. But there are reasons, as a technologist, Web Components in particular stand out. I empathize with the challenges then and now to get here. I remember some of what I thought were outrageous asks from Apple regarding the shadow dom, the dance around native element extensions, and V0 vs V1. Getting everyone coming together is a feat in itself.
Ryosuke Niwa recently thanked the WHATWG community for their efforts.
You know that community, so you can value what that sole remark means.
That standards body is the only body that will decide what runs in the browser for the next 25 years.
Fight/ignore them or join them, those are the only options you have.
And in joining you can chose to follow every Web Component fart Google releases;
join the community sessions: github.com/w3c/webcomponents-cg/is... and validate your arguments are valid,
or only focus on technologies supported by all 3 Browser engines.
I have been doing the latter for the past years, does it feel as exciting as my tour of Internet-duty in the 90s...
No, but I know this old geezers code will run without any issues for the next 25 years
I stopped using Frameworks when Google called Angular 2 an "upgrade", so never had the urge to create a I-can-do-Web-Components-better wrapper.
Will the WWW be around for another 25 years... maybe not... there will always be smarter people, with smarter marketing (technology doesn't count) I looked in the mirror years ago and concluded I am not good (enough) at marketing.
Fighting evolving standards... been there... lost when WWW trumped my early 90s Gopher dabblings.
Yes, it will hurt to let Solid go...
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
Frameworks are indeed abstracting web technologies away, and that is a good things.
We don't program in Byte Code or in Assembly code, because that is not the level of abstraction we want to deal with. Could we build a website in Assembly? Sure, but we don't want to.
We build websites with Frameworks. But we build also native apps, and VR apps, and terminal apps with Frameworks. Or even Windows Start Buttons. Just like my Assembly code can run on different processors, the work in my Framework can run in different digital experience platform . The framework should decide how it works with the primitives of that platform (browser, vr environment, native app, etc.) and the platform should stay as unassuming as possible.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.