Live data from Hacker News

Htmx in a Nutshell

htmx.org

141–150 of 414 posts

Re: Htmx in a Nutshell

#141
post #98

I 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 screwed around for hours trying to get my first JS fetch code implemented recently.

I found HTMX a few months after, and had it doing AJAX in probably 10 minutes. It has been unbelievably easy to use and helpful.

Re: Htmx in a Nutshell

#142
post #94

Earlier quoted context omitted.

> as if this sort of thing doesn't exist in other languages and stacks It doesn't. For example in the Java world and in the last 10 years there were only two "frameworks". Just Spring and Oracle/Java EE Now two more have appeared (Quarkus and Micronaut) bringing the total number of frameworks to 4.

Is the argument here that there are too many JS frameworks, or that the complexity of the frameworks themselves tends to grow over time? If the former, totally agree. If the latter, Java frameworks are plenty complicated. Also not sure how you've missed a lot of other frameworks; Spring and J2EE are certainly not the only ones that have been around for 10+ years. Dropwizard, Vert.x, akka-http, GWT, Play... just to na…

The argument is that I could learn Spring in 2002, find a Job then I could learn Spring in 2008 and find a job and then I could learn Spring in 2013 and find a job and then learn Spring in 2018 and find a job and then learn Spring in 2023 and find a job.

Spring IS complex, but you learn it once and you are done with it.

Re: Htmx in a Nutshell

#143
post #75

I'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…

It's just a JS library that attaches behavior to HTML elements based on attributes where you'd otherwise have to write a bunch of JS yourself. It's just a framework where all the metadata is just embedded in the HTML.

Re: Htmx in a Nutshell

#144
post #127

"When a user clicks on this link, issue an HTTP GET request to '/blog' and load the response content into the browser window" Why do you want that? Sounds a bit like the hacky stuff PHP did in the first half of the 00s.

It's for building SPAs (https://en.wikipedia.org/wiki/Single-page_application)

Re: Htmx in a Nutshell

#145
post #97

Earlier quoted context omitted.

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.

This idea used to be called microformats. The premise was that you send an HTML snippet, and all the semantic attributes plus a protocol definition will let you parse it as either data or a part of the UX. It's self-documenting in the sense that, if you do it right, the snippet has clear semantic meaning.

However, it's not backward and forward compatible as either UI or data, because that was never an explicit goal of HTML. It's also much slower to process because:

1) Network IO is CPU intensive, so sending more data is worse

2) HTML is not optimized for data interchange. Parsing a protobuf is probably at least 10x faster than parsing the same data out of an HTML microformat.

Re: Htmx in a Nutshell

#147
post #75

I'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…

It's just a JS library that attaches behavior to HTML elements based on attributes where you'd otherwise have to write a bunch of JS yourself. It's just a framework where all the metadata is just embedded in the HTML.

Yeah, but why? Why is it better to remember a bunch of attributes than to remember 3-4 javascript functions?

Re: Htmx in a Nutshell

#149
post #98

I 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'm using htmx for my SaaS web app. It has a lot of spreadsheets. User can filter, sort, highlight with color, etc. It's for PPC managers, they work a lot with spreadsheets. So I'm making a specialized version of that. First two weeks was tough, but after I adapted and found htmx idiomatic recipes to common tasks, it is crazy productive. I can show, if you are curious hit me at twitter @alexblearns. PS. I just believ…

Sounds like you should be writing some blog posts about writing complex applications with this stuff

Re: Htmx in a Nutshell

#150
post #75

I'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…

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?

Post reply on HN