[andersmurphy]

Hypermedia can do all of that fine. You don't need to stick it all in the url. Using simple session and cookie/tab id state can be shared and or isolated between tabs. Then just do a lookup in your backend database.

Hypermedia is also way better for realtime and multiplayer.

If anything where HTMX falls short is it doesn't put enough state on the backend, if anything it's not radical enough.

[b_e_n_t_o_n]

You mean I should be storing the state of a popup menu in my database?

[andersmurphy]

Correct. That's literally what happens with the scroll position, and share modal in this demo (QR code is generated on the fly on the backend):

https://checkboxes.andersmurphy.com

[julianz]

300ms of latency to click a checkbox is a horrible experience, though.

[andersmurphy]

Feels surprisingly good to me.

[christoff12]

not really in this case

[b_e_n_t_o_n]

There is a noticeable delay between interaction and response (~200ms), which is way over the usual 16ms budget for smooth interactions. I think you need some pending state on the client, but that sort of breaks the idea of storing all state on the server haha.

[andersmurphy]

Not sure why this is getting downvoted. I'm literally showing an example of storing popup state in the database as per the parents question.

> You mean I should be storing the state of a popup menu in my database?

[troupo]

No, no you shouldn't.

Well, if you want to present the user with a fully saved UI state even if the user closed your app and opens it later, then yes :)

Otherwise purely client side things should stay either fully client-side, or at most in session storage.

[andersmurphy]

But what really defines client side state?

If the latency was good enough you'd store everything on the server. It doesn't force you to give them the same state when they re-open your app, you can key state by session and tabid if you want.

[troupo]

> But what really defines client side state?

You define it. And the client defines it.

> If the latency was good enough

It's never good enough. Worse, it can abruptly become not good enough. And you have to code additional loading states or optimistic UI for every action that is now performed on the server and takes longer than some time.

> It doesn't force you to give them the same state when they re-open your app

Then why would you store modal state on the server?

It's also a consideration of resource utilization. A million clients with their own app state is better than a million clients hitting your server and requiring you to store that state.

[andersmurphy]

Not if you care about state being consistent between all clients. Say you want a minimap, or a presence indicator, now the server needs to know these things. Same the minute you want backend analytics.

Millions of users hitting the same server at the same time is a very nice problem to have. I've handled 40000r/s (script kiddies are gonna script) with 500+ concurrent users in those demos on a 5$ VPS. With all the scroll position/tab state etc not just going to the server, but to a sqlite db.

Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that you can throttle/batch. You only push view data when the server decides to. In my case that's every 100ms (because it's a 5$ server), so all changes in that time get batched.

>Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace. Not only does this make your program safer by keeping the control flow of your program under your control, it also improves performance for the same reason (you get to batch, instead of context switching on every event). Additionally, this makes it easier to maintain bounds on work done per time period.

- tiger style https://github.com/tigerbeetle/tigerbeetle/blob/main/docs/TI...

You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases. I like to add a pop animation on the client to register something has happened, but in a lot of situations you don't even need that.

[troupo]

> Not if you care about state being consistent between all clients.

No idea what you mean

> Say you want a minimap, or a presence indicator, now

I struggle to see where I said that you have to have everything and anything on the client.

> Events up are fine if you batch them and 204 (i.e CQRS). In return you get a nice pushed based system that

That you have to actually code, create, and maintain.

> Whenever your program has to interact with external entities, don't do things directly in reaction to external events. Instead, your program should run at its own pace.

No idea what this has to do with anything I wrote

> You don't need optimistic UI, a fast server with an in process DB and a decent backend language and you'll be fine for a lot of use cases.

Again, this hinges on the childish belief that the network is always there, is always fast, and is always low-latency.

And none of these answer the question of why you would want to save "I showed a modal on the client" in a backend database.

[rvitorper]

I’ve heard of a major fintech in South America that stores all the client state on the backend. Millions of users daily and it works