13 ms·

Facebook just updated its relationship status with Web Components

134 points by mmcclure 2y ago

j-bos 2y ago
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.
- kristiandupont 2y ago
  I haven't used them. Why does "ad hoc fixing" require searching and boilerplate?
  - toasted-subs 2y ago
    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.
    - kristiandupont 2y ago
      >Where as react requires a lot of unnecessary overhead associated with security risks. Such as what?
- mmcclure 2y ago
  I'm not following, what makes a poorly written React component better than a poorly written web component?
  - j-bos 2y ago
    When your company requires using them, it's more straightforward adjust the styles and event handling of a react component than a web component.
- toasted-subs 2y ago
  Oh please. If we are going to complain about anything free and built into the standard it would be server side events which barely work at best. Personally I wouldn't mind server rendered features like what react does but in the setting of not javascript.
- dylanjha 2y ago
  (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?
  - j-bos 2y ago
    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.
    - dylanjha 2y ago
      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.
    - mst 2y ago
      > select internal elements of the component 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 :)
- deergomoo 2y ago
  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.
  - fidotron 2y ago
    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.
    - dylanjha 2y ago
      > 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.
      - fidotron 2y ago
        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.
- bobby_table 2y ago
  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)
- wordofx 2y ago
  I would rather take web components than deal with react any day of the week. Never seen a good react implementation. The only issue with web components is shadow dom makes styling a pain so you need to work without the shadow dom and implement slots yourself.
- CornCobs 2y ago
  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)
danielrhodes 2y ago
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.
- dylanjha 2y ago
  (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.
- spartanatreyu 2y ago
  > I don't think there's any inherent upside to using Web Components over React. The upside is that web components will last longer than react components. There was a great blog post about this very thing and why someone chose them over react components in their use case (making their code migration-proof across updates and stack changes): https://jakelazaroff.com/words/web-components-will-outlive-your-javascript-framework/ https://jakelazaroff.com/words/web-components-will-outlive-y...
  - wokwokwok 2y ago
    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.
    - djbusby 2y ago
davekiss 2y ago
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.
- CharlesW 2y ago
  Interesting. As a not-React user, it feels like a very positive thing that the framework is keeping up with alternatives like Vue (https://vuejs.org/guide/extras/web-components https://vuejs.org/guide/extras/web-components) and Svelte (https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api) in terms of standards support.
- the_real_cher 2y ago
  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?
  - sesm 2y ago
    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.
    - Waterluvian 2y ago
      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.
dbbk 2y ago
In 18 years I have never once actually used a Web Component. What is the point?
- dylanjha 2y ago
  Not everyone has to use everything. 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.
  - deleted 2y ago
    [deleted]
- deleted 2y ago
  [deleted]
- barkbyte 2y ago
  They didn’t exist for the first 8 of those years and didn’t have real support until even later so…
- mickael-kerjean 2y ago
  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).
- gitaarik 2y ago
  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.
  - troupo 2y ago
    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).
daxfohl 2y ago
Embrace, extend, extinguish?
- daxfohl 2y ago
  Eh, probably not. It's not like web components are a big threat to react. Nor that react is any kind of a profit driver anyway.
continuational 2y ago
> 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.
- esprehn 2y ago
  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. (Not that things couldn't be better: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...)
  - jamesfinlayson 2y ago
    > 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.
  - continuational 2y ago
    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.
    - 2y ago
brundolf 2y ago
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
c_s_guy 2y ago
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. Is there a best practice around this yet?
- virtualbluesky 2y ago
  Importing a common https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleShe... CSSStyleSheet and adding it inside the web component constructor might help?
- gitaarik 2y ago
  With Lit it's easy: https://lit.dev/docs/components/styles/#inheriting-styles-from-a-superclass https://lit.dev/docs/components/styles/#inheriting-styles-fr... https://lit.dev/docs/components/styles/#sharing-styles https://lit.dev/docs/components/styles/#sharing-styles Already quite some time ago I made a little library which makes this easy: https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style
_akhe 2y ago
Why hasn't Facebook made a browser that runs React/JSX as native code? Should work well for their ad business. Make a Llama 3 based search as the home page :) And fully support AI/LLMs in the browser :)
- croes 2y ago
  Google would kill it.
  - 1oooqooq 2y ago
    they wouldn't know how since it would be based on chrome and lie in the user agent string. the irony.
- werdnapk 2y ago
  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.
  - _akhe 2y ago
    You might not, but the boomers are going to love it. Wait til they find out about LLMs. We're fucked actually.
  - deleted 2y ago
    [deleted]
inopinatus 2y ago
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
- troupo 2y ago
  > Or proposes something better that otherwise solves the content model issues. They have proposed it. They have also explained why the existing proposal for customisable built ins is a loaded gun waiting to explode. > To date they have done neither Tell me you know nothing about the topic without telling me that
  - deleted 2y ago
    [deleted]
  - deleted 2y ago
    [deleted]
  - inopinatus 2y ago
    > 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 Aw, you're gonna hurt my feelings.
DanielHB 2y ago
> 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: export const MyButton = 'my-button' import MyButton from './MyButton' ... return <MyButton /> 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.

134 points by mmcclure 2y ago

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.

kristiandupont 2y ago
I haven't used them. Why does "ad hoc fixing" require searching and boilerplate?
- toasted-subs 2y ago
  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.
  - kristiandupont 2y ago
    >Where as react requires a lot of unnecessary overhead associated with security risks. Such as what?
mmcclure 2y ago
I'm not following, what makes a poorly written React component better than a poorly written web component?
- j-bos 2y ago
  When your company requires using them, it's more straightforward adjust the styles and event handling of a react component than a web component.
toasted-subs 2y ago
Oh please. If we are going to complain about anything free and built into the standard it would be server side events which barely work at best. Personally I wouldn't mind server rendered features like what react does but in the setting of not javascript.
dylanjha 2y ago
(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?
- j-bos 2y ago
  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.
  - dylanjha 2y ago
    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.
  - mst 2y ago
    > select internal elements of the component 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 :)
deergomoo 2y ago
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.
- fidotron 2y ago
  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.
  - dylanjha 2y ago
    > 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.
    - fidotron 2y ago
      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.
bobby_table 2y ago
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)
wordofx 2y ago
I would rather take web components than deal with react any day of the week. Never seen a good react implementation. The only issue with web components is shadow dom makes styling a pain so you need to work without the shadow dom and implement slots yourself.
CornCobs 2y ago
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)

