Agreed.

In fact, I find Django and Postgres to be the best solution for htmx but Go stack is probably almost as good in terms of developer velocity and obviously much faster. So I think that's a good solution.

You can really build powerful production apps with htmx, and what people underestimate is how good it is with AI assisted development (Claude understands it and does it well, and if any JS glue logic on a specific template is required, it's pretty well written and not a mess).

Django + Postgres on the backend plus a frontend of HTMX + alpine.js for a light touch of interactivity where needed is a killer combination. Claude is very good at it, and with the right instructions actually keeps things concise and modular without spilling into spaghettification. I would recommend this as a first option to anyone looking to spin up a new web stack if you’re not absolutely sure you need the heavyweight of React.

I use the same stack. Single codebase, no build step. It’s so refreshing.

I had a great role for just over a year building with django/postgres/htmx! i ended up using lightweight web components for my js glue code (as well as shoelace, now web awesome, components). once a few patterns were established, claude code was extremely proficient. now getting back into frontend framework world i'm realizing what a lightweight, enjoyable experience that was...

Strongly disagree on Django, unless it is something you are already at a senior level at pre-AI. I've had the displeasure of cleaning up multiple Django backends lately, and the combination of standard fail-open, weak validation, mediocre ORM, and bad testing frameworks lead to issues I've simply not had when managing agents doing Go, Java or Rust.

Go probably wins as a matter of trade-offs for pure productivity (speed, reliability, ease of refactor), but Java Spring Boot works excellently if you're willing to take the plunge (pretty steep learning curve), and the ecosystem really lends itself to building more complex stuff that holds for a while.

Rust is fun because it is an amazing multi-faceted language where agents will constantly deliver you working yet surprising implementations you'll have to quintuple check, and sometimes spend and afternoon trying to grok. The outcome is also perfectly usable, fast, and reliable, but developer velocity is lower.

Feeling this pain with Django right now. I don't even have to deal with a database in this app (it's just a BFF) and it's unnecessarily complex. Right now I'm ripping out the React frontend and replacing it with htmx. Using Pydantic for form validation (will write a custom validator if I ever need multiple values from form fields). And using htpy instead of a templating engine. So far so good. Let's see how it goes.

Yes, it assumes senior level at pre AI, but this will apply to pretty much anything. Java in particular.

Keep in mind of course that a lot of so called seniors were also producing mediocre code <insert framework or language here>. It doesn't change the point though.

I call it the GOSH stack (Go Sqlite Htmx) but HUGS is good too.

Or RASX (Rust Axum Sqlite Htmx)

Skill.md here: https://github.com/dunctk/rasx-app-framework

Or HAGS (HTMX, AlpineJS, Go, SQLite).

Someone asked about using htmx with php on reddit, and was recommended a HAYW (Hypermedia on Anything You Want) stack.

DASH.

DynamoDB, API Gateway, Step Functions and HTMX.

I go with rust/datastar.

I actually think JSX is better, but I am bored of it because we don't need state in JS no more.

Same here team rust/datastar though I still can't decide between minijinja and maud for templating.

i use this stack quite a bit too. i made the claude do some load bearing 360 backflips, gate and seam a whole buncha smoking guns, and bolt go-starlark on top of this so i can just declare little web apps like its streamlit but it doesn't feel sucky like streamlit. i get to just write little blurbs of python-looking code and i get these fully reactive tools. probably my favorite and most used abstraction that came from too much wine and lazy boredom. also built stupid simple framework ish coverage for connections and duckdb and a few other things.

Go backend with Starlark for dynamic behavior is a great combination. I have been building https://github.com/openrundev/openrun with that approach, mainly for teams to deploy internal tools. It can be used to deploy any containerized application. The management UI for OpenRun is built with the Hypermedia approach https://utils.demo.clace.io/console/

I was unfamiliar with this stack and had an AI conversation about it to figure out what it meant, if I'm correct (not likely), this openrun+Go stack has a PHP FastCGI analogy:

Your web app can be HTML templated pages, with HTMX client interactivity and server interactivity provided by ~~PHP~~ Starlark, which does not have full OS access, but only what ~~CGI~~ OpenRun exposes as possible functionality, all of which happens in-process and per web route.

That's a fascinating new combination!

Yes, OpenRun can deploy any containerized application and act like a proxy for the upstream application, no Starlark or any transformation in OpenRun. If the upstream container is serving JSON APIs, OpenRun can also be used to implement a Hypermedia based web app on top, using Go HTML templates and Starlark as the glue code.

The advantage is that you get the performance of Go while being able to hot reload applications and install new application dynamically without a process restart. I think of it as an application server for containerized applications.

How are you using dbos with SQLite? The docs say its a Postgres library

Hello, I'm from DBOS.

Our Golang and Python SDKs support SQLite as well as Postgres.

Interesting, it's not mentioned anywhere in the https://github.com/dbos-inc/dbos-transact-golang README. By contrast, Postgres is mentioned right at the top.

I recommend updating the README to mention SQLite somewhere, with maybe a link to https://docs.dbos.dev/golang/reference/configuration#using-s... ?

Oh wow, interesting combo that I would never independently reach for, but thanks to your template I might have to give it a whirl!

If you want a prototype fast, don't you use an LLM?

And if you do, why start with a simpler framework?

LLMs are fantastic at HTMX+Go

I also like the same stack, as it plays very well with a terminal focus workflow.