Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx in a Nutshell

htmx.org

Post reply on HN
Print view View original

371–380 of 414 posts

Re: Htmx in a Nutshell

#371

Post by rswskg »

t8sr wrote: post #150
theptip wrote: post #121

Earlier quoted context omitted.

The great thing about HTMX is it fits really nicely with templated server-rendered frameworks like Django. You can have a page with a list of items. The page is one template, and it includes a sub-template which is just the items. Then you have a separate view for "get list fragment" which just returns the updated/sorted/filtered , rendered with that same sub-template. If you toggle the ordering, or filter the list,…

But you can already do that. I was doing it in the 90s, Ruby on Rails supports it, etc. Just send the HTML if you want to and call `el.innerHTML = response.body`. The false dichotomy here is that it's either htmx or React. Why not... neither?

Also an old head here - so glad I'm seeing you write this, I was beginning to wonder myself!

Re: Htmx in a Nutshell

#372

Post by ksec »

zelphirkalt wrote: post #48
leetrout wrote: post #3

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX h…

But HTMX is a JS library. Anything done with it is basically done with JS.

Well, I hope someday HTMX will be HTML6.

Re: Htmx in a Nutshell

#374

Post by silver-arrow »

sandGorgon wrote: post #334
silver-arrow wrote: post #30

Have been using htmx for a little over a year now, and I am so thankful for this library. It has simplified our development tremendously from ClojureScript / React to vanilla Clojure on the backend doing SSR of HTML with htmx HTML element attributes. All with 1 script tag that includes this wonderful library. Kudos to the creator of htmx! This is what hypermedia architecture with true HATEOAS is all about. It feels l…

here's a question to you...since ur like, almost from the Java world! Why not clj-thymeleaf ? or even clojurescript ? this is very interesting that you find HTMX better than clojurescript - typically clojure devs prefer to stay within the lisp world for any markup. ive been getting pushback in a java team against htmx. cos the value prop is unclear vs jsp or thymeleaf. Would love to hear ur perspective.

I see bnert gave a very good answer to your question in a reply. So to echo what bnert said, as far as the java template frameworks like jsp and thymeleaf, htmx is complementary to them. Here is a good scenario in this blog post by someone. https://www.wimdeblauwe.com/blog/2021/10/04/todomvc-with-thy...

Also like bnert, when using Clojure we prefer to use a library on the server-side called hiccup to generate HTML from Clojure data structures instead of a template library. Either way, template engine or hiccup HTML generation, the principle is the same. You are coding everything on the server-side and rendering HTML back to the browser - something it is VERY good at rendering. :) As part of that HTML rendering, you are putting attributes on some HTML elements that htmx understands from the browser side.

ClojureScript is a totally different concept, as it basically allows a Clojure developer to write JavaScript in Clojure - it generates JS. With the server-side rendering model above, we still code 100% in Clojure, but we get to jettison a lot of the complexity of the ClojureScript model (Reagent etc), and development set-up. It is far simpler.

Other benefits of the hypermedia approach provided by htmx: 1. It is obviously true HATEAOS, so we don't worry about end-point versioning issues. 2. The barriers of the UI team and Server team negotiating and re-negotiating end-points is gone. We have all transitioned to "full stack developers" - sanely. 3. As mentioned above, it is language and server-side agnostic, so use what you prefer and have competitive advantage with using. 4. Simpler mental model. The team thinks in hypermedia terms from a server rendering perspective only. That lets you wrap your brain more easily around the business problems. 5. You have the full power and capability of your database at your disposal instead of going through and desigining the correct endpoints to get there first.

Hope that made sense

Re: Htmx in a Nutshell

#375

Post by silver-arrow »

sandGorgon wrote: post #335
silver-arrow wrote: post #283

Earlier quoted context omitted.

The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags. Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements…

why hyperscript and not alpine.js ? just asking. alpine.js seems to be a lot more popular generally (even without htmx)

Hmmm. alpine.js does complement htmx very well and is pretty popular, so it is a great choice. I liked _hyperscript when I saw it when assessing htmx so thought they might play better together since the author is the same for both. But I don't know if that is even really true actually, and alpine.js seems to be just fine. Honestly, it may be because I used AppleScript back in the day and _hyperscript reminded me of it!

