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

341–350 of 530 posts

Re: Please just try HTMX

#341

Post by [deleted] »

azangru wrote: post #306
Octoth0rpe wrote: post #275

Earlier quoted context omitted.

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

> One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second. The Hacker News website runs on Lisp. How many jobs do you see on the market that ask for Lisp? And yet, for what it is, this site is amazing! I don't see them rushing to migrate to a python backend and a react-based frontend, no matter how many jobs there are for those.

[deleted]

Re: Please just try HTMX

#342

Post by bccdee »

bottlepalm wrote: post #287
robinhood wrote: post #239

Earlier quoted context omitted.

Clearly you haven't used something like HTMX. Do you understand what "returning HTML by the server" mean? You are basically sending back a view, like you would in any other framework actually. This would be the exact same pattern as displaying or dynamically adding a new component from either React or Vue. It doesn't create any styling issue at all, nor any unintended consequences.

I’ve used jquery which is very heavy into html fragments. It can get unwieldy compared to keeping all your rending logic in one place and applying data to it like in React. Other comments here validate the suspicion that HTMX can fall apart in large systems. Unless you’re saying the components returned by HTMX are using the shadow dom for isolation, you can very easily run into styling problems by changing a style an…

Well yeah, HTMX wouldn't be a good fit for micro-frontends, but I didn't think many people were actually using those. You have to write all your html in accordance with a single stylesheet, but that strikes me as the least of HTMX's impositions.

Re: Please just try HTMX

#343

Post by chuckadams »

azangru wrote: post #306
Octoth0rpe wrote: post #275

Earlier quoted context omitted.

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

> One language has 2 jobs, and the other language 13k jobs. I doubt you'd think for more than a second. The Hacker News website runs on Lisp. How many jobs do you see on the market that ask for Lisp? And yet, for what it is, this site is amazing! I don't see them rushing to migrate to a python backend and a react-based frontend, no matter how many jobs there are for those.

Not just Lisp, but Arc at that. That's about as niche as it gets.

Re: Please just try HTMX

#344

Post by bccdee »

leoedin wrote: post #197
ErroneousBosh wrote: post #123

Earlier quoted context omitted.

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

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

Re: Please just try HTMX

#346

Post by aembleton »

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

Re: Please just try HTMX

#348

Post by rodolphoarruda »

lgvld wrote: post #332
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…

I love Unploy, the documentation as well, but I find it a bit too complex. For even simpler usecases I often use Alpine AJAX [1], which is an Alpine.js plugin giving your links and forms -- only, because progressive enhancement -- basic AJAX capabilities. [1] https://alpine-ajax.js.org/

I first read about Unpoly in Stephan Schmidt's Radical Simplicity website[1], I liked it's value prop and decided to try it. I found it bit too complex just as you said. A long time later I came across htmx and decided to try it even after reading a side comment that the library was "like unpoly". 15 minutes later I had a simple to-do list running htmx ajax calls using php and mysqlite in the backend. It was so easy I could not believe such thing could exist. Then I decided to read the Hypermedia book and never stopped using htmx in my projects.

[1] https://www.radicalsimpli.city/

Re: Please just try HTMX

#349

Post by stefan_ »

bccdee wrote: post #344
leoedin wrote: post #197

Earlier quoted context omitted.

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

> 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 website? Build it all down to a simple zip bundle, the ARM can serve those static files just fine. The SPA talks to the ARM via a few JSON APIs. Very nice clean boundary.

Re: Please just try HTMX

#350

Post by wvbdmp »

yellow_lead wrote: post #231
adamzwasserman wrote: post #181

Earlier quoted context omitted.

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…

How do you handle HTTP errors? Just curious because when I used HTMX I didn't enjoy this part.

I like to return errors as text/plain and I have a global event handler for failed requests that throws up a dialog element. That takes care of most things.

Where appropriate, I use an extension that introduces hx-target-error and hx-swap-error, so I can put the message into an element. You can even use the CSS :empty selector to animate the error message as it appears and disappears.

Usually the default behavior, keeping the form as-is, is what you want, so users don’t lose their input and can just retry.

Post reply on HN