Hacker News new | ask | show | jobs
by m1el 1456 days ago
Hi, I believe I understand you. If you look at immutable data structures implemented using JS primitives, it will surely look terrible. However, there's a lot of benefit to using a FP approach like Redux.

It's much easier to reason about state updates if all you have is pure functions. It allows you avoid very annoying and hard to catch bugs. I've seen this personally, when replacing a spaghetti component with a straightforward `useReducer` hook.

Unfortunately, we don't really have a performant way to express this pattern in JS (or even in other languages?). You could use something like elm-lang, but it's not as widespread.
1 comments
acoard 1456 days ago
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.

link
kaba0 1456 days ago
I would say that the tool should reason about it at compile time, a la SolidJS.
link
nyanpasu64 1455 days 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.

link
m1el 1456 days 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.

link