Live data from Hacker News

Htmx 4.0

four.htmx.org

191–200 of 208 posts

Re: Htmx 4.0

#191
post #7

Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

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.

Re: Htmx 4.0

#192

I really like htmx, and intercooler.js before it. It's been a while since I tried to convince a co-worker to use it, it might be time to try again. Either way I can't wait to try out the new version. Full Disclosure, I am CEO of HTMX

[flagged]

Re: Htmx 4.0

#195

I really like htmx, and intercooler.js before it. It's been a while since I tried to convince a co-worker to use it, it might be time to try again. Either way I can't wait to try out the new version. Full Disclosure, I am CEO of HTMX

HTMX 4 is 41KB minified, why not use just plain HTML and a single inline 166-byte (sic!) onload handler named HTMZ? https://leanrada.com/htmz/

Re: Htmx 4.0

#196
post #33
post #7

Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

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 speci…

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.

Re: Htmx 4.0

#198
post #142
post #140

Earlier quoted context omitted.

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 fr…

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!

Re: Htmx 4.0

#199
post #7

Congrats and thanks! htmx brings me joy. Pretty much every experiment I build now starts with Go, htmx, and SQLite to keep things simple and fast but still responsive. I put a few more thoughts about this here: https://housecat.com/blog/the-hugs-stack-hypermedia-unix-go-...

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

DASH.

DynamoDB, API Gateway, Step Functions and HTMX.

Re: Htmx 4.0

#200
post #196
post #33

Earlier quoted context omitted.

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 speci…

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 (spe…

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.
Post reply on HN