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

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

231–240 of 530 posts

Re: Please just try HTMX

#231

Post by yellow_lead »

adamzwasserman wrote: post #181
perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…

How do you handle HTTP errors?

Just curious because when I used HTMX I didn't enjoy this part.

Re: Please just try HTMX

#233

Post by mal-2 »

alfonsodev wrote: post #128
chrisweekly wrote: post #97

Earlier quoted context omitted.

This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

I overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this: - 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx) - 2 Taking a break from React - 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX an…

This is what doesn't get discussed enough around htmx, in my opinion. So much of the difficult steps are left for the templating system, and template systems aren't great in general. You need to track a lot of identifiers for htmx to work properly, and your template and view logic needs to make that make sense. For the templating systems I've seen, that's not so simple to do.

Re: Please just try HTMX

#234

Post by lkbm »

bondarchuk wrote: post #203

> The "server" (mocked client-side for this demo Hmmm.... I wonder why that is......

I mean, I guess it's fine to mock stuff here, but when I tried clicking the button, I first opened the network tab of devtools, and was confused by the lack of any request being made. (The console explained, showing "[HTMX Demo Mock] fetch: POST /demo/clicked" and "[HTMX Demo Mock] Returning mock for: POST /demo/clicked")

Your demo shouldn't have explicit lies, such as "It worked. That was an actual HTMX POST request. The "server" returned this HTML and HTMX swapped it in."

I mean, I guess maybe it made an HTMX POST request, not an HTTP POST request? But this does reduce my trust in the article.

Re: Please just try HTMX

#235

Post by n4pw01f »

I have used HTMX extensively with AI agents. It is fantastic for dynamic views.

Agent one: handles the request and does tool calls

Agent two: reads the result and decides on quality vs a re-drive if it’s low quality

Agent three: decides how to present the information to the user, creates a collection of HTMX elements

HTMX hx-get is reliably, and beautifully rendering the result of the Agentic Workflow without any react, etc.

Very happy and passing quality gates. I love not having security alerts every week to patch because of some buried react dependency library

Re: Please just try HTMX

#236

Post by otherme123 »

g947o wrote: post #25
geoffeg wrote: post #11

> After the user downloads 2MB of JavaScript, waits for it to parse, waits for it to execute, waits for it to hydrate, waits for it to fetch data, waits for it to render... yes, then subsequent navigations feel snappy. Congratulations. In my experience, a lot of SPAs transfer more data than the front-end actually needs. One team I worked on was sending 4MB over the wire to render 14kb of actual HTML. (No, there wasn'…

even for "downloads 2MB of JavaScript", it is often simply because the site is badly written (e.g. not careful about managing dependency), not necessarily because "JAVASCRIPT BAD". Just look at the source code of amazon.com. It's a mess. But I bet it is more of an organizational problem than a tech stack problem, for a website worked on by literally hundreds of teams (if not more) where everyone crams their little fe…

> it is often simply because the site is badly written

I find that some techs tend to cause badly written code. I have junior coworkers that can write clear Python after a short intro, but can't write clean R after a year using it daily. I don't know if it is caused by the philosophy behind the language, the community, the tutorials and docs...

Re: Please just try HTMX

#237

Post by djeastm »

adamzwasserman wrote: post #181
perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

I was able to find architectural patters that work smooth as glass. Here is what my htmx apps have: - Single-purpose endpoints: Each endpoint returns ONE thing (a card list, a tag cloud, a form fragment) - Optimistic UI: Preferences like font/theme update the DOM immediately; the save is fire-and-forget with no response needed - Simple error handling: Most endpoints either succeed (return HTML) or fail (HTTP error co…

Please do a write up of the best practices you've found. I tried htmx a few years ago for a side project and while I appreciated the simplicity of a lot of it, I had trouble understanding how/when to use it and in what ways. I think I was trying to contort it too much into my understanding of api/spa. That or my interactivity needs were too complex for it, I can't tell.

These days, I admit, though, the ship has sailed for me and htmx. My main app frontend is React and since the LLMs all know much more than I do about how to build out UIs and are 100x faster than me, I'll probably be sticking with React.

Re: Please just try HTMX

#238

Post by CooCooCaCha »

krzyk wrote: post #189
CooCooCaCha wrote: post #85

Earlier quoted context omitted.

What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it. React is easy for small websites so why would I use a separate framework when I can use one framework for everything?

> What I don’t get is why I’d use it if I can’t write a reasonable complex SPA with it. Because most webpages don't need to be SPAs. I miss the days of jquery and html+css, where everything was snappy, and wasn't an SPA.

Plain react is arguably just as simple if not simpler than jquery.

And I’m not saying every site needs to be an SPA. I’m saying if I can write everything from a simple site to an SPA in a single framework then why not use that for everything?

Re: Please just try HTMX

#239

Post by robinhood »

bottlepalm wrote: post #215
stefan_ wrote: post #80

Earlier quoted context omitted.

It's terrible, why would I want my endpoints to return random HTML fragments? I realize thats how you did it in the JQuery times, but I was never in those - at that time we simply had template engines in the backend so this HTML slop wouldn't contaminate everywhere.. Most of the frontend stuff I do is for internal pages on embedded devices, and I'm very happy with a structure where I have the frontend being a full Re…

Returning HTML sounds like a styling nightmare, if anyone changes the structure, unintended consequences. Plus it’s difficult to reason possible states of the UI with fragments sitting on the server, possibly dynamically built on the server. Very jquery/PHP ish. I had my fun and don’t want to go back.

Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.

Re: Please just try HTMX

#240

Post by robinhood »

Yet another thread of React vs the rest of the world. Each has its use case, and most of the time, React/Vue are largely overkill. Personally, I would never, ever, ever start another React project again. The nightmare of the horrible JS ecosystem, build steps and tooling is behind me. All my projects now use either HTMX or Alpine Ajax - and for web apps that are actually pretty large. It works perfectly fine. Add Turbo to the mix and you almost have the feeling of using a real SPA, without the headache and large bundled JS files. Feels refreshingly simple. Still have to figure out the no-build step so I can completely drop Bun/Yarn/Npm, and life will be a wonderful thing.
Post reply on HN