[DangitBobby]

I was noticing this as well. I believe it's because each ui element must do a request to perform actions server-side (notice how the on_click handlers are python lambda functions).

This is probably the main drawback; you need your server to be located physically close to where the UI is open or there will be a very noticable delay. It's probably pretty snappy when the server and browser are on the same machine, though.

[steve_adams_86]

Another choice would be optimistic UI updates (assume the checkbox will end up checked. If not, revert to unchecked and display feedback about an error).

I’ve tended to use this in UIs which rely on server state, and it usually makes things feel much snappier. In my experience it’s rare that an optimistic update isn’t fulfilled as expected, so the user experience is improved overall.

I’d hesitate to do it absolutely everywhere, though. In large forms it would be preferable to do batch updates rather than updating on every field interaction, for example.

[solardev]

That causes rubberbanding, doesn't it, where the checkbox looks checked at first and then unchecks itself a few seconds later when the server says "nope"?

[steve_adams_86]

It can, yes, but the snap back should always be accompanied by feedback to allow the user to understand what happened.

There are pitfalls (what if the user thinks a setting saved and closes their browser, but it failed after they closed the tab?) which are addressable but it takes work and complexity. I think optimistic UI can be helpful. Generally speaking it’s a layer of complexity I’d tend to try to avoid, though.

Tools like Relay for graphql come with excellent implementations of this which I’d say are worth using if you’ve adopted the library, for example.