Hacker News Reader

Comment by a_wild_dandan | Hacker News Reader

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.

View on HN

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

No, you don't. React does.

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.

But that's the whole point of react compiler, which is the whole point of the post we're talking under

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)

> 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

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.

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

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.

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

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

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)

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.

Wonder why. We’ve got thousands of conditionally rendered components on a pretty interactive scheduling screen. One click can affect all of them but everything feels instantaneous.

Our bottleneck was that we have so much data, making it all observable up front led to slow initial load times and high memory usage. We now make things observable on demand which has eliminated a lot of that.

Try jotai. Of all the different react state libraries it’s the one I enjoy using the most.

I miss it when working with languages other than JavaScript.

I don't understand Jotai. What are atoms and why is using atoms preferable over a normal JS class/object? With react-class-model I can keep my data and logic in a JS class and access it from React components with hooks.

Atoms have a few advantages over a plain object:

1. They can easily provide derived data without manual memoization.

2. You can provide custom setters that do more than just assign values.

3. Your UI only re-renders the parts that reference fields that changed, not every component.

4. Atoms compose nicely etc.

Putting plain JS objects in context/state and passing them around only really works for simple, small apps. Beyond that you need more powerful tools. I also like Zustand for this.

For a bare object sure. Points 2 and 3 are solved with react-class-model. I don't understand how atoms compose nicely but classes wouldn't.

Zustand looks a bit better but it is still very different from normal JS. Nobody writes code like that normally. Why can't we have normal, boring code for state management?

This react-class-model?

https://github.com/Facepunch/react-class-model

7 stars on github? Class objects with decorators? No thanks.

That's the one. Obviously not popular since I made it for an app I work on.

What's wrong with decorators? Technically not needed but I like things being explicit.

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

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

Reply on news.ycombinator.com