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

271–280 of 530 posts

Re: Please just try HTMX

#271

Post by bondarchuk »

lkbm wrote: post #234
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…

I don't think it's fine, if even the "just fucking use htmx" page can't be arsed to just actually fucking use htmx then something must've gone wrong somewhere.

Re: Please just try HTMX

#273

Post by adamzwasserman »

lunar_mycroft wrote: post #211
adamzwasserman wrote: post #175

Earlier quoted context omitted.

multicards is almost purely client side interactivity. I STILL use htmx for a number of reasons: - No JSON serialization: HTMX sends form data natively no JSON.stringify() needed - Less JavaScript: Declarative hx-* attributes replace imperative fetch code. in my world declarative always wins. - Automatic headers: HTMX handles X-User-Id and other headers configured globally - Built-in error handling: hx-on::error inst…

You won't keep those performance numbers if the network conditions are bad, unfortunately. For things that require a network round trip, that's fine, because doing it via JSON (or some other serialization format) won't save you anyway. On the other hand, if it can be done entirely on the client, adding network round trips will slow the interaction down. It sounds like you're mostly doing the former (otherwise loading…

I think you misunderstood me. I use htmx where most people would use fetch. I do not just use htmx willy nilly for no reason.

I use pure front end manipulation to set state, then I send the state to the stateless back end with pure functions, and I get amazing performance: www.multicardz.com public test bed, 1M records, round trip usually around 160 ms for anywhere between 1 to 100K hits

Re: Please just try HTMX

#275

Post by Octoth0rpe »

azangru wrote: post #162
librasteve wrote: post #103

Earlier quoted context omitted.

HTMX Sucks https://htmx.org/essays/htmx-sucks/

> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…

> Resume-driven development should not be a thing.

Pretend this is not about library choice, but rather about language choice. One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second.

Re: Please just try HTMX

#276

Post by recursivedoubts »

lbreakjai wrote: post #270

It feels like the worst of both worlds, what am I missing? I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive. I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint. This seems like a worst-of-bot…

Yep. And that’s a good thing:

https://htmx.org/essays/splitting-your-apis/

Re: Please just try HTMX

#277

Post by mostlysimilar »

viiralvx wrote: post #157
recursivedoubts wrote: post #29

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

Damn, Unpoly looks great! Never tried HTMX but have been a fan of it, it solves a UX problem that frameworks like Django and Rails suffer from, without needing to bring in something heavy like React. I'm currently working on a side project in Rails using Stimulus but sometimes I wonder if Stimulus is overkill with all of the controllers and stuff as well. Do you have an opinion on when you should reach for something…

In most simple cases you probably don't want to be handling request-response initiated DOM updates in a Stimulus controller. Turbo Frames and Turbo Streams are the more htmx-like in functionality and they're excellent for this.

Re: Please just try HTMX

#278

Post by placebo »

bobjordan wrote: post #196

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

This got me thinking: I am not about to fight windmills and the future will unfold as it will, but I think the idea of "LLM as a compiler of ideas to high-level languages" can turn out to be quite dangerous. It is one thing to rely on and not to be able to understand the assembly output of a deterministic compiler of a C++ program. It is quite another to rely on but not fully understand (whether due to lazyness or complexity) what is in the C++ code that a giant nondeterministic intractable neural network generated. what is guaranteed is that the future will be interesting...

Re: Please just try HTMX

#279

Post by slekker »

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…

> and is great for agentic AI coding.

Definitely sad to see this everywhere nowadays, tech choices made because of AI

Re: Please just try HTMX

#280

Post by H1Supreme »

CooCooCaCha wrote: post #238
krzyk wrote: post #189

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. 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?

How do you handle routing with plain React?
Post reply on HN