3 ms·

I don't see why it couldn't be used in a PWA with a service worker providing offline HTML responses to hx directive elements though. You can see an example here

I don't see why it couldn't be used in a PWA with a service worker providing offline HTML responses to hx directive elements though. You can see an example here that uses a WASM-based service worker (but you don't have to do that, it could just be plain old JS generating HTML): https://github.com/richardanaya/wasm-service https://github.com/richardanaya/wasm-service

infogulch 4y ago
Check out the live demo! https://richardanaya.github.io/wasm-service/ https://richardanaya.github.io/wasm-service/ Last month I contributed the todos functionality to this project after it was submitted to HN. https://news.ycombinator.com/item?id=33228891 https://news.ycombinator.com/item?id=33228891 I think this is a great idea and could eventually enable htmx projects to transition from server-side-only to being a PWA with very little code changes (given the right backend). Unfortunately this particular implementation exhibits some blocking issues which I was not able to solve yet: 1. The Service Worker is eventually unloaded from memory, which means all data is lost because it currently stores everything in memory. This isn't a defect as much as it is lacking a persistence feature; this is a MVP (emphasis on minimal) after all. The most promising solution in my opinion would be to use the OPFS/File System Access API with SQLite, which is yet to be shipped in all browsers. 2. The bigger issue is that once the SW is unloaded it doesn't come back. The SW getting reaped after being idle is fine, that's part of the expected behavior. But there are no events or any other indication that it was disconnected, at some point it just stops intercepting requests. I don't know why. If anyone can chip in here to say why it does this and how I can detect or somehow restart SW fetch interception on demand I would be glad to hear it. ( For some more detail see the "# Remaining Issues" in my PR #5: https://github.com/richardanaya/wasm-service/pull/5 https://github.com/richardanaya/wasm-service/pull/5 )

infogulch 4y ago

Check out the live demo! https://richardanaya.github.io/wasm-service/ https://richardanaya.github.io/wasm-service/ Last month I contributed the todos functionality to this project after it was submitted to HN. https://news.ycombinator.com/item?id=33228891 https://news.ycombinator.com/item?id=33228891 I think this is a great idea and could eventually enable htmx projects to transition from server-side-only to being a PWA with very little code changes (given the right backend). Unfortunately this particular implementation exhibits some blocking issues which I was not able to solve yet: 1. The Service Worker is eventually unloaded from memory, which means all data is lost because it currently stores everything in memory. This isn't a defect as much as it is lacking a persistence feature; this is a MVP (emphasis on minimal) after all. The most promising solution in my opinion would be to use the OPFS/File System Access API with SQLite, which is yet to be shipped in all browsers. 2. The bigger issue is that once the SW is unloaded it doesn't come back. The SW getting reaped after being idle is fine, that's part of the expected behavior. But there are no events or any other indication that it was disconnected, at some point it just stops intercepting requests. I don't know why. If anyone can chip in here to say why it does this and how I can detect or somehow restart SW fetch interception on demand I would be glad to hear it. ( For some more detail see the "# Remaining Issues" in my PR #5: https://github.com/richardanaya/wasm-service/pull/5 https://github.com/richardanaya/wasm-service/pull/5 )