> Would be a great hack to be able to just run your server code in a worker.
This is exactly why some people build heavy offline-first SPAs in JS. HTMX tries to avoid this entirely. Conceptually (seen from the perspective of HTMX), it makes zero sense to put the server code in a worker and run a client-server architecture in the client‘s browser.
This would be an over-engineered thing that HTMX explicitly tries to avoid in the first place.
> This would be an over-engineered thing that HTMX explicitly tries to avoid in the first place.
Yes, this is where I think a lot of folks who moan about "bloated JS frameworks", etc. really are just complaining they can't use their favorite (or only) language for web UI development.
I made an app doing this with an HTMX-like library with a total of 100 kB minified/zipped code. Not bloated at all. The code to make it work is about 10 kB. The rest is the code for the actual app.
I'm not sure "zero sense" is true. An app designed around REST and hypermedia imposes sensible constraints, like how you handle state, navigation, etc., and this can still yield plenty of benefits.
I am not sure if I understand the definition of offline here. HTMX has graceful degradation options. What else could you do when the client is offline?
This is exactly why some people build heavy offline-first SPAs in JS. HTMX tries to avoid this entirely. Conceptually (seen from the perspective of HTMX), it makes zero sense to put the server code in a worker and run a client-server architecture in the client‘s browser.
This would be an over-engineered thing that HTMX explicitly tries to avoid in the first place.