wasm-service

It's really cool to see someone else gravitate toward this idea. I think there might be some real potential in the future. I wrote about a similar idea in 2022 [0] and 2023 [1]. The service worker approach was heavily inspired by Richard Anaya's work [2]. HTMX migrating to fetch [3] makes this even easier. I had to create a xhr-fetch-proxy [4] to intercept requests with htmx today. I'm not the author, but would be happy to answer any questions. [0] https://logankeenan.com/posts/a-rust-server-app-compiled-to-... [1] https://logankeenan.com/posts/client-side-server-with-rust-a... [2] https://github.com/richardanaya/wasm-service [3] https://news.ycombinator.com/item?id=45803358 [4] https://github.com/logankeenan/xhr-fetch-proxy

I didn't fully understand this idea of hydration but I also got recently interested in leveraging Wasm, in context of running parts of backend logic using it (eg. regular templating and some Htmx endpoints) to allow certain offline features with regular server-side web frameworks that could use similar Sqlite Wasm datastore as OP. - Full Django example https://github.com/m-butterfield/django_webassembly - Minimal Rust example with client-server separation using macros https://github.com/richardanaya/wasm-service - Clojure Electric using more macros for something similar (without wasm) https://github.com/hyperfiddle/electric - Recent M$ web tooling starting with letter B? In last few years, surprisingly many parts of Python ecosystem to have gained Wasm support that can leverage this also. Obvious ML related ones and even game libraries li

You can embed a "backend" as a service worker and use htmx to interact with it. A proof of concept here: https://github.com/richardanaya/wasm-service

Check out the live demo! 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 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 SQL

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