I feel warm and fuzzy inside every time HTMX is featured on the front page :-)
Btw if you are interested in the reasoning of HTMX: https://htmx.org/essays/
Htmx in a Nutshell
111–120 of 414 posts
Re: Htmx in a Nutshell
#112I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an ` Blog ` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".) Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why…
this lib can offer tremendous taste for those looking for an html soup recipe.
[deleted]
Re: Htmx in a Nutshell
#113howdy, I'm the creator of htmx, happy to talk about it
Hi, thanks for the libraries!
When I started using them, one of the hardest parts was to actually have it imported and built with webpack, since the site focuses on cdn and webpack example is really brief. Same goes for hyperscript
Do you see cdn as a preferred way of usage?
Re: Htmx in a Nutshell
#114howdy, I'm the creator of htmx, happy to talk about it
How does error handling work? If I try to replace the content of some div with a reply I get using htmx, but the request fails or times out etc., what content is then put into the div? What if the reply is not valid HTML?
Sorry for the newb and lazy questions.
Re: Htmx in a Nutshell
#115If you just want to use plain HTML with JavaScript, take a peek at Joystick [1]. 100% plain HTML, CSS, and JavaScript based components (zero attribute hacks or compiler tricks). No external libraries for basic functionality (state, data fetching, url handling—all included or relies on native browser functionality). All a part of one full-stack framework that works out of the box. [1] https://github.com/cheatcode/joys…
I had a quick look at joystick and wonder if you have even read anything related to htmx. Nothing against joystick but it seems more an alternative for frameworks like react and svelte. Those are also npm and jsx based. Htmx is nog ;)
Yes, I have. It was one of the things I looked at as part of my initial research before deciding to work on Joystick. What I don't like about is that it's a non-standards based pattern for implementing interactivity in HTML (the same reason I didn't like React, Vue, Svelte, etc).
All of these frameworks try to wedge stuff in between the core languages of the web (HTML, CSS, and JavaScript) for the sake of speed/being clever, but ultimately lead developers into a proprietary skills trap. It's all 100% unnecessary and will (arguably, has) lead to massive confusion and messes in the industry.
By contrast, Joystick uses plain HTML, plain JavaScript DOM events, and plain CSS to build your UI. It just adds some very thin API abstractions over those features to help you move faster.
Re: Htmx in a Nutshell
#116Re: Htmx in a Nutshell
#117I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an ` Blog ` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".) Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why…
Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing. Also if you build stuff on top of hypermedia…
You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.Then you can get rid of almost all your js code.
The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.
Re: Htmx in a Nutshell
#118I don't love the idea of implementing common app state logic via attributes. It probably works a lot better than I'm assuming, but it feels hacky to me. Like it can't solve every problem you'd actually encounter when making a complex app, so eventually you'll need to fall back to using javascript, and possibly a framework or three...on top of htmx. But it does seem like this would be fun to play around with using PHP…
I've used HTMX on several projects (Django) and it's truly a great add in. You can basically build a "React" style app with Django. I can't praise it enough.
Re: Htmx in a Nutshell
#119I'm confused about what value this adds. The introductory example is certainly not helpful, as it takes an ` Blog ` and turns into 7 lines of markup to accomplish the same thing. (And then it says a bunch of things that are arguably not desirable, like "any element can now trigger requests".) Like: what's the point of using this over HTML5+js? I've spent 15 minutes reading the website and I still don't understand why…
Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing. Also if you build stuff on top of hypermedia…
> Also if you build stuff on top of hypermedia APIs then bye bye performance.
This is not obvious to me.
Re: Htmx in a Nutshell
#120Earlier quoted context omitted.
Consider the case of calling your backend with a POST call and then updating your app in response. Typically, for a SPA: your backend would return some data, and your frontend would then figure out how to update your html in response to it. For a multi-page-app: your backend will redirect the user to a whole new page with new HTML. This is somewhere in between: Your backend will send just a little bit of HTML and you…
Yeah, that I understand. I am not a huge fan of sending JSON that's not backwards compatible. Sending HTML is probably a good choice for some applications, but that was already well supported 20 years ago. Why is htmx better than one line of javascript saying `onload = function() { e.innerHTML = response.body` } ?
Please see my answer above, but htmx has some swap attributes where you can declaratively update as many elements of the page as you want. You can grep this id and find all the updates easily.