undefined | Better HN

0 pointsacoard3y ago0 comments

Right it’s basically just developer convenience.

So from your post it follows that if a developer can reason about the state changes of their app without redux, they should do so if there are performance concerns. Right?

I say this as a webdev who has written pure vanilla Js SPAs a decade ago, and someone who often uses Redux now on most projects today. So I know it’s totally possible to have performant mutable state management on a project that isn’t a mess - that’s how we always did stuff before redux.

0 comments

kaba03y ago

I would say that the tool should reason about it at compile time, a la SolidJS.

nyanpasu643y ago

Can SolidJS reason about collections of items being added and removed? My pseudo-reactive Qt apps do well with structs, but I often resort to recomputing the entire list of items when elements are added or removed (because QAbstractItemModel is hell to work with, and because my "move items" commands are not exposed to the GUI layer). Perhaps even diffing the item list would be faster than telling the GUI that all data was changed. (Though with <100 items, it really doesn't matter.)

I don't know how item lists are handled by GTK3, GTK4 (which is supposedly a lot better: https://blogs.gnome.org/antoniof/2022/06/15/the-tree-view-is...), Svelte, Solid, or the C# GUI frameworks.

m1el3y ago

> if a developer can reason about the state changes of their app without redux, they should do so if there are performance concerns. Right?

That is correct :)

However, I'm not sure how many developers will be able to maintain the project and keep the invariants implicitly ingrained in the codebase by the smart developer who can reason about mutable state changes.

j / k navigate · click thread line to collapse