3 ms·

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 b

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.
    - gedy 2y ago
      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.
    - hn_throwaway_99 2y ago
      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.
- deleted 2y ago
  [deleted]
- skrebbel 2y ago
  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.
troupo 2y ago
> 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 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.).
- ruined 2y ago
  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
  - troupo 2y ago
    > 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 - Open styling of shadow roots - Styling children of slotted content - Theming

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.
  - gedy 2y ago
    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.
  - hn_throwaway_99 2y ago
    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.
deleted 2y ago
[deleted]
skrebbel 2y ago
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.

troupo 2y ago

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

ruined 2y ago
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
- troupo 2y ago
  > 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 - Open styling of shadow roots - Styling children of slotted content - Theming