3 ms·

I love this. As a big native web components fan, I've been mystified about the popularity of react. It, like angular, solved a problem that definitely existed

I love this. As a big native web components fan, I've been mystified about the popularity of react. It, like angular, solved a problem that definitely existed prior to the custom elements spec. But with custom elements and your favorite rendering library (lit-html, jsx, whatever) I really haven't seen a powerful technical argument for react, other than the ecosystem.

kevmo314 1y ago
The ecosystem really is the main argument. If you want to hire developers who can work productively in your codebase, part of that is being able to match their expectations of what the code looks like. React standardizes your codebase, even if the standard produces complex code.
- FpUser 1y ago
  There is no shortage of developers who can understand Java Script and general application development concepts. And why would I ever want to hire a person who can only be productive in confines of single framework.
- claytongulick 1y ago
  Sure, but when I balance all the factors, bundle size, performance, weird ecosystem stuff like redux, framework churn, and debuggabilitiy I still scratch my head. Every react team I've migrated over to WC have picked it up within a couple days, and I've had universally positive feedback on the change. Also, the web components ecosystem is pretty dang good these days. Between ionic, shoelace, and all the others, there aren't really any functional gaps that I've seen. I think at this point it just has momentum, and people just go with what they know.
p4ul 1y ago
I feel like "other than the ecosystem" is doing quite a bit of work here.
- claytongulick 1y ago
  For sure, and that's the primary valid technical argument. I've never really been a big one for that particular argument though. I've seen the same argument made about Cold Fusion, flash, flex, visual basic, asp server controls, jquery, dojo, moo tools, backbone, and many others.
FpUser 1y ago
Same here. All my front ends for business apps are bunch of native web components, some libs and some core managing business logic. All pure Java Script. Works like a charm, no build needed.
doradoblank 1y ago
Web components are neat but they don't solve the problem React solves. React provides a simple mental model for managing client state, which is the one of the main challenges in frontend. It's basically, "re-render everything when one of your dependencies changes" -- and that's extremely easy to understand and reason about. It incurs significant performance overhead, but your app has to be fairly large before you start running into meaningful perf issues.
- claytongulick 1y ago
  My style with web components solves it really well. Just have each component maintain it's own state. Class setters work great. If you need the component to update, just call render() in the setter. It's super simple, encapsulates logic, and brain-dead simple to debug. You know exactly where to go for everything: the component. I've always felt like react's approach to state management was creating more problems than it solves.
  - doradoblank 1y ago
    How do you handle state that affects multiple components? Like a filter button that affects a list table. In React you just hoist the state up and make both components dependent. If you're managing all state via internal component state, then you need to explicitly pass state between the components. That's okay for simple cases, but in my experience it breaks down pretty quickly. Once you have more than a few components involved, you end up writing your own state reconciliation.
    - gitaarik 1y ago
      That's why I wrote Lit State, a simple state management lib to use in combination with Lit, a simple web components lib. It works really simple, and it's simple to use. Much more intuitive than React. https://github.com/gitaarik/lit-state https://github.com/gitaarik/lit-state
    - claytongulick 1y ago
      There are a few different ways. One really easy way is to put a custom element at the root of the dom and just add/remove event listeners, maybe one-shot if that's all you need. I also have a convenient little library called ApplicationState [1], which basically does the same thing but can persist state in indexdb. Lots of other libraries out there too. [1] https://claytongulick.github.io/applicationstate/ https://claytongulick.github.io/applicationstate/
ggregoire 1y ago
For me it's about productivity. I can code anything in react without opening the doc once, cause it's javascript and useState/useEffect. Zero pain points. I can focus 100% on delivering features. I can't comment on web components but I worked with Angular for 2 years a decade ago and I was always in the docs wondering what's the syntax to render a list or what's the function to do even the simplest things. Same with Backbone.js before Angular.
- iammrpayments 1y ago
  Completely opposite experience for me and when I used to write React I’d avoid useEffect like the devil.

kevmo314 1y ago

The ecosystem really is the main argument. If you want to hire developers who can work productively in your codebase, part of that is being able to match their expectations of what the code looks like. React standardizes your codebase, even if the standard produces complex code.

FpUser 1y ago
There is no shortage of developers who can understand Java Script and general application development concepts. And why would I ever want to hire a person who can only be productive in confines of single framework.
claytongulick 1y ago
Sure, but when I balance all the factors, bundle size, performance, weird ecosystem stuff like redux, framework churn, and debuggabilitiy I still scratch my head. Every react team I've migrated over to WC have picked it up within a couple days, and I've had universally positive feedback on the change. Also, the web components ecosystem is pretty dang good these days. Between ionic, shoelace, and all the others, there aren't really any functional gaps that I've seen. I think at this point it just has momentum, and people just go with what they know.

p4ul 1y ago

I feel like "other than the ecosystem" is doing quite a bit of work here.

claytongulick 1y ago
For sure, and that's the primary valid technical argument. I've never really been a big one for that particular argument though. I've seen the same argument made about Cold Fusion, flash, flex, visual basic, asp server controls, jquery, dojo, moo tools, backbone, and many others.

FpUser 1y ago

Same here. All my front ends for business apps are bunch of native web components, some libs and some core managing business logic. All pure Java Script. Works like a charm, no build needed.

doradoblank 1y ago

Web components are neat but they don't solve the problem React solves. React provides a simple mental model for managing client state, which is the one of the main challenges in frontend. It's basically, "re-render everything when one of your dependencies changes" -- and that's extremely easy to understand and reason about. It incurs significant performance overhead, but your app has to be fairly large before you start running into meaningful perf issues.

claytongulick 1y ago
My style with web components solves it really well. Just have each component maintain it's own state. Class setters work great. If you need the component to update, just call render() in the setter. It's super simple, encapsulates logic, and brain-dead simple to debug. You know exactly where to go for everything: the component. I've always felt like react's approach to state management was creating more problems than it solves.
- doradoblank 1y ago
  How do you handle state that affects multiple components? Like a filter button that affects a list table. In React you just hoist the state up and make both components dependent. If you're managing all state via internal component state, then you need to explicitly pass state between the components. That's okay for simple cases, but in my experience it breaks down pretty quickly. Once you have more than a few components involved, you end up writing your own state reconciliation.
  - gitaarik 1y ago
    That's why I wrote Lit State, a simple state management lib to use in combination with Lit, a simple web components lib. It works really simple, and it's simple to use. Much more intuitive than React. https://github.com/gitaarik/lit-state https://github.com/gitaarik/lit-state
  - claytongulick 1y ago
    There are a few different ways. One really easy way is to put a custom element at the root of the dom and just add/remove event listeners, maybe one-shot if that's all you need. I also have a convenient little library called ApplicationState [1], which basically does the same thing but can persist state in indexdb. Lots of other libraries out there too. [1] https://claytongulick.github.io/applicationstate/ https://claytongulick.github.io/applicationstate/

ggregoire 1y ago

For me it's about productivity. I can code anything in react without opening the doc once, cause it's javascript and useState/useEffect. Zero pain points. I can focus 100% on delivering features. I can't comment on web components but I worked with Angular for 2 years a decade ago and I was always in the docs wondering what's the syntax to render a list or what's the function to do even the simplest things. Same with Backbone.js before Angular.

iammrpayments 1y ago
Completely opposite experience for me and when I used to write React I’d avoid useEffect like the devil.