Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx 4.0

four.htmx.org

Post reply on HN
Print view View original

201–210 of 211 posts

Re: Htmx 4.0

#201

Post by sgt »

arw0n wrote: post #196
sgt wrote: 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…

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 . It doesn't change the point though.

Re: Htmx 4.0

#202

Post by deadbabe »

Maybe I’m missing something, but why would you want HTMX server side rendering, rather than a restful API that can return platform-agnostic data structures that you could render in various contexts, like a SPA, or a mobile app, or a terminal app, etc?

Re: Htmx 4.0

#203

Post by vercelsucks »

Hopefully Vercel acquires them and puts the final nail in the coffin of that piece of shit PaaS and the SSR concept in general for client-side applications.

Re: Htmx 4.0

#204

Post by ajayvk »

Multicomp wrote: post #198
ajayvk wrote: post #142

Earlier quoted context omitted.

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

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.

Re: Htmx 4.0

#205

Post by fatplexer »

turtlebits wrote: post #149
fatplexer wrote: post #123

Earlier quoted context omitted.

I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression. Seriously DB->json->client->toHtml DB->toHtml->client Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issue…

Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.

[dead]

Re: Htmx 4.0

#206

Post by aidenn0 »

mexicocitinluez wrote: post #180
aidenn0 wrote: post #128

Earlier quoted context omitted.

> ... managing state on the server is not fun at all. Do you not have a database for your backend? Managing state is kind of their thing.

Are you not familiar with building web apps? So, when building for the web you'll essentially have 2 different categories of state: server and client. Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.

I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.

Re: Htmx 4.0

#208

Post by cbeach »

rednb wrote: post #109

Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people…

I totally agree. When we started splitting presentation from content (CSS) that was a wonderful step forwards. And splitting back-end and front-end concerns similarly makes for a cleaner and more elegant design in both codebases.

IMO HTMX is a weird regression in our design patterns. Hopefully a temporary anomaly. I'd never choose to work in a company that adopted this mixing of front and back end code - it's a red flag as far as I'm concerned.

Re: Htmx 4.0

#209

Post by tyre »

embedding-shape wrote: post #126
perardi wrote: post #114

Earlier quoted context omitted.

I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.) Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite. Different tools for different jobs. (Me? I honestly love React, just a more minima…

Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches. I'm no…

As someone who has conducted a ton of systems design interviews, the "I used these tools at my last job so I will use them for this completely different problem" is bamboozling.

OTOH, there are advantages to comfort picks. You know the APIs, you know the common libraries in the ecosystem, you know the quirks and pitfalls. It might not be optimal—and in production it compounds—but for dinky personal projects or finite-scoped professional things, it's understandable.

Post reply on HN