Re: Htmx in a Nutshell

#377

Post by bnert »

silver-arrow wrote: post #374
sandGorgon wrote: post #334

Earlier quoted context omitted.

here's a question to you...since ur like, almost from the Java world! Why not clj-thymeleaf ? or even clojurescript ? this is very interesting that you find HTMX better than clojurescript - typically clojure devs prefer to stay within the lisp world for any markup. ive been getting pushback in a java team against htmx. cos the value prop is unclear vs jsp or thymeleaf. Would love to hear ur perspective.

I see bnert gave a very good answer to your question in a reply. So to echo what bnert said, as far as the java template frameworks like jsp and thymeleaf, htmx is complementary to them. Here is a good scenario in this blog post by someone. https://www.wimdeblauwe.com/blog/2021/10/04/todomvc-with-thy... Also like bnert, when using Clojure we prefer to use a library on the server-side called hiccup to generate HTML fr…

Thanks for calling out some gaps in my explanation! Appreciate your perspective :)

Re: Htmx in a Nutshell

#378

Post by HenriTEL »

talideon wrote: post #177

HTMX is the perfect example of a project that, like jQuery, exists to be replaced with a W3C standard. And I don't think the people behind it would feel at all bad about that, as it fills a real niche that ought to have been filled a decade ago.

HTML imports got deprecated in favor of ES modules, because JS was required anyway to use those imports. I was disappointed at the time as I wish we could make web components without touching JS directly. Now with HTMX the future sounds promising.

Re: Htmx in a Nutshell

#379

Post by adamckay »

sandGorgon wrote: post #360
adamckay wrote: post #357

Earlier quoted context omitted.

> Could you talk about where it fails If the HTTP request that htmx has made returns a status code >= 400 or times out then the response will not be swapped into the body. There are several events that htmx fires, once of which can catch `responseError` [1] and you can write some Javascript to handle it according to your requirements (throw a toast, swap anyway by setting `evt.detail.shouldSwap = true`. In a project…

this was super duper useful! so would you say that one of the first things a htmx based project should do is handle all the error conditions ? like all the 40x and 50x ? and stuff like your modal thinggy ? how do you develop the js here ? do you setup a different nodejs/npmjs toolchain. or do the jqueryish development of edit->browser reload ?

> so would you say that one of the first things a htmx based project should do is handle all the error conditions ? like all the 40x and 50x ? and stuff like your modal thinggy ?

IMO yeah, but different pages and actions will (probably) want different things. For example clicking a button that makes a POST request may make more sense to have a red toast notification if it fails, however a tab that dynamically loads its content in using htmx might want a dummy placeholder saying "Sorry, try again later" or something like that. Functionality around the modals were done as and when we needed them and then expanded on over time so I don't think you need to write/know everything up front. It's honestly been a joy to use based on how simple it is once embrace server side rendering.

> how do you develop the js here ? do you setup a different nodejs/npmjs toolchain. or do the jqueryish development of edit->browser reload ?

For my projects it's just 1 or 2 JS files that are included in my base template that contain the event handlers, so it's quite old school of edit and refresh. I use Django mostly now so I can use that to collect and minify static files so it's low effort/complexity.

The only down side is for the few JS packages I do need (e.g. Select2 for nice dropdowns) I either vendor the package in (no automatic updates) or use NPM (but it's a pain). Again, depends on what you want because htmx doesn't care either way.

Re: Htmx in a Nutshell

#380

Post by jonotime »

jonotime wrote: post #291

I like HTMX. But I got stuck with the fact that there is no url routing or history. After using things like React and Angluar, I am used to having well defined urls that can get me where I want. Perhaps there is some recommended way to add some other library ontop of htmx, but maybe I'm the only one looking for this?

Interesting, thanks. I stand corrected on the history part. But routing is still left to the user (its even explicitly mentioned in the doc you linked to.

For example if a user clicks a link in their email to /movies/2001, it does not know to show the movies frame with the 2001 content. We have to implement some kind of url parsing to determine what divs need updating and then update those on first page load.

Post reply on HN