Alex Russell

My hottest take might be that "state management" isn't a real class of either problem or solutions. Instead, it seems to cover a confusion of:

- intra-component data propagation
- a bad way to reinvent events and broadcast channels
- a missing data synchronization layer

Each of these have distinct solutions, and "state management" tools do none of them credibly.

Jun 3, 2024 at 4:43pmWeb
Show threadAlex RussellJun 3, 2024
If your app ended up serializing multiple MB of JSON in local storage because of your "state management" tool, I've got bad news for you.
Show threadLouis IngenthronJun 3, 2024
@slightlyoff Agreed. It can, charitably, be described as a simple abstraction that's good enough for simple systems.
Show threadBruno NicolettiJun 3, 2024
@slightlyoff For anything complex, implement state via web assembly in a statically typed language and avoid JS hell. The statically typed language will have libraries that aren’t fads of the month that help your do what you need to do. Leave JS as the thinnest possible skin as a presentation layer.
Show threadHasan AliJun 4, 2024
@bjn do you have any examples of this? I’ve attempted this before and with my limited experience, I worry the issue with this might be the serialization cost across the WASM boundary
Show threadBruno NicolettiJun 4, 2024
@hasanhaja figma has a web assembly and webgl engine.
Show threadHasan AliJun 4, 2024

@bjn I’m familiar with the Figma using WASM generally, but I’ve not seen anything specifically around state management and the benefits thereof. My concern was around crossing the WASM boundary too frequently and I think the link in the post addresses it better:

https://fosstodon.org/@hasanhaja/112491179226762889

I feel that using WASM for state management rather than JS to keep the JS layer as thin as possible only shifts the complexity within the client and doesn’t reduce the overall complexity for the user

Hasan Ali (@[email protected])

@[email protected] I’ve found it quite difficult too, and this article did a good job talking through the vast undertaking WASI has grown to be. I do really hope that this doesn’t “die under its own complexity” Watched this talk yesterday and it made some of the component model stuff more digestible: 🎥 https://youtu.be/2GSlCFCuN8U?si=Xc1W62GO5TstS6q6

Fosstodon
Show threadTim BrayJun 3, 2024
@slightlyoff Hmm, would it be reasonable to say that state management is an aspect of almost every application, but the needs (and thus the shape of the solution) is so highly application-specific that there’s little room for generic solutions at a much higher level than Redis?
Show threadAlex RussellJun 3, 2024

@timbray Yes, exactly this. There are broad patterns that help you know which territory you're in, though.

For instance, if you're doing optimistic local commit against a complex data model over 50+ interaction sessions (without reloading), you need a sync tool.

If you're serving short-lived individual pages, you likely only need DOM events.

Show threadBrian LeRoux 💚Jun 3, 2024
@slightlyoff thiiiiiiiiiis
Show threadJan Lehnardt Jun 3, 2024
@brianleroux @slightlyoff oh lol and here I thought there was some arcane magic in building fronted that I didn’t know.
Show threadBrian LeRoux 💚Jun 3, 2024
@janl @slightlyoff all three of us are suffering a curse of knowledge. how a frontend works with data isn't all that special unless you want to gatekeep frontend devs into one year experience repeated infinity times
Show threadFrancis 🏴‍☠️ GulottaJun 4, 2024
@janl @brianleroux @slightlyoff you just need to sprinkle some venture-capital pixie dust in the form of their other companies dev tools and then it’s guaranteed to work
Show threadBrian LeRoux 💚Jun 4, 2024
@reconbot @janl @slightlyoff I genuinely wonder if an "advanced" course about how to <form> properly would do well.
Show threadThomas Randolph Jun 4, 2024

@slightlyoff these have been sitting in my drafts for years

I have yet to muster the energy to fight this battle with the folks for whom this is a matter of their identity.

Show threadAlex RussellJun 4, 2024
@rockerest I feel the same ennui. Would me going first be enough to open the proverbial floodgates?
Show threadThomas Randolph Jun 4, 2024

@slightlyoff it would certainly be useful to read your perspective on it!

That said, I don't know how to coax most people away from their comfort blanket in this aspect, because - fundamentally - "replace your Flux implementation with something more thoughtful and with better separation of concerns." never gets any bites.

Show threadMunawwar FirozJun 4, 2024
@slightlyoff At the heart of the good "state management" libraries, it's just this. But it's being built by random people over and ocer again because certain framework authors are focused on "the next big thing" (narrator: which isn't) than clearly addressing something that is missing in their "framework" and is causing confusion.
Show threadmatthewJun 4, 2024
imo, it's built over and over because view and state are separate asymmetrical hierarchies and the view is the focus of component-oriented architecture.

CC: @[email protected]
Show threadMunawwar FirozJun 4, 2024

@matthew As I see it, It's still all about view. And a FW without some tools there feels incomplete.

The built-in solution doesn't need to have loads of bells and whistles. For more advanced solution use a 3rd party solution if needed. One can see a pattern in the use cases majority of these state mgmt libraries are addressing.