Local First Htmx

[oldestofsports]

HTMX is neither a meme nor is it anti-javascript, it is literally written in js.

It 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.

[Animats]

Nor is it "local first". It works by remotely pushing HTML into the DOM. It's really a form of push technology.

[kryptn]

i decided to use htmx for a frontend for myself and it was a pretty fun experience. even got tailwind involved pretty easily with my rust+maud backend.

[xg15]

It is definitely "anti-javascript" or more precisely "anti-SPA". I've read the blog posts.

[cubefox]

> HTMX is neither a meme nor is it anti-javascript, it is literally written in js.

Java is written in C++, but it is clearly "anti-C++" for any reasonable interpretation of the term. (Java historically replaced C++ as the most popular language, as far as I remember.)

More importantly, HTMX could have had native support without requiring an implementation in JavaScript.

[throwaway838112]

It is definitely meant to provide an alternative to JS, obviously

[sublinear]

Why not just write the js yourself? It's really not that complicated. The people who keep pushing for htmx are weird.

[kubafu]

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.

[wffurr]

Go and even TinyGo aren't a great fit for Wa because they have to bring along their own runtime including a GC. Go can't use WasmGC because it lacks support for interior pointers and unboxed heap primitives: https://github.com/WebAssembly/gc/issues/59

So you'll never get Go Wasm binary sizes down to something reasonable, alas.

[logankeenan]

Using Rust instead of a Go would provide a smaller binary since it doesn't need a runtime. Compared to JavaScript apps, it's not terrible but also not great. One thing WASM has over JS is that it can decode and compile code in parallel across multiple threads as it streams in.

https://hacks.mozilla.org/2018/01/making-webassembly-even-fa...

[andai]

For comparison, opened a random NY Times article. It downloaded 19MB before the page loaded, and then tried to show me an ad (it failed to load, for some reason), and then refused to actually show me the article.

I know it's "whataboutism" but I thought it was pretty funny.

[phplovesong]

IIRC wasm will get a GC soon, so i assume the tinygo project can produce way smaller binaries for wasm.

[logankeenan]

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

[pickpuck]

I built something with Service Workers a few years ago. It's similar in concept, but I never got around to syncing with a server.

Instead of a WASM backend, I used react-dom/server to generate the HTML.

https://github.com/michaelcpuckett/listleap?tab=readme-ov-fi...

[quicksilver03]

I have an issue with

    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).

[jasode]

>, what's the thought process behind this meaning of "render"?

It's another use of "render" relative to the server such as converting non-HTML data inside database tables, json, etc --> rendered into HTML:

https://www.google.com/search?q=SSR+server+side+rendering

Many different perspectives of "rendering":

- SSR server-side rendering : server converting data to HTML

- CSR client-side rendering : e.g. client browser fetching and converting JSON/XML into dynamic HTML

- browser-engine rendering : converting HTML to operating system windowing GUI (i.e. "painting")

[LelouBil]

"render" as in being templated with server-side data/logic.

See also Server Side Rendering (SSR) which uses the term rendering in the same way.

[ranger_danger]

Django uses a render() function to convert a template to HTML, then return it as an HTTP response.

One of the many dictionary definitions of the word also appears to be to "give an interpretation or rendition of" something.

[e12e]

Imagine you have a markdown file.

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.

[librasteve]

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).

[flashgordon]

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!

[recursivedoubts]

In htmx 4.0 you are able to do pretty much anything, up to and including replacing `fetch()` with your own implementation on a per-request basis.

So you should be able to achieve pretty much anything at that point. A nice side-effect of moving to fetch.

[dlisboa]

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.

[righthand]

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?

[mattrighetti]

WASM is not needed.

The author explicitly states that he likes to write Go and that’s why he picked it in this example, which in my opinion makes this article more interesting. The main benefit is that the 'local server' within the service worker mimics the 'real server,' which effectively means you only have to write the code once.

But I generally agree that a 10MB download on first load is not something that I’d be happy to serve to users, especially to those who are using their mobile network.

[aidenn0]

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.

[scuff3d]

I'm not a web dev but isn't the initial page load going to be a bitch if you have to ship a whole ass web server with it?

[BinaryIgor]

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.

[mejutoco]

This is interesting exactly because making everything come from the server (like htmx) saves oneself from having to do another frontend, but it has a disadvantage: it does not work offline. While many traditional SPA fail miserably at working offline, there is no such limitation in SPA land. It is a valid concern for htmx, and it is good that there are options. Addressing the limitation is precisely the point.

[ranger_danger]

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.

[euroderf]

This architecture looks perfect, for the locally inclined. Waiting for episode 2.

[fud101]

why we even need a backend. just run it in the browser. is there a framework for that?