danielrhodes 2y ago

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.

dylanjha 2y ago
(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.
spartanatreyu 2y ago
> I don't think there's any inherent upside to using Web Components over React. The upside is that web components will last longer than react components. There was a great blog post about this very thing and why someone chose them over react components in their use case (making their code migration-proof across updates and stack changes): https://jakelazaroff.com/words/web-components-will-outlive-your-javascript-framework/ https://jakelazaroff.com/words/web-components-will-outlive-y...
- wokwokwok 2y ago
  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.
  - djbusby 2y ago

davekiss 2y ago

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.

CharlesW 2y ago
Interesting. As a not-React user, it feels like a very positive thing that the framework is keeping up with alternatives like Vue (https://vuejs.org/guide/extras/web-components https://vuejs.org/guide/extras/web-components) and Svelte (https://svelte.dev/docs/custom-elements-api https://svelte.dev/docs/custom-elements-api) in terms of standards support.
the_real_cher 2y ago
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?
- sesm 2y ago
  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.
  - Waterluvian 2y ago
    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.

dbbk 2y ago

In 18 years I have never once actually used a Web Component. What is the point?

dylanjha 2y ago
Not everyone has to use everything. 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.
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
barkbyte 2y ago
They didn’t exist for the first 8 of those years and didn’t have real support until even later so…
mickael-kerjean 2y ago
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).
gitaarik 2y ago
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.
- troupo 2y ago
  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).

daxfohl 2y ago

Embrace, extend, extinguish?

daxfohl 2y ago
Eh, probably not. It's not like web components are a big threat to react. Nor that react is any kind of a profit driver anyway.

continuational 2y ago

> 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.

esprehn 2y ago
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. (Not that things couldn't be better: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal...)
- jamesfinlayson 2y ago
  > 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.
- continuational 2y ago
  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.
  - 2y ago

brundolf 2y ago

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

c_s_guy 2y ago

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. Is there a best practice around this yet?

virtualbluesky 2y ago
Importing a common https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleSheet https://developer.mozilla.org/en-US/docs/Web/API/CSSStyleShe... CSSStyleSheet and adding it inside the web component constructor might help?
gitaarik 2y ago
With Lit it's easy: https://lit.dev/docs/components/styles/#inheriting-styles-from-a-superclass https://lit.dev/docs/components/styles/#inheriting-styles-fr... https://lit.dev/docs/components/styles/#sharing-styles https://lit.dev/docs/components/styles/#sharing-styles Already quite some time ago I made a little library which makes this easy: https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style

_akhe 2y ago

Why hasn't Facebook made a browser that runs React/JSX as native code? Should work well for their ad business. Make a Llama 3 based search as the home page :) And fully support AI/LLMs in the browser :)

croes 2y ago
Google would kill it.
- 1oooqooq 2y ago
  they wouldn't know how since it would be based on chrome and lie in the user agent string. the irony.
werdnapk 2y ago
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.
- _akhe 2y ago
  You might not, but the boomers are going to love it. Wait til they find out about LLMs. We're fucked actually.
- deleted 2y ago
  [deleted]

inopinatus 2y ago

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

troupo 2y ago
> Or proposes something better that otherwise solves the content model issues. They have proposed it. They have also explained why the existing proposal for customisable built ins is a loaded gun waiting to explode. > To date they have done neither Tell me you know nothing about the topic without telling me that
- deleted 2y ago
  [deleted]
- deleted 2y ago
  [deleted]
- inopinatus 2y ago
  > 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 Aw, you're gonna hurt my feelings.

DanielHB 2y ago

> 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: export const MyButton = 'my-button' import MyButton from './MyButton' ... return <MyButton /> 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.