Alex RussellJun 3, 2024

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.

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 Ali
@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
Jun 4, 2024 at 9:03amWeb
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