IMO, TurboLinks + service workers are the way to go.
Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.)
The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support. Service workers also have access to a local database, IndexedDB, running in the user's browser.
You can build a very fast web experience this way. You can easily cache individual pieces of a web page and glue them all together.
Strongly agreed that service workers have a ton of potential here. But I’m still waiting for there to be some kind of killer framework that crosses the bridge between worker and window, saving lots of main thread processing, etc... MessageChannels are quite low level so I imagine it would need some abstraction. But still, very powerful. I’m imagining some kind of Svelte-like thing that creates the whole page worker-side, then generates minimal window-side JS to hydrate the components that’ll actually change. Of course I’d make it myself, but... oh, look over there...
(IMO they should still be called local servers, or server workers perhaps. Service worker is too vague)
I'm working on something like this. Not really a framework though. More of a hodgepodge of JS that I've written and the front end logic would be something like HTMX/Behavior.js style of coding. It will be a progressively enhanced approach to writing a SPA so you could have no JS and it would still work! Or, if you have a modern browser it would work offline. We'll see if I ever finish it :-)
I'm doing a bit of a rewrite right now so this flexibility will come soon.
Is ESI in Service Workers anything you’ve tried? A bit mind blown, never thought of that. Been putting of SW due to all horror stories of people bricking their sites basically
Is this the same model meteor.js uses? I seem to recall their system maintains a mini-database on the client side and syncs it with the main server through a pub-sub model.
Yes. At least it can use service workers.
Meteor uses MongoDB on the backend, and minimongo client side. Those two are synced over their DDP protocol IIRC.
I miss meteor. It was such a great framework and promise. Not for big sites really, but for mock-ups, internal sites ect.
A while ago I started to look at it again. The drivers behind the project was essentially asking for input on what was preventing people from using the framework.
The current state of the project is/was OK, except for the fact that it was hold down by all the guides and howtos referring to previous versions. It was not well documented what current best practices to follow, what to use as replacements for deprecated dependencies ect.
Not many people know this, but a service worker (previously called "local server") allows you to run a little web server in the user's browser that intercepts requests to your own web site. (There's no open IP port.)
The service-worker web server can proxy requests to the remote server, and even build/store entire pages on the client side, enabling offline support. Service workers also have access to a local database, IndexedDB, running in the user's browser.
You can build a very fast web experience this way. You can easily cache individual pieces of a web page and glue them all together.
For example, you can easily implement server-side includes https://en.wikipedia.org/wiki/Server_Side_Includes or edge-side includes https://en.wikipedia.org/wiki/Edge_Side_Includes but running on a server that's running on the client.