5 ms·

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 lit

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. For example, you can easily implement server-side includes https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes or edge-side includes https://en.wikipedia.org/wiki/Edge_Side_Includes https://en.wikipedia.org/wiki/Edge_Side_Includes but running on a server that's running on the client.

untog 6y ago
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)
- nymanjon 6y ago
  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. https://github.com/jon49/MealPlanner https://github.com/jon49/MealPlanner Right now it only works offline.
edouard-harris 6y ago
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.
- rglover 6y ago
  Not quite. It's just a client-side cache of query results matching a MongoDB query on the server (pub/sub).
- martinmunk 6y ago
  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.
jacobr 6y ago
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
skoskie 6y ago
Any good tutorials you’d recommend?
Aeolun 6y ago
I have literally never had a worse experience developing than with serviceworkers. Accidentally cache your index.js file? You are now stuck with your serviceworker forever (unless you do some chrome voodoo). The promise is there, but it’s just a gigantic footgun.
- winrid 6y ago
  If you build your SPA to an index.js file and serve it without a timestamp you're screwed when it gets cached too.
  - Aeolun 6y ago
    Not nearly as much since every browser has a variety of ways to perform a cache refresh. Any issue with webworkers is almost by necessity opaque.
robertoandred 6y ago
That sounds incredibly complicated just to avoid using react

untog 6y ago

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)

nymanjon 6y ago
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. https://github.com/jon49/MealPlanner https://github.com/jon49/MealPlanner Right now it only works offline.

edouard-harris 6y ago

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.

rglover 6y ago
Not quite. It's just a client-side cache of query results matching a MongoDB query on the server (pub/sub).
martinmunk 6y ago
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.

jacobr 6y ago

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

skoskie 6y ago

Any good tutorials you’d recommend?

Aeolun 6y ago

I have literally never had a worse experience developing than with serviceworkers. Accidentally cache your index.js file? You are now stuck with your serviceworker forever (unless you do some chrome voodoo). The promise is there, but it’s just a gigantic footgun.

winrid 6y ago
If you build your SPA to an index.js file and serve it without a timestamp you're screwed when it gets cached too.
- Aeolun 6y ago
  Not nearly as much since every browser has a variety of ways to perform a cache refresh. Any issue with webworkers is almost by necessity opaque.

robertoandred 6y ago

That sounds incredibly complicated just to avoid using react