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

361–370 of 530 posts

Re: Please just try HTMX

#361

Post by sudodevnull »

qingcharles wrote: post #206
kitd wrote: post #37

Earlier quoted context omitted.

This is the thing. Htmx is great if you only consider the frontend. But it does require fixing up the backed to match. A framework like that needs to integrate the front & back ends fairly tightly to have good UX. You may be interested in Datastar which does this better IMHO https://data-star.dev/

My current plan is to switch to Datastar too, although the devs seem a little odd. The guys writing HTMX seem like a more professional bunch.

you have a point https://x.com/htmx_org/photo

Re: Please just try HTMX

#362

Post by wvbdmp »

aembleton wrote: post #346

> The server just returns HTML (not JSON, actual HTML) Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable. That way all of the front end code is in one place.

But the front end code is in one place, and that place is the server. It is true, though, that the experience greatly benefits the easier it is to manage and return partials from backend code. Some frameworks make it harder than others.

Re: Please just try HTMX

#363

Post by aembleton »

turtlebits wrote: post #352
aembleton wrote: post #346

> The server just returns HTML (not JSON, actual HTML) Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable. That way all of the front end code is in one place.

In the simplest web server, the server returns HTML. Having the backend return JSON is where you're adding complexity. Your front end code won't even work without some base HTML.

Having the html stored both on a static html site that can be cached and in the code base of a backend server is more complex to me than keeping these concerns separate.

Re: Please just try HTMX

#364

Post by aembleton »

wvbdmp wrote: post #362
aembleton wrote: post #346

> The server just returns HTML (not JSON, actual HTML) Thats the thing I don't like. I don't want parts of the structure of my page coming from the backend server. I just want that to send data, as JSON and for the front end to handle that into whatever structure it deems suitable. That way all of the front end code is in one place.

But the front end code is in one place, and that place is the server. It is true, though, that the experience greatly benefits the easier it is to manage and return partials from backend code. Some frameworks make it harder than others.

I'd rather have the often loaded static html running on a server that is optimised for that job, or served from a cache close to the user. The backend can then just serve up the dynamic content and be optimised for that job.

Re: Please just try HTMX

#365

Post by beders »

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?

Re: Please just try HTMX

#366

Post by listenallyall »

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.

To "get" HTMX, you have to think server-first. State is persisted on the server and all state-change logic is performed on the server (often triggered by http requests from a "dumb" client).

If you hang on to "possible states of the UI" that are client-side only then yes you'll have some difficulty implementing server-generated HTMX responses but more importantly, when your client has state that sometimes isn't in sync with, or shared with, or validated by your server, you're setting yourself up for errors and bugs that will exist regardless of framework.

In short, HTMX forces you to apply "single source of truth" concepts to your application.

Re: Please just try HTMX

#367

Post by IgorPartola »

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…

I have never loved the idea of the server rendering HTML which is probably why I have such a hard time with HTMX. In every other paradigm you clearly separate your server API and UI rendering/logic. Web apps are the only place where it seems common to have the server render UI components. Imagine if you had a Java or Swift application and had the server sending your phone UI screens. I don’t even know how you would pitch that. About the only thing I have seen that makes some sort of sense here is video game rendering to be able to play on really limited devices with quick internet access.

The problem with SPAs is the ecosystem. I recently found packages like this [1] and this [2] in my node_modules and that is insanity. But the architecture honestly makes way more sense than any other paradigm: server side is a well defined API and the client renders UI and handles local state.

[1] https://www.npmjs.com/package/isarray

[2] https://www.npmjs.com/package/is-string

Re: Please just try HTMX

#368

Post by AstroBen »

g947o wrote: post #15

I am tired of people using the smallest "Hello World" example to demonstrate how something is better than React -- "See, you don't need all these things to get a website up and running!" Of course it will work. I can vibe code the most terrible web framework you have seen within 20 minutes and claim it is better than React, but what does it prove? > You write zero JavaScript > The whole library is ~14kb gzipped Oh su…

Check out Fizzy from 37signals. They used a similar HATEOAS approach to build it with Hotwire

https://www.fizzy.do

source: https://github.com/basecamp/fizzy

I don't think this is a better approach than React. It's just an approach. It's viable. It's fine

Re: Please just try HTMX

#369

Post by listenallyall »

stefan_ wrote: post #349
bccdee wrote: post #344

Earlier quoted context omitted.

> It has to load HTML templates into memory and insert strings into them. In practice, I doubt this is much slower than serializing JSON. Keeping a couple kilobytes of HTML templates in memory is nothing. Conversely, running a whole vdom on the frontend (typically more resource-constrained than the server) is a much bigger performance issue.

Three levels down and people have entirely forgotten what my post was. My "server" is some anemic ARM core built into real physical hardware with 64M of read-only storage. I don't want it spending its time "hydrating" some DOM, I don't want to bring any of this frontend insanity on there at all. No code hosted on npm shall ever run on that processor or I can't go to sleep in peace. So how do we still get a fancy SPA…

Yes, if your server is a weak, limited processor, you want to keep the demands on it as low and lean as possible, and let the client do the heavy lifting. HTMX is not a good fit for this scenario, just like PostgreSQL is not a good database to embed on your devices.

This isn't a controversial idea and nobody would try to sell you on HTMX for your use case.

Re: Please just try HTMX

#370

Post by amluto »

The Demo 3 Live Search example has really nasty scroll jank issues. I’m guessing it’s caused by the results being inserted inline in the document (and thus redoing the layout of much of the page) instead of being placed in some sort of overlay.
Post reply on HN