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

371–380 of 530 posts

Re: Please just try HTMX

#371

Post by Exoristos »

liampulles wrote: post #101

I like HTMX, I use it on my blog. But I will say, in the niche where I need some dynamic DOM changes without needing a full-blown SPA, raw JavaScript with some basic utilities like jQuery is not so bad. The issue with htmx is that it is fairly prescriptive of how one should go about building dynamic interactions, and it becomes complex quickly if the dynamic interaction is more than trivial. I don't disagree with its…

> it becomes an issue when my product owner tells me that I need to do some funny dynamic thing

Okay, but on the other hand maybe you should do the right thing and say no.

Re: Please just try HTMX

#372

Post by listenallyall »

beders wrote: post #365

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

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

Re: Please just try HTMX

#373

Post by listenallyall »

lbreakjai wrote: post #327
recursivedoubts wrote: post #276

Earlier quoted context omitted.

Yep. And that’s a good thing: https://htmx.org/essays/splitting-your-apis/

Splitting application API and generic data API is orthogonal to HTMX. You still have issues compared to plain JSON, don't you? Imagine you need firstName/email in once place, firstName/email in another, and firstName/D.O.B in another. In a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it. My understanding is with HTMX, I'd have to craft (an…

> let the frontend handle it

via 3 different rendering logic, (such as JSX templates) same as the server

> if you hide the complexity under the bed!

which is what you just did by dismissing the reality that client-side requires the same 3 renderers that server-side requires! (plus serialization and deserialization logic - not a big deal with your simple example but can be a major bottleneck with complex, nested, native objects)

Re: Please just try HTMX

#374

Post by dev_l1x_be »

> No fetch(). No setState()

Just pure eval(). [1]

1. htmx.config.allowEval: defaults to true, can be used to disable htmx’s use of eval for certain features (e.g. trigger filters)

Re: Please just try HTMX

#375

Post by dev_l1x_be »

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…

Real world examples with error handling would be great for HTMX. Now in the LLM era you might get away without those. I just don't understand why can't we have complete documentation for the most basic scenarios.

Re: Please just try HTMX

#376

Post by lbreakjai »

turtlebits wrote: post #355
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…

You need to get out of the mentality that there have be two states. Ultimately the frontend state cannot exist without the backend, where data is persisted. Most apps don't need the frontend state, all it really gives you is maybe a better UX? But in most cases the tradeoff in complexity isn't worth it.

This isn't about state, is it? In a classic react app, if I need to display the name of a user, then I fetch it (from the server) once, and display it as many times as I need, in as many forms as I need. There's only server state.

I don't see how it's any simpler to shift partial presentation duties to the backend. Consider this example:

https://htmx.org/examples/active-search/

The backend is supposed to respond with the rows to fill a table. You have an extremely tight coupling between the two. Something as simple as changing the order of the columns would require three releases:

- A new version of the backend endpoint - A frontend change to consume the new endpoint - A version to delete the old endpoint

I'm not trying to be obtuse, but I fail to see how this makes any sense.

Consider something as simple as an action updating content in multiple places. It happens all the time: changing your name and also updating the "Hello $name" in the header, cancelling an order that updates the order list but also the order count ...

There's _four_ ways to do it in HTMX. Each "more sophisticated" than the previous one. Which is one really wants, sophistication, isn't it?

https://htmx.org/examples/update-other-content/

I really struggle to decide which example is worse. Not only the backend needs to be aware of the immediate frontend context, it also needs to be aware of the entire markup.

In example two, a seemingly innocuous renaming of the id of the table would break the feature, because the backend uses it (!) to update the view "out of band".

I'm really trying to be charitable here, but I really wonder what niche this is useful for. It doesn't seem good for anything complex, and if you can only use it for simple things, what value does it bring over plain javascript?

Re: Please just try HTMX

#377

Post by bccdee »

listenallyall wrote: post #369
stefan_ wrote: post #349

Earlier quoted context omitted.

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.

1. No, templating strings is actually quite cheap. I'm doubtful that you could benchmark any substantial difference between templating html and serializing json.

2. Who has a server with a weak, limited processor? HTML templates power Django, Rails, and PHP. This paradigm worked fine on the servers of 20 years ago, in the slowest languages we use. I could serve a Django app on my phone and see reasonable performance.

Re: Please just try HTMX

#378

Post by jabbywocker »

puppy_lips wrote: post #258
nrclark wrote: post #120

Earlier quoted context omitted.

fwiw I'm the CEO of htmx, and I am a huge fan of these types of hyperbolic articles.

I am starting to understand htmx.

As the CEO of HTMX I can assure you that you’ve only scratched the surface of the HATEOAS doctrines

Re: Please just try HTMX

#379

Post by array_key_first »

epolanski wrote: post #322
krzyk wrote: post #191

Earlier quoted context omitted.

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

That makes for some nasty debugging and unsafety. Both sides should parse both times, unless you're encountering real (not imaginary) performance issues. As someone who's been parsing everything entering the system from 2018, I don't believe you can have performance issues by parsing the data entering the system, the only exception I can name in a decade was real time trading app where the data coming in all time was…

Frontend and backend will always diverge and 90% of your bugs will be around that. Mitigating the divergence is the primary goal of every web framework, both backend and frontend, when you sit back and think about it.

Re: Please just try HTMX

#380

Post by yawaramin »

catapart wrote: post #290
yawaramin wrote: post #253

Earlier quoted context omitted.

Invokers don't give you what htmx gives you out of the box. If you want to, for example, have an invoker command to fetch a resource and swap it in to the page, you have to write custom JS for that. That's the thing that htmx gives you out of the box, along with error handling, progress indicator support, history support, animated transitions, and a host of other features. If you don't need or want all these and are…

As you should be able to tell from the other comments, this is not a library for me. If I had ever looked into it past trying to actually implement it, I would have realized that it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much. The author made that very clear in the supporting documentation, I just never bothered to check. So I relayed my persona…

> it's actually specifically for server-rendered content and using it for front-end development doesn't actually add much

It's for server-rendered content that can be used to build a frontend app. I know because I've done it several times.

> I would also have to write custom JS for the functions I would try to invoke with htmx

The difference is with invokers you would have to re-implement everything from scratch and with htmx you typically only need to implement some parts that it doesn't handle, like eg listening to a DOM event and doing some action in response.

Post reply on HN