What it's like to run Htmx in Production | Hacker News Reader

What it's like to run Htmx in Production

hamy.xyz

38 pointsbnewton16 comments

Interesting claim here about engineering org dysfunction:

> FE code has gotten so complex that many orgs now have specialized positions - FE and BE. In practice this means that it's very hard for any one developer to get a fullstack change out.

> Short-term this means that all changes incur extra cost due to context switching and collaboration overhead between FE / BE dev

> Long-term this means a general architectural bias against doing things fullstack. Both sides will go to great lengths to not have to do things fullstack which often leads to suboptimal architectures throughout. This is how we got heavyweight client state management (Redux), interesting RPC protocols (GraphQL), and the push towards JS-only stacks (NextJS, Nuxt, SvelteKit, etc) - all methods to try and lower the pain of FE <> BE communication.

I see this in my job, so at least for me it's not a claim, it's reality.

I can only recommend everyone to learn both FE and BE programming, to avoid this situation and the overhead.

HTMX is closer to REST than your so-called JSON REST API.

I would say that it misses one of the main drawback of using Htmx: it does not force you to create a proper API.

When you create a standard single page application, you generally start by building a JSON API on the server side, and a client application that can consumme that API.

Htmx server code is different as it just returns HTML code to be inserted back in the page. So while, writing an app with Htmx is very easy for that very reason, you will likely not build a proper public API while you build your app and the day that you realise you need one, you have to write it from scratch.

If you know you will need to provide a good public API, building it from the get go and a React/Angular app on top might still be worth it.

(Just to be clear, I think Htmx is great still.)

HTMX is sort of like a spiritual grandchild of 1990s stuff like CFML, at least conceptually, anyway. That's pretty cool. And maybe instructive, to look at what brought down systems like that, way back in the day.

I'm a flunkie from the caverns of the military industrial complex, but I'm also poking my head aboveground and going through some of my buddies' modern doc projects (along with the git history, issues, all the Swagger stuff [which I like!]). All in a (probably futile) attempt to be employable outside my industry. Anyway, I came away with this nagging sensation that the API is where the actual architecture work takes place. It's almost certainly a wrong impression - this is not my world - but I'm having a hard time seeing what keeps things on the rails aside from the API process. I'm getting a whiff of that from the OP article too.

I am betting that better managed projects have a whole layer specialized for architecture, instead of shoving that work down for the API docs to figure out. Nothing as stupid as what we got in our business - "fifty different architectures in a hundred different places each of which costs millions of dollars" - but a place where it theoretically happens.

> If you know you will need to provide a good public API, building it from the get go and a React/Angular app on top might still be worth it.

That is a different point than you made earlier in your comment though. That you start building an API on the server side does not mean you’re creating a good, well-balanced, API suitable for public consumption (being consumption in other teams or even other companies).

This is actually a feature. A good API for public consumption is a specific thing to build with intentionality.

If your tech stack forces you to build an API in order to put a basic webpage together and handle form data, that is the red flag.

https://htmx.org/essays/splitting-your-apis/

Concedes that there's extra network requests and then just completely handwaved it away.

I'm not a web dev so my knowledge is limited here.

What is the canonical way to do "components" with this htmx workflow though? How do you create an abstraction for a button, or a card, etc... Do you just copy/paste the html all the time?

Is it just BE templates?

The same you always have? With HTML/CSS. Copy and paste sounds a bit derogatory, but it's pretty much what you're doing. You can also "templatize" things depending on your backend (card partial/template, etc).

What I like about my tech stack (go, tailwind, htmx, alpinejs) is the fact I can work entirely in HTML and Go. It keeps the work very focused and simple.

I render HTML from Go. I style it with Tailwind. If I remove styles from HTML then Tailwind culls the unused styles (I don't need to manage CSS). I use HTMX for some dynamic behavior (active search, lazy loading content/modals/slide overs/product details/etc). I use Alpine for client side state (drop downs, slide overs, toggles, etc).

I get it, thanks.

Out of curiosity what's the templating lib/engine/whatever you use in Go?

html/template

https://pkg.go.dev/html/template

I'd really like to see some production web sites that use htmx.

https://htmx.org/webring

Reply on news.ycombinator.com