Top
Best
New

Posted by iNic 6 days ago

Please just try HTMX(pleasejusttryhtmx.com)
614 points | 502 commentspage 5
delbronski 6 days ago|
My main use of HTMX is to hack the Django Admin here and there. It works great for that. I’ve tried to use it in a moderately complex app and it became such a mess so quickly. I’m sticking with React for frontend stuff for now. Works well enough and I’m used to it now.
pawelduda 6 days ago||
To prove the point, author mentions company that went from React to Htmx and saw positive change in relevant metrics. When you do that, it usually means your app has matured in a sense and you can be sure that htmx will be sufficient to handle all the functionality

I'm however more curious about going the other way, i.e. you start a project with Htmx which happily grows but after a while, a large feature is requested which inevitably changes the direction of the app into React use-case territory. I can't think of concrete example but you now have to work around it with htmx or commit to rewriting to React (or alternative). Wonder what are thoughts of people who had to deal with this

hakunin 6 days ago||
For those who build in Ruby on Rails, does htmx have an advantage over Turbo/Stimulus? For me, the sense that it doesn't is why I've been avoiding it. Prefer to stick with vanilla stack unless there's a very compelling reason not to.
bondarchuk 6 days ago||
>The "server" (mocked client-side for this demo

Hmmm.... I wonder why that is......

lkbm 5 days ago|
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.

bondarchuk 5 days ago||
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.
themafia 5 days ago||
No, I'm sorry. Life is too short to write code inside of HTML attributes.
didip 5 days ago||
I love HTMX. It felt like a rebirth of PJAX. Server side template rendering is simply the best.

Too bad that the world insists on going nuts with JS everything.

Oh as a plus, AI agents are a lot more productive when dealing with server side logic.

recursivedoubts 5 days ago|
huge fan of pjax, interviewed @defunkt here:

https://htmx.org/essays/interviews/chris-wanstrath/

H1Supreme 6 days ago||
> But sometimes—and here's where it gets uncomfortable—you actually do need a button that updates part of a page without reloading the whole damn thing. You do need a search box that shows results as you type. You do need interactivity.

You can do this with plain old Javascript. Make a request, swap out the [inner | outer]HTML with the result. If you want a nice visual transition, wrap the swap in a startViewTransition(). Obviously, you need to be extra careful if you're using user-submitted HTML. Otherwise, it's fairly straight forward.

joeevans1000 4 days ago||
Weird, Safari reloads the page on the demo button clicks and Chrome does not.

UPDATE: the second visit to the page on Safari didn't have the issue. It's interesting to note that some people might have that effect though... reloads on Safari occasionally for whatever reason. Or it could be something rare on my end.

JohnMunsch 3 days ago||
False dichotomy. Your only options aren't HTMX or React/Vue/Svelte when web standards like custom elements have been here for years, are smaller, faster, and work with all your browsers (including the ones on your phone).
beders 5 days ago|
Can someone who's adapted HTMX for a larger app report about front-end-server costs?

HTMX serves fully baked HTML that needs to be created on the back-end (or front-end-facing servers)

That is more processing than sending the raw data to the front-end and baking the HTML there.

It is also more bandwidth (unless the JSON is more verbose than the HTML generated).

Lastly, I can generate different HTML fragments on the front-end from the same client-side state with the data only being transported once. How is that working out?

listenallyall 5 days ago|
> That is more processing

Not necessarily. Often it is less. Template engines can be very, very efficient and fast.

Returning JSON almost always requires data/object serialization on the server, this is often slower than direct data/object -> template rendering.

Further, it's not your server but keep in mind the client must de-serialize JSON and render some HTML every time.

Modifying layouts as a result of non-persistent state (light/dark mode, sorting, etc) can usually be handled relatively easily with styles and data- attributes and sprinkles of JS. HTMX works very well with Alpine.JS and similar libraries for more complex situations.

HTMX isn't for every scenario, but it works very very well in many scenarios.

More comments...