It seems like Web Components are ideal for libraries shipping pre-built components, which is probably why Mux finds it compelling. From Mux's point of view, they want the highest level of compatibility with the least amount of framework lock-in. For example, they don't want to have to ship a library for React and another one for Vue and another one for bare bones JS/HTML.
In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.
(author from Mux here) -- that is correct. For the stuff we build for in-house use on mux.com and dashboard.mux.com we have a components library written in React.
You nailed it that we are shipping SDKs with visual components (like a video player) that need to be compatible across all kinds of frontends.
Instead of N number of SDKs to maintain where N is every front end framework, we have 2: a web component, and a React wrapper around the web component. Maybe in the (near) future we only have to maintain 1.
If you're prepared to put money down on it, I'd wager $500USD on longbets that Web Components will still function in 20 years.
And I'd wager another $500USD on longbets that it will be easier to port a web component written in 2024 into a new project written in 2044 than it will be to port a react component written in 2024 into a new project written in 2044.
The reason why I'm so confident is that Web Components are already a standard.
I am not a betting man, but I would not be so sure. The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet.
As someone who has been doing GUI development since 16-bit Windows, it's really remarkable to me how much staying power React has. It's 10 years old and still the dominant way of building web applications. I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack.
What I'd be most concerned about with any 20-year bet is what new paradigm/library might come along and supplant the old ways. Standard or not, React has a critical mass that will keep it viable even if it becomes "legacy". If some new hotness makes web components look old-fashioned, the small community could disappear pretty fast - browser standard or no. Ask any XSLT developer.
> The web is littered with abandoned standards, and Web Components - while by no means a failure - have not really achieved widespread adoption yet.
Web Components are used by internally by browsers to implement elements.
As dannye stated (https://news.ycombinator.com/item?id=40292970): input, textarea and video are all web components. And since the major browsers have implemented those elements in that fashion I think it's safe to say they have most certainly reached widespread adoption. (even if most people haven't realized yet)
> I can't think of any other frontend library (web or native) that has had that long of a run at the head of the pack.
Flash and jQuery come to the front of my mind. React (or at least the React of today) will one day be looked back just as we look back at what came before it.
I think it'd probably be fair to say we're at that point about 10 years after the record-tuple proposal goes through and the explicit resource management gets a syntactic sugar upgrade a la promises to async/await. They shift the paradigm enough that the old assumptions used when building our current frameworks will need to be re-examined. New frameworks will be able to blossom, and/or the current frameworks will shift enough internally that they won't resemble how they are today, and they will have to drop support for older code, or run slower compatibility layers that no one would want to use on newer projects.
Even if one of those proposals fails to go through, we would still have other standards moving with enough momentum to eventually change the landscape. In the long term, I'm looking at a lot of capabilities being added to wasm to make compile-to-wasm look more attractive.
<software that is used internally in some popular software> doesn't grant network effect - after all, the team(s) that maintain the software could replace the implementation and nobody would be the wiser. The countless humans trained to write React code are harder to fix.
Flash and jQuery are contenders, but still aren't comparable. They didn't run as long at the head of the pack, and the web (and web development community) was much smaller back then. React is still going strong.
I agree with you, all things (and especially all technologies) end. But I'm not ready to speculate what the post-React world will be like. I don't think we've even seen "peak React" yet.
> Flash and jQuery are contenders, but still aren't comparable.
I would contend that they are. Flash was enormous, it was installed for 92% of all internet users. (Source is wikipedia, they've rewritten the page, but it still appears in google's cache, search: "flash player 92%") It wasn't just the standard, it was the industry. Jquery too used by at least 76.9% of all websites, compared to React at 4.2% all websites. (source: https://w3techs.com/technologies/details)
> But I'm not ready to speculate what the post-React world will be like.
I am.
React is currently adding web component support right now.
TC39's tuple/record propsal will reshape dataflow in component libraries/frameworks. Eventually we will get syntactic sugar for explicit resource management to make it easier to use a defer style setup/pulldown like in other languages. Both of those (plus the decorator proposals + extensions) will change the dataflow and ergonomics of the js landscape.
Frameworks will adapt into new shapes of be supplanted.
If react wants to keep adding new ways to do things to hold onto the "react" brand then by all means, but even now it wouldn't be unfair to say we're in a post-<this kind of>-react and a post-<that kind of>-react world.
...and yet standards bodies do deprecate standards that fall out of use. WebSQL and XHTML come immediately to mind, I'm sure there are more. Not that I'm predicting Web Components will go that route, but - given a long enough timeline - I don't dismiss the possibility.
Flash and jQuery had their time in the sun, certainly, but not as long as React, and the web (and web development community) in the 2000s was tiny by modern standards. Also, I don't believe that "user installed base" is an important metric - "number of programmers deliberately writing software with it" provides the network effect.
If anything, your point about the ubiquity of Flash reinforces my point that "web standards" can change pretty suddenly when mindshare changes. The writing was on the wall, but the iPhone really killed Flash.
"Web Components now" has been the "year of the Linux Desktop" refrain of the webdev community for a long time now. It's possible (just like Linux on the desktop is), but given the history, my prior is to be skeptical. And it's possible we haven't yet seen the hit product (eg iPhone) that reshuffles the technological landscape.
Do I think WCs will disappear anytime soon? Certainly not. Do I think it might end up being part of plumbing underneath frameworks like React that nobody thinks or cares about? Possibly. On a 20-year time scale, will web technologies as a whole be disrupted? Possibly.
WebSQL never became a web standard because it never had a specification so that doesn't compare properly with Web Components. XHTML on the other hand does, and it's still supported. In terms of the wager, if Web Components goes the way of XHTML then I would still win that wager.
> Flash [...] 2000s was tiny by modern standards [...] I don't believe that "user installed base" is an important metric - "number of programmers deliberately writing software with it" provides the network effect.
Well there's two things here.
1. It's important to remember to focus on percentages rather than numbers because the total developers and users have changed. If we weren't looking at the percentages then we would end up with a skewed perception. (and since there were millions of web developers back then, we won't need to worry about sample size jitter/bias)
2. I agree that user installed base is not as useful a metric as a developer use base. So looking at flash's usage, it was 3 in 10 web developers (30%) compared to React's 1 in 4 web developers (25%). (fun aside: flash was used in at least 70% of games, 75% of video delivery methods and 98% of enterprise apps so for a bunch of areas it dominated)
> jQuery
I'm guessing I don't need to go through how this was used to make a standard working environment that standards bodies then recreated.
> "Web Components now" has been the "year of the Linux Desktop" refrain of the webdev community for a long time now.
No, just among clickbaiters. Web Components was a set of capabilities/standards wrapped up under an umbrella term. Here's a map of them: https://postimg.cc/87Ljbhdj
Web Components cannot currently replace React as a whole since not all of the standards are implemented yet. (the speed of implementation is partially due to browsers needing to change a lot of behind-the-scenes functionality to support them, but a lot of that work is done now leading to browser vendors porting existing functionality to web components)
However, a whole bunch of those standards are currently implemented meaning that depending on your use-case, Web Components are the best choice. (They're doing really well in enterprise right now, e.g. Google, Microsoft, Adobe, Salesforce, etc...)
We won't have a "year of", but as each standard on the umbrella becomes available we get a "this group of devs who needed this one thing" and a "that group of devs who needed just one thing" moving to web components.
I'm not in the US so I'm not sure longbets would work (AIUI it's set up to do some charitable-donation tax arbitrage that only works for US taxpayers and means you can only take your winnings via a US 503(c)?) but I'm up for that second bet if we can nail down the criteria a bit more.
(My reason is that I've seen standards come and go and have found e.g. old files easier to open when they're in nonstandard-but-popular-in-the-past formats than when they're in a standard format that didn't see wide adoption.)
I'm not in the US either but I'm sure someone will know how to make it happen, even if it goes to charity or something. (no crypto though)
I guess the second bet's criteria would depend on both the recommended practice for moving components today and the recommended practice in the future (which we don't know yet so it'd have to be done in good faith).
Currently, web components are designed to be portable so they can easily be ported between projects by copy-pasting a single hunk of code.
Whereas react components can be copy-pasted, but (as far as standard practice is concerned) require build systems and their dependencies (both of which rot over time) before they can be considered functional.
Aside: There's an argument to be made about the difficulty of migrating some web component based design systems (due to build systems and dependencies), but those difficulties that would be experienced are locked into the design system itself and would be experienced regardless of whether the design system was implemented with web components, react, vue, svelte, angular, lit etc... The bet is about an individual component and how easy it would be to port.
-----------------------------------
To respond to your reasoning, I feel that it's important to point out there is a difference between standards and web standards.
The pendulum of standards themselves may come and go, but web standards almost entirely swing towards the coming side. The going side is reserved almost entirely for newer standards that subsume older web standards so the older web standards are still supported.
Anyone can make a standard, but a web standard proposal doesn't become a web standard until it has become adopted and implemented. This means that web standard proposals can be thrown away without affecting web standards themselves.
It takes a black swan event to remove a web standard (e.g. spectre/meltdown leading to SharedArrayBuffer's removal).
When it comes to web standards, backwards compatibility is sacrosanct.
Consider this simple ES1 example code:
-----------------------------------
var person = {
name: "John",
age: 30,
sayHello: function() {
console.log("Hello, my name is " + this.name + ".");
}
};
console.log(person.name); // Output: "John"
person.sayHello(); // Output: "Hello, my name is John."
-----------------------------------
It still works.
Now try to picture this functionality implemented in "nonstandard-but-popular-in-the-past formats" like java applet, flash file, coffeescript and an old jquery plugin.
Would that code be more straight forward to make functional today than the web standard ES1 code above?
Now that question above doesn't neatly fit with your reasoning because you were comparing "nonstandard-but-popular-in-the-past formats" with "a standard format that didn't see wide adoption". I think we can both agree that ES4 was something that fit into the second bucket. And judging by your comments I think you would say that Web Components as they exist now would also fall into that second bucket.
> I'm not in the US either but I'm sure someone will know how to make it happen, even if it goes to charity or something. (no crypto though)
I'm not up for a charity thing - if we're betting I want to be able to win as well as lose - but if there's a way to do it then I'm down.
> I guess the second bet's criteria would depend on both the recommended practice for moving components today and the recommended practice in the future (which we don't know yet so it'd have to be done in good faith).
Right, yeah, happy to just say we look at it in good faith and reach a conclusion.
> Currently, web components are designed to be portable so they can easily be ported between projects by copy-pasting a single hunk of code.
> Whereas react components can be copy-pasted, but (as far as standard practice is concerned) require build systems and their dependencies (both of which rot over time) before they can be considered functional.
I don't think that's a huge difference; copy-pasting your dependency declarations and your implementation is not conceptually any harder than copy-pasting just your implementation. If the accepted dependency format changes, or your component needs custom build steps, then that might be a harder piece of porting (but I wouldn't consider a simple mechanical change like changing dependency notation from JSON to XML to be a significant burden).
I would go all-in.
Web Components is not (just) about technology, but about 4 companies working together on setting a standard.
Companies that used to fight in the Browser Wars now work together on the standard.
They are the WHATWG that took the role of the W3C HTML/Web workinggroup.
4 companies ... Apple, Google, Mozilla and Microsoft
And the WHATWG (for now) is "by invitation only"... note the big name missing.
They won't last longer than a react component (that's not even the claim the linked post is making); you can just use them in a different framework, if you care about that.
...which is the point the parent comment was making.
> code saved on laptops that hadn’t been turned on in a full decade. The more dependencies a website had, the more difficult it was to restore
is the crux for me. When I clone one of my Vue projects from a few years ago and try to run it, it is always broken. My (new) node version is incompatible with a Vue core library, then updating the core library breaks some other libraries and requires config file changes.
There's also the "React is the industry standard that tons of developers and companies use" vs. the "WebComponents is the 'official' standard that nearly nobody uses".
Yes, I'm being hyperbolic. But if you're worried about longevity I would certainly hitch my wagon to React before I hitched it to WebComponents.
Unfortunately I don’t think that comparison quite holds. jQuery is mentioned less and less because core browser APIs implemented a lot of what it does and made it unnecessary.
Even if Web Components solve the “create a component” part of React there’s still an absolute ton of stuff it provides that Web Components don’t. I tend to think of WC as a low level API you want a library interfacing with rather than your own code, e.g. the way Svelte exports web components.
If it's a choice between removing the JQuery dependency from old JQuery code, or updating equally old vanilla javascript, I'm going to be picking the first option a lot.
The point isn't that it's a standard, it's that it's implemented in browser (not in a framework), and is a lot closer to the web equivalent of "bare metal". There are less moving pieces that will break backwards compatibility in the next 10 years (is the hope)
> Web components get imported and registered at the global level. This also means if two different libraries have a component called my-button, you can’t use both of them.
In my opinion, fundamental problems like these really ought to be addressed before things become part of the web platform.
It's debatable if that's a fundamental problem. The entire Objective-C ecosystem was a flat namespace with prefixes too.
Web Components trace their history to trying to explain how the web platform itself works. HTML is also a flat namespace, and the goal was to empower developers to do all the same things the platform does and in the same way.
We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. And in practice with reasonable prefixing practices we find folks rarely (if ever) collide, the same as ObjC.
Thank you for your answer. It makes sense in a historical context.
But then, all languages since Objective-C seem to agree that namespacing is a good idea. There's no debate there. Even JavaScript has modules now. So I can't help but wonder what makes web components unique in this regard.
Programming languages, perhaps. HTML not a programming language, it’s markup. The best comparison I can think of is XML: it does have namespacing and in my experience it’s more annoying than not having it.
It’s really only annoying because it has exceedingly fussy semantics. And even then, it usually fades into background noise unless you’re using the exceedingly fussy semantics with minimal constraints. If you generally tend to use the same N set of namespaces and always use the same prefixes with them, it’s mostly just fine after you copypasta some boilerplate (or have tools do the boilerplate for you).
(Yeah I work with XML day to day, yeah I might have some amount of Stockholm Syndrome associated with that.)
> We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense.
Ah. I feel like the demos and examples that I've seen never have the first word as the pseudo-namespace so I had no idea that was the intention.
I thought this was going to be about shipping web components made with React, but it's about consuming web components from apps made with React, which is a much more sensible thing to do in my opinion
The problem with web components is that they've never had a templating/reactivity story, which means if you wanted to build one reactively you'd have to ship it with a framework, and shipping a separate framework per-component is just unworkable. So they don't make sense internally to an app, and they don't really make sense for a large library of components. They only really make sense for a single hand-crafted widget that a company wants to ship to various consumers who may be using different frameworks
My dream is still that browsers come up with an actual reactive-templating API for HTML. If they did that, we might finally be able to get rid of frameworks for many common use-cases
The good: this seems like a necessary step towards standards-based development
The worrying: we might be setting up for a scenario where newer developers are bewildered by mixed paradigms within what was (at least once upon a time) a simple library
Full disclosure I work for Mux (OP), so as a team we're web component fans, but I'm personally still almost exclusively writing React. So...personally, saying this with love, but add this to all the new esoteric hooks in React 19 and it feels like React might be losing the plot.
> this seems like a necessary step towards standards-based development
Which standards?
I keep saying: even web components people finally admitted that they need 20 more standards to solve issues (largely caused by web components themselves) that literally no other framework has: https://w3c.github.io/webcomponents-cg/2022.html
There's a reason very few frameworks (including the new ones) target web components by default and do their own thing. And their authors have been very clear as to why (think Svelte, Vue, Solid etc.).
just glancing over this doc, it seems like a lot of these are problems currently ignored by existing frameworks and solved by bundlers, and the remainder of them were problems that each framework addressed independently after years of development
> t seems like a lot of these are problems currently ignored by existing frameworks
They are not ignored. They just don't exist or, indeed, are solved by other, better means (or indeed better web specs like CSS scoping etc.). Let me quote directly from the doc:
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- start quote ---
To put simply, "many of these problems exist only because web components exist, and they are so bad that developers actively avoid web components and seek other solutions".
Here is a list of issues that literally don't exist anywhere except web components (so there's nothing to ignore):
- Composed Selection
"Since existing Selection APIs can represent only a single selection in a document, bound to a single Range, the need for an API to represent ranges over a composed tree has been generally acknowledged since at least 2015."
- Constructable Stylesheets & adoptedStyleSheets
The only way for web components can share stylesheets without duplicating them
- Cross-root ARIA
"Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM."
- CSS Properties and values inside shadow root
- Anything related to declarative templates: Declarative CSS Modules, Declarative Custom Elements, Declarative Shadow DOM
- DOM Parts
"Enable batched updates to the DOM, usable by library/framework view engines."
This is actually useful. Why the hell it's tied to Web Components? No one knows. But yeah, all/most frameworks have a solution to this, and web components are useless as a foundation for web frameworks without it
- Form-Associated Custom Elements
Yup, you still can't make a custom button that behaves like a submit button in web components
- Lazy custom element definitions
Web components are eagerly rendered whether you want it or not. I don't think there's a single framework that doesn't have lazy loading/rendering/rendering on demand
Im not a front end dev but from what Ive read it seems like ES6 and native web components solve a lot of the problems react was originally trying to solve.
So is react losing the plot or just naturally it's ideas are being folded into the browser natively?
The number 1 problem React was created to solve is synchronizing state with UI (FB chat originally). Web Components don't provide any solution to this problem.
Any time I try not to use React and just go vanilla, the main frustration is how much time I waste being imperative with UI state and event listeners and such. I don’t fricking want to manually manage all the pieces! That’s the least interesting part of developing software.
I agree, but I would also say that it took a loooooong time IMO for react to get good global state management. IMO Redux was generally a disaster - a big overcomplication with lots of unnecessary conceptual pieces - actions/reducers/selectors etc., and I've yet to see a Redux front end that didn't turn into an incomprehensible mess.
All I really wanted was just `useState()` but for a piece of state that can be shared between components. I think that exists now in easy-to-use libraries like jotai and zustand, but it certainly took a while to get there. In retrospect I don't think this is that uncommon (overcomplicating something at first and then just simplifying it to the few core things people want) - graybeards like me may remember some of the original EJB horrors.
Yeah that's the challenge with front end opinions - there's still a lot of folks who want to write code that way (even when using frameworks), then bitch about "too much magic!", etc. I'm with you that I do not want to deal with all that, give me a mental model of state->UI and I'm good.
This is not true. Web Components are extremely barebones and featureless. There’s no built-in way to do data dependencies, reactivity, etc. They’re also quirky, eg theres properties and attributes and they sort of correspond but haha not really. And because they’re globally registered, even composability works less well than in React.
All of this has “just worked” with React since it very first release.
Web Components are great for distributing components. Not for building the internals of an app. In fact, for moderately complex web components it often pays to build the internals of the web component with a framework like React or Svelte.
I wouldn't use a web browser made by facebook for the same reason I don't use a browser made by google. Both are big companies that aim to know everything about you.
One of the biggest problems I run into with Web Components is how to share common CSS styles between them. I understand that goes against the idea that each web component should be encapsulated, but sometimes this is desirable.
Say you have a component library where each component depends on a base set of styles and you don't want to load duplicate styles for each component.
Alas that Web Components will be forever held back from their true potential until WebKit pulls their obstinate finger out and implements the customised built-ins half of the standard. Or proposes something better that otherwise solves the content model issues. To date they have done neither, leaving us with a shortfall of composability and a fistful of janky polyfills
> They have proposed it. They have also explained [cut]
That is laughable. I've been following this since finding that my code extending built-in elements for progressive enhancement in the Hotwire framework was dead in the water on Safari and no polyfill could resuscitate it because the browser infrastructure was fundamentally missing. In reality, Apple have sat on the pot groaning for a decade without taking a dump, and the stated reason in 2016 was this, entirely:
rniwa> The problem here is that UA internally checks local name e.g. `element.localName == aTag` to do various things, and all of that code needs to be updated to account for the fact there could be an instance of `HTMLAnchorElement` whose local name is not `a`.
Thus frankly placing it in the too-hard-basket, a refreshing piece of honesty from a company that's usually in love with its own bullshit. You don't have to look hard at the WebKit source code to grok that, yes, it surely would require a massive chunk of refactoring. Still, here's the updated response, from 2023, after a flamebait thread on WebKit/standards-positions that attracted a mountain of withering criticism:
rniwa> The position has been established.
[WebKit locked as off-topic]
Which I took to mean, "all of you whinging bastards can get fucked, it's our browser".
So it's fundamentally an effort-reward gap for Apple that has become a dug-in entrenched position over time as more product managers flail around hoping to justify it. Pretending an obviously commercial/resourcing decision is due to <bunch of technical reasons> is a common way to avoid committing resources, but any engineer who actually believes that fiction is a damn fool. I'm reminded of Cisco's hissy fit with the IEEE over PoE. Apple aren't dumb enough to miss that refusing to implement part of a published standard erodes their claim of stewardship over that standard, and if a major customer really wanted it, they'd flip-flip in a heartbeat.
> Tell me you know nothing about the topic without telling me that
> But that doesn’t exist in the web components world (at least not yet). When you use <my-button> in a React component, you don’t have to explicitly import my-button from anywhere inside that file.
Technically you can just export a string with the name of your web component:
But you do have to make sure there is no name clash. And since this is more of a convention any web components libs you pick up will probably not do this.
In my 13 years there are a lot of technologies I've never used. Maybe there was opportunities where you could have, or maybe things are working just fine for the problems you're solving and you don't need it, which is fine too.
The example I see all the time is creating design systems and dumb components but the major benefit is its a standard that work everywhere and isn't tied around a particular framework (hem react).
The point is that browsers will do a lot of work that JavaScript frameworks might need to do now, enabling framework developers to make their frameworks simpler, and their execution faster.
And yet, very few frameworks use them as their foundation because they don't actually do any of the work that frameworks/libraries actually do, and introduce a ton of issues (some of them unresolvable).
Well, because of the true encapsulation, which solves real problems when looking at a global web level which you should do if you make a browser wide component framework, it becomes harder to do things that are simple if you have a global DOM like in the traditional component frameworks.
So a new way of dealing with certain problems is required, which requires a mindset change. For most developers it doesn't add value right away to break out of their framework cage and share their components with each other. But eventually we will all benefit from web components because they will work in any environment without them ever breaking. You won't be able to say that about traditional framework components.
> So a new way of dealing with certain problems is required, which requires a mindset change.
It's not a new way (components is not a new idea), and no, it doesn't require a mindset change (again, components are not a new idea).
Web Components have so many issues that they are nearly useless to frameworks, and Shadow DOM is the cause of many of those issues.
> For most developers it doesn't add value right away to break out of their framework cage and share their components with each other.
Ability to share components has nothing to do with suitability of web components for frameworks/libs.
> But eventually we will all benefit from web components because they will work in any environment without them ever breaking.
Except they are breaking a11y, selections, forms; they can't be lazily rendered; they cause waterfall HTTP requests; they...
Well, they literally need 20 more web standards (on top of a dozen or so existing ones) to fix issues that no frameworks have, and many of which exist only because of web components themselves: https://w3c.github.io/webcomponents-cg/2022.html
The only useful web spec that may come out of this slow moving train wreck is DOM Parts which enables batched updates to the DOM. And even then it depends on how blind the spec authors are to the actual needs of developers. And up until 2022 they weren't just blind, they were intentionally and militantly blind.
You know I think you have interesting arguments, but at the same time I feel like somehow you are just very anti web components, and want to break them down. I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework, in the sense that you shouldn't break current standards. I believe the committees of the creation of the standards spend a lot of time to come to consensuses. That is not easy with the web today. So these standards evolve very slowly and take many iterations to become mainstream in a world that is already used to the common frameworks. And I think that for most new projects it's still a sensible choice to go for the common frameworks.
But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser, so that the web basically becomes more native. And that can be implemented as a new possibility alongside the common frameworks. And those frameworks can even adapt to it.
You seem to know a lot about and be very engaged with this subject. Maybe instead of breaking it down you could help make it better? I'm personally not involved with the web component development, but I find their ideas interesting and worthwhile exploring. Web standards evolve slow but stay long. It's good to know what's coming.
> You know I think you have interesting arguments, but at the same time I feel like somehow you are just very anti web components
Yes, I am, hence the arguments.
I'm not the only one against them. There are multiple reasons why even the people who originally modeled their frameworks after web components and were very pro-web components are not at best completely indifferent towards them: Svelte, Vue, Solid JS.
> I understand you're issues with it, but I also think that implementing web standards is a different thing from a framework
Yes, yes, it is a very different thing, and that's why you should be very careful when implementing anything, and listen to people who have to deal with these standards.
People working on these standards would ignore, berate, denigrate and gaslight anyone who would point out glaring and obvious issues with the design of web components. They would throw more and more standards at the problem trying to patch holes that were caused by the design of web components.
In 2022 they finally relented, sat down and wrote what more is needed to bring web components barely on par with existing userland solutions. And admitted that many of the issues that still need to be solved are the direct result of their design.
> But at the same time I also feel like we should be engaged in a positive way with making certain patterns more integrated with the browser
People have tried to do that. As I say, they were ignored, belittled and gaslighted. The people who were the most vocal proponents are now at best indifferent and will not touch web components with a 10-mile stick.
Having worked with internal company web components, I despise them. In a bureaucracy, bad and buggy web components are a blight because, unlike a bad React component,ad hoc fixing them requires a mess of searching and tons of boilerplate. I accept this news with mourning.
I love the idea of web components, I just wish slots weren't tied to shadow DOM.
Anecdotally it feels like they arrived right as headless/self-styled component libraries started to pick up steam, and things inverted to the point that not being able to have your "external" styles easily apply to the component became more of a problem than them being affected by random stray styles.
Maybe I am missing what you mean, but I think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components.
I wonder if that is the true reason OLE type systems have failed on the web, as there aren’t enough agreed upon preexisting widgets for it not to descend into an inconsistent horror show.
> think there is a clear tension between the component desire for encapsulation vs the web designer wanting to impose their styling on the nested components
This is the inherent tension. It requires good web component authoring to expose:
1. `part`s that can be accessed by application-level CSS
2. slots for the application developer to inject html
3. CSS custom properties (--variable) -- these pierce the shadow DOM
The web component authors have to be very intentional about these things. There are good examples and bad examples and I think people are still learning how to do this well.
Isn’t the problem that this is recursive? i.e. if you use a component which itself contains a component that contains a button and that button should be styled should the intermediate components be worrying about it? And does the end consuming application need to care when new widgets are added to components nested two deep?
It is almost like the need for styling necessitates all the old dependency injection and factory gunk that older frameworks became notorious for.
By default the drawer component has an "X" button in the header to close it. If you want to override that, instead of trying to style the nested "X" button you can pass in your own header actions with slot="header-actions"
and you won the prize. web components are being rushed because it's getting too easy to use the internet without JavaScript thanks to the SSR crazy. and no JS is not good for google business
(author here) I think the problem might be more around bureaucracy mixed with bad & buggy code than it is a specific problem with web components. Can you expand on that?
Thanks, I think you're 100% right, it's the red tape more than the tech. My issue is that when an in house React component is poorly coded, it's trivial to inject css overrides or select internal elements of the component to change it's behavior. With web components, the events emitted are locked in, each sub element or worse sub web component is nested away and only accessible via the shadow dom making edge case or hot fix solutions that much more trouble to deal with. In both cases the ideal would be for the internal library maintainers to fix the issues or support the required features, but with ever long lead times, it's often necessary to work something out at the project level. The working out is much more abrasive with web components though.
In practice, this update is great for usability. But it's a sign that web components are still relevant, extending my time dealing with poorly built ones.
I see. Particularly with CSS there's more of an enforced contract around how the element internals get exposed for styling. If the element hasn't exposed `parts` or slots it's hard to hack around it.
More broadly speaking I have found myself getting thrashed by the ever evolving "best practices" in the React ecosystem. First: write everything using class components, and then a couple years later everything should be written with hooks.
I think the benefit of web components (for certain things) is that the APIs and the standards move slowly. Something you write today isn't going to feel obsolete in only a couple years.
If you need an equivalent Expedient Field Hack for a web component, remember it's an HTMLElement subclass and ends up in the DOM. So you can get the object back out of the DOM as 'just another internal element' and gutwrench it from there (or, depending, subclass it and register your subclass, or insert an extra entry into its prototype chain, or ...).
I mean, yes, those are all horrible, but so's digging into the guts of a react component you don't own, sometimes taking a dependency on the internals of somebody else's code is the least horrible option.
... it occurs to me that given a JS Function's .toString() returns the source code, on an e.g. lit-html component you could probably even grab the render function, yank the html`...` call out of it, regexp that to tweak the mark up, and then use an indirect eval to stuff it back in.
But really, I think "you now have the element object, monkey patch it to taste" is probably quite sufficient and far, far less ridiculous than that last paragraph, I just couldn't resist sharing the horrifying thought :)
Yeah, worth noting that there IS an escape hatch for monkey-patching (at your own risk). So you're not totally out of luck. It is just HTMLElement all the way down
I'm in a similar boat. I have to use a 3rd party component library written in web components for our react app (esri/calcite-components) and it's a huge pain because
* You can't override styles except what is exposed through css variables
* They often encapsulate some internal logic which I can't control from React (tbh this could happen with a React library too)
Having worked with both internal company web components and internal company jquery-based components, I vastly prefer the former.
Yes, ad-hoc fixing styles and behavior from the outside is nice. But when every internal style/class/element is technically part of the API surface, you quickly end up with extremely brittle code.
Suddenly every tiny change (bug fixes, refactors, new feature) in the component library has the potential to break the app in unexpected ways, and the result is an inability to upgrade. Happens all the time.
With shadow DOM, this problem basically go away (depending on how it’s implemented)
It shouldn't there's a lot of ways to use web components anyone with years of experience with objective programming should feel extremely at home. Where as react requires a lot of unnecessary overhead associated with security risks.
In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.