The computers are fast, but you don't know it

Re:The computers are fast, but you don't know it by m1el on Friday June 17, 2022 @05:23AM (#31775876)

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.

[ Parent | on HN ]

Re:The computers are fast, but you don't know it by acoard on Friday June 17, 2022 @10:10AM (#31778435)

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.

[ Parent | on HN ]

Re:The computers are fast, but you don't know it by kaba0 on Friday June 17, 2022 @03:38PM (#31783222)

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

[ Parent | on HN ]

Re:The computers are fast, but you don't know it by nyanpasu64 on Friday June 17, 2022 @09:23PM (#31786503)

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.

[ Parent | on HN ]

Re:The computers are fast, but you don't know it by m1el on Friday June 17, 2022 @02:42PM (#31782531)

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

[ Parent | on HN ]