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

191–200 of 530 posts

Re: Please just try HTMX

#191

Post by krzyk »

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…

> Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads.

Well, frontend and backend always need to agree on every scenario, that's why I prefer to do validation on backedn and frontend to just display it and not do any validation.

Re: Please just try HTMX

#192

Post by xXSLAYERXx »

dubcanada wrote: post #107
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…

Just to be completely clear... you do not need React just so you can turn JSON into HTML. HTMX can 100% can do that. You're argument is fine assuming you wish to become another react frontend in a sea of react frontends. But the documentation example is a terrible argument, the benefit of HTMX is it is easy to understand what is actually happening. There is no magic, you don't need to dive through millions of lines o…

> become another react frontend in a sea of react frontends

Whats the big deal here?

Re: Please just try HTMX

#193

Post by NewsaHackO »

mixmastamyk wrote: post #147
CooCooCaCha wrote: post #143

Earlier quoted context omitted.

Hello world in react is just a few lines of code that mounts a react component to a dom element. There should be zero network requests beyond the initial download of html and js. You’re either doing something wrong or not actually doing a hello world.

I don’t know but vite was involved, looks like it was setting up live updates. This is part of the problem, you can’t just include a script apparently.

Was it in Dev mode?

Re: Please just try HTMX

#194

Post by mrinterweb »

ChocolateGod wrote: post #178
mrinterweb wrote: post #166

HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy a…

Using JSON over the wire means you can re-use your backend between multiple frontends (like with mobile apps).

Not all web applications need to be have an API that serves other clients. Often web apps are enough.

Re: Please just try HTMX

#196

Post by bobjordan »

I’ve been a fan of this philosophy since the Intercooler.js days. In fact, our legacy customer portal at bomquote.com still runs on Intercooler. I spent the last year building a new version using the "modern" version of that stack: Flask, HTMX, Alpine, and Tailwind.

However, I’ve recently made the difficult decision to rewrite the frontend in React (specifically React/TS, TanStack Query, Orval, and Shadcn). In a perfect world, I'd rewrite the python backend in go, but I have to table that idea for now.

The reason? The "LLM tax." While HTMX is a joy for manual development, my experience the last year is that LLMs struggle with the "glue" required for complex UI items in HTMX/Alpine. Conversely, the training data for React is so massive and the patterns so standardized that the AI productivity gains are impossible to ignore.

Recently, I used Go/React for a microservice that actually has turned into similarly complex scale as the python/htxm app I focused on most of the year, and it was so much more productive than python/htmx. In a month of work I got done what took me about 4-5 months in python/htmx. I assume because the typing with go and also LLM could generate perfectly typed hooks from my OpenAPI spec via Orval and build out Shadcn components without hallucinating.

I still love the HTMX philosophy for its simplicity, but in 2024/2025, I’ve found that I’m more productive choosing the stack that the AI "understands" best. For new projects, Go/React will now my default. If I have to write something myself again (God, I hope not) I may use htmx.

Re: Please just try HTMX

#197

Post by leoedin »

ErroneousBosh wrote: post #123
stefan_ wrote: post #109

Earlier quoted context omitted.

HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.

Okay, so what do you your servers actually serve stuff to? I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.

I think the parent's point is that when you have a react front-end, your back-end basically just deals in structs of data. There's no HTML or templating to think about. It's just JSON-serialisable structs. That makes the code on the back end much simpler, which makes it easier to run in a resource-constrained environment.

The only exposure the back-end has to HTML is streaming the static files to the browser. Which can be done in small chunks.

If your back-end is rendering HTML with every request, it has to do a lot more work. It has to load HTML templates into memory and insert strings into them.

Re: Please just try HTMX

#198

Post by krzyk »

0x3f wrote: post #16

The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?

React (and Angular) is an MVC framework pushed on top of a MVC framework in the backend. Why make things so complex?

Re: Please just try HTMX

#200

Post by adamzwasserman »

johnfn wrote: post #83

> When you click it, HTMX POSTs to /clicked, and whatever HTML the server returns replaces the button. No fetch(). No setState(). No npm install. No fucking webpack config. Can someone explain something to me? To my view, the single best idea React has is that it forces you to encapsulate the full set of states in your component - not anywhere else. For instance, if you have a "Comment" button that becomes "Submitted…

The state encapsulation concern is exactly what DATAOS addresses: dataos.software

The premise is that React's "UI=f(state)" creates a synchronization problem that doesn't need to exist.

If the DOM is the authority on state (not a projection of state held elsewhere), there's nothing to sync. You read state from where it already lives.

I built multicardz on this: 1M+ cards, sub-500ms searches, 100/100 Lighthouse scores.

If you have time to read, I would very much like to hear your thoughts; genuine technical pushback welcome.

Post reply on HN