The WASM component just seems like a way to avoid writing models? Or is it demonstrating that you can run your server in the browser? Why is WASM needed then if it's just handling simple internal requests. WASM adds a layer of Golang which would be nice if the server needed to be portable from the local, but then why run the server locally at all if you need it in remote contexts? If you're trying to build a simple local JS app, why not just write it all in JS?
So far, all of the comments are taking this far too seriously. It's literally just: "htmx is supposed to be great" and "Local first is supposed to be great" so lets combine them in the dumbest way possible.
Really enjoyed this article … thanks for opening my mind wider.
In case anyone thinks this idea is serious, my strong like of vanilla HTMX came from the realizations that (i) state management can revert to the ur-web model and avoid all the complexity of browser / server state synch and (ii) I can use anything I damn well like on the server (I wrote https://harcstack.org to optimize for expediency).
Big fan of htmx here, so thanks for opening my eyes to a new way of using it with service workers.
But man, 10MB Go WASM download? That's a no go. It's not only about downloading it but executing on a clients machine over and over again. But I guess you can handle those requests perfectly fine just in service worker using pure JavaScript.
Interesting article, but isn't the main HTMX use-case mostly where you want to make server do most of the work, that is Remotely? As you literally render its responses directly - HTMX pages and fragments - instead of doing HTML -> JSON -> HTML gymnastics. Using paradigm of this kind to build local/client-first apps sounds weird.
I think it would be nice to be able to use APIs that only return JSON, and be able to hx-swap in some text that comes from a specified JSON object/key... but the htmx developer has made it very clear to me that they are intentionally, ideologically allergic to JSON.
The geneal idea of HTMX is that your HTML will be rendered by the backend — à la Server Side Rendering.
To me this phrase makes no sense, what's the thought process behind this meaning of "render"? The only place HTML is "rendered" is in a browser (or in a user agent, if you prefer).
You could "render" it to html with pandoc, then serve the html from disk by a static web server.
This would be "build time" html - it's html before it's read by the server.
Then you could setup a cgi script, php-script or an application server that converted markdown to html - then sent it to the client. This would be server-side rendering.
Finally, you could send some html+javascript to the client that fetch the raw markdown, then generates html on the client. That would be client side rendering.
Local first is really relevant if you have the potential of users losing connectivity or is building some sort of collaborative workflow and want updates to happen automatically (like Linear or Google Docs).
Latency is not a real issue with SSR apps, there are a bunch of solutions to place servers and data closer to your users (within a few tens of ms). Plus you can prefetch and cache content very easily without using service workers. That’s not the reason Jira or GitHub feel slow; in fact GitHub was quite fast a few years ago when all it did was render pages from the server.
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.
Wow I am loving this. I had a very related question on the htmx discord (ie can we load content from "any function" instead of an endpoint. My use case was that I used the FE (in typescript) in a very stateless way and had most of the logic driven by a go-wasm binary (the binary was pretty much the "M" and "P" in MVP). When I saw the Wasm binary here in the post it gave me a bit of relief. Cant wait to see this direction take off!
19 comments
[ 3.7 ms ] story [ 50.9 ms ] threadIt does not aim to remove js from your code, it simply adds more features to HTML by default, like making any element able to trigger an web request.
When you write a real world app with HTMX, you inevitably end up writing some js, which is totally fine.
In case anyone thinks this idea is serious, my strong like of vanilla HTMX came from the realizations that (i) state management can revert to the ur-web model and avoid all the complexity of browser / server state synch and (ii) I can use anything I damn well like on the server (I wrote https://harcstack.org to optimize for expediency).
But man, 10MB Go WASM download? That's a no go. It's not only about downloading it but executing on a clients machine over and over again. But I guess you can handle those requests perfectly fine just in service worker using pure JavaScript.
Instead of a WASM backend, I used react-dom/server to generate the HTML.
https://github.com/michaelcpuckett/listleap?tab=readme-ov-fi...
One of the many dictionary definitions of the word also appears to be to "give an interpretation or rendition of" something.
You could "render" it to html with pandoc, then serve the html from disk by a static web server.
This would be "build time" html - it's html before it's read by the server.
Then you could setup a cgi script, php-script or an application server that converted markdown to html - then sent it to the client. This would be server-side rendering.
Finally, you could send some html+javascript to the client that fetch the raw markdown, then generates html on the client. That would be client side rendering.
Latency is not a real issue with SSR apps, there are a bunch of solutions to place servers and data closer to your users (within a few tens of ms). Plus you can prefetch and cache content very easily without using service workers. That’s not the reason Jira or GitHub feel slow; in fact GitHub was quite fast a few years ago when all it did was render pages from the server.
[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
So you should be able to achieve pretty much anything at that point. A nice side-effect of moving to fetch.