16 ms·
> You literally do though, if you want to keep user experience on par. On par with what? Use any of your existing UI frameworks and instead of keeping state cl
by ctvo 3y ago
> You literally do though, if you want to keep user experience on par.
On par with what? Use any of your existing UI frameworks and instead of keeping state client side, let the server tell you. Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. Dumbly reflect what the server returns.
I understand this isn't what the tutorials for React, for example, show and breaks away from all the auxiliary things they've been using with it for state management, but there's nothing stopping you from doing this.
You can do all of these things today. You don't need to adopt this. You don't need to move to server side templating and downloading chunks of HTML to inject into elements.
- naasking 3y agoYou'd end up partly reinventing htmlx to reduce network traffic, just badly. htmlx literally is just dumbly reflecting what the server returns.
- Xeamek 3y ago>Instead of doing things like eagerly updating client side state (deleting an item -> removing it from your in-memory array), let the server tell you after it's processed and updated its state. So this literally what htmx does, no? Except You'd be operating on framework-sourced components rather then built in html structures. And the swapping itself would be performed by frameworks code rather then htmx library. Is that what you mean? If so then sure, I get that it would be cleaner then with htmx, but logic is the same and htmx simply let's you expand this logic for core html elements, rather then having to remake all of them into frameworks components that can handle the partial updating.