So this keeps happening, and I think we need to talk about it:
> them: React manages state in our app.
>
> me: It does? Then what are <various_libraries> for?
>
> them: Oh, those manage state.
Discussion
So this keeps happening, and I think we need to talk about it:
> them: React manages state in our app.
>
> me: It does? Then what are <various_libraries> for?
>
> them: Oh, those manage state.
Just stumbled on this article about Github's recent local-thirst adventure. I'm in favour of the concept (especially the Service Worker), but surely it would have been simpler and faster if they didn't have <various_libraries> competing to "manage" state and the render path...
> Hard-navigation gains are real, but less than Turbo gains: on cache-hit hard navigations, we trade SSR time for client-side rendering. The critical path now becomes JavaScript
@slightlyoff @janl i have unfortunately encountered many of these in the wild. they all suck compared to react props+state+contexts, and often react itself is overkill. and every dependency is a liability when it comes time to make an upgrade or a migration to another framework
@slightlyoff does it go without saying that CRDTs etc should only be considered if your app really can't just be an SSR MPA (which doesn't even preclude many local/offline-first use cases. Eg Could use service worker to return cached pages, fragments and associated data)?
@nickchomey Good question. If you're holding on to state you care about in the JS heap – stuff that should be saved and that isn't managed by HTML form elements directly – then you need something that's better (conceptually) than "last writer wins"
@nickchomey If the server is the only authority, then there's no problem. If, OTOH, the client has a potentially mutable, disconnected slice of the data set, then you need to tech up and think about "state management" as "sync" instead
@slightlyoff yeah, if you need it, you need it. But, like JS in general, perhaps CRDTs should be a "break in case of emergency"?
I suspect that most apps don't (shouldn't?) really have disconnected slices of data, and server as source of truth that returns corresponding html is probably the simplest, fastest and most robust
And it seems to me that "last writer wins" is probably ok for many offline situations. Like, submitting this comment or boosting yours while offline wouldn't need a CRDT
@slightlyoff The inability of these libraries' marketing pages to explain how they manage state better than *checks notes* variables... is a tell.
@twifkak Multiple times over the past decade+ of consulting, I've had some senior person find me after the main meeting and whisper *"they don't seem to understand that Redux is just programming with global variables, and I don't know how to explain it to them."*
Validating and dispiriting, every single time.
@slightlyoff I have been using https://mint-lang.com/ for writing web apps the last few years and it's a total fresh experience. I don't need a single library for rendering, state management, styling and theming, or consuming APIs. It's all built in and integrated, and the dev experience to get hacking on a new project or component is so easy, it makes the JS/React mainstream 😱 feel like a bad dream in comparison.