4 ms·

I love React. It feels foundational somehow. It's also vindicating after toiling for years on bloated frameworks. Declaratively describe your UI, React paints i

I love React. It feels foundational somehow. It's also vindicating after toiling for years on bloated frameworks. Declaratively describe your UI, React paints it. That's it. No app state management. No routing. No learning yet another templating system (which inevitably morphs into a shitty programming language). Just full JS(X optional). No grokking convoluted, bespoke abstractions. It's clean, narrowly scoped, and as simple as possible (but not simpler). Having recently worked on two legacy apps -- one ASP.NET, one Angular -- it made me deeply appreciate React and how far UI tech has come. Phenomenal work from the React team on more optimizations via this compiler. Good article too.

azangru 2y ago
Same would be true for: - Preact (like react, but tiny) - Solid (like react, but tiny and without the stupid re-rendering, or the stupid rules of hooks) - Lit (like react; but tiny, based on the browser-native web components, and with a class-based api) Considering that React has a virtual dom, a separate templating language (jsx), and now also a compiler, I would not call it simple.
- mock-possum 2y ago
  God I love Lit. I wish more outfits were running it, templating in ‘lit-html’ is such a good experience.
smarkov 2y ago
> Declaratively describe your UI, React paints it. That's it. No app state management. "that's it" does not paint the full picture. Yes, UI = function(state) is very convenient but the way React implements it inverts the problem. Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.
- willsmith72 2y ago
  No, you don't. React does.
  - LegionMammal978 2y ago
    I think I get what GP means. Without very judicious use of useMemo, you can't move a piece of state into an outer component without causing the rest of its children to also be re-rendered when the state is changed. I recall having to fiddle around with useRef at least a few times due to this, to avoid lots and lots of useMemo churn.
    - willsmith72 2y ago
      But that's the whole point of react compiler, which is the whole point of the post we're talking under
    - yunohn 2y ago
      Have you tried wrapping component exports with memo? That basically solved everything for me. It’s the equivalent of functional components from before hooks. > export default memo(ExampleComponent)
- bastawhiz 2y ago
  > Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update. That's literally the point of React Compiler
nox101 2y ago
This is not my experience at all. I write some visualization. I want to add a UI to tweak the numbers. I add React. React requires me to re-write all of my state for its `setState` stuff.
- Rohansi 2y ago
  State management is the worst part of React IMO. Basic things with `useState` aren't too bad but as soon as things get a bit more complex you need to reach for a separate library to make it easier. Unfortunately all of the popular options make use of weird patterns like reducers. I ended up rolling my own state management that lets you just write a normal JS class with normal fields and methods and use that for accessing and modifying your state. No reducers, atoms, stores, etc... Just a JS class for your state and logic. https://github.com/facepunch/react-class-model https://github.com/facepunch/react-class-model
  - PaulHoule 2y ago
    One trouble I see with React is that it doesn't have a complete answer to state management. I was building very complex AJAX apps around 2006 or so such as knowledge graph editors and decision support software using tools like GWT and Silverlight that had the same async comm as Javascript and was developing state management systems that were so far ahead of React, Vue and that sort of thing that when I came across those frameworks I was seriously disappointed. I've got the feeling that I can render anything I want the way I want with React (even 3-d worlds!) but the only framework that comes close to what my old systems could do is https://mobx.js.org/README.html https://mobx.js.org/README.html and I cannot understand why MobX isn't more popular than it is. (Worked fine for a websocket-based app to control my smart speakers, it was trivial to make it so adjusting the speaker volume through the mobile app or buttons was reflected on my web app. Never tried a bigger app)
    - nox101 2y ago
      MobX can be slow. Example for me, and maybe I just did it wrong. Made a photo gallery viewer (so a page of a few hundred thumbnails). Have options in the toolbar for whether to show the filename, date, location, on each thumbnail. Use MobX to make those settings reactive. Result, it runs way way way too slow since each of the hundred thumbnails is doing some complicated check to read the value of the reactive state variables. I can fix that by having some higher level component (like the thumbnail gallery) read the value and then pass it down to all the thumbnails. But, the point is, I had to work around the fact that it's slow rather than just do the obvious thing and have each thumbnail look at the state it's interested in and not have to have higher level components deal with it. In other words, I want to be able to add features to Thumbnail without having to modify ThumbnailCollection but because it was too slow I now have to modify two places (or 3 or 4) instead of one.
jmull 2y ago
> No learning yet another templating system (which inevitably morphs into a shitty programming language). React has yet another templating language. Sounds like we agree that JS isn't a shitty programming language, but that's hardly unique to react.
- throwAGIway 2y ago
  React doesn't have a templating language, React has syntax sugar for JS function calls - a very significant difference especially when you add TypeScript.

azangru 2y ago

Same would be true for: - Preact (like react, but tiny) - Solid (like react, but tiny and without the stupid re-rendering, or the stupid rules of hooks) - Lit (like react; but tiny, based on the browser-native web components, and with a class-based api) Considering that React has a virtual dom, a separate templating language (jsx), and now also a compiler, I would not call it simple.

mock-possum 2y ago
God I love Lit. I wish more outfits were running it, templating in ‘lit-html’ is such a good experience.

smarkov 2y ago

> Declaratively describe your UI, React paints it. That's it. No app state management. "that's it" does not paint the full picture. Yes, UI = function(state) is very convenient but the way React implements it inverts the problem. Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.

willsmith72 2y ago
No, you don't. React does.
- LegionMammal978 2y ago
  I think I get what GP means. Without very judicious use of useMemo, you can't move a piece of state into an outer component without causing the rest of its children to also be re-rendered when the state is changed. I recall having to fiddle around with useRef at least a few times due to this, to avoid lots and lots of useMemo churn.
  - willsmith72 2y ago
    But that's the whole point of react compiler, which is the whole point of the post we're talking under
  - yunohn 2y ago
    Have you tried wrapping component exports with memo? That basically solved everything for me. It’s the equivalent of functional components from before hooks. > export default memo(ExampleComponent)
bastawhiz 2y ago
> Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update. That's literally the point of React Compiler

nox101 2y ago

This is not my experience at all. I write some visualization. I want to add a UI to tweak the numbers. I add React. React requires me to re-write all of my state for its `setState` stuff.

Rohansi 2y ago
State management is the worst part of React IMO. Basic things with `useState` aren't too bad but as soon as things get a bit more complex you need to reach for a separate library to make it easier. Unfortunately all of the popular options make use of weird patterns like reducers. I ended up rolling my own state management that lets you just write a normal JS class with normal fields and methods and use that for accessing and modifying your state. No reducers, atoms, stores, etc... Just a JS class for your state and logic. https://github.com/facepunch/react-class-model https://github.com/facepunch/react-class-model
- PaulHoule 2y ago
  One trouble I see with React is that it doesn't have a complete answer to state management. I was building very complex AJAX apps around 2006 or so such as knowledge graph editors and decision support software using tools like GWT and Silverlight that had the same async comm as Javascript and was developing state management systems that were so far ahead of React, Vue and that sort of thing that when I came across those frameworks I was seriously disappointed. I've got the feeling that I can render anything I want the way I want with React (even 3-d worlds!) but the only framework that comes close to what my old systems could do is https://mobx.js.org/README.html https://mobx.js.org/README.html and I cannot understand why MobX isn't more popular than it is. (Worked fine for a websocket-based app to control my smart speakers, it was trivial to make it so adjusting the speaker volume through the mobile app or buttons was reflected on my web app. Never tried a bigger app)
  - nox101 2y ago
    MobX can be slow. Example for me, and maybe I just did it wrong. Made a photo gallery viewer (so a page of a few hundred thumbnails). Have options in the toolbar for whether to show the filename, date, location, on each thumbnail. Use MobX to make those settings reactive. Result, it runs way way way too slow since each of the hundred thumbnails is doing some complicated check to read the value of the reactive state variables. I can fix that by having some higher level component (like the thumbnail gallery) read the value and then pass it down to all the thumbnails. But, the point is, I had to work around the fact that it's slow rather than just do the obvious thing and have each thumbnail look at the state it's interested in and not have to have higher level components deal with it. In other words, I want to be able to add features to Thumbnail without having to modify ThumbnailCollection but because it was too slow I now have to modify two places (or 3 or 4) instead of one.

jmull 2y ago

> No learning yet another templating system (which inevitably morphs into a shitty programming language). React has yet another templating language. Sounds like we agree that JS isn't a shitty programming language, but that's hardly unique to react.

throwAGIway 2y ago
React doesn't have a templating language, React has syntax sugar for JS function calls - a very significant difference especially when you add TypeScript.