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

htmx 2.0.0-beta1

v2-0v2-0.htmx.org

Post reply on HN
Print view View original

31–40 of 88 posts

Re: htmx 2.0.0-beta1

#31

Post by traceroute66 »

danielvaughn wrote: post #17
traceroute66 wrote: post #15

There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes). Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled grac…

I didn’t know that, that’s interesting. I’d expect 100-199 responses to be able to render a result as well, at the very least.

> I didn’t know that, that’s interesting.

Yeah, it caught me by surprise first time I used htmx. I spent forever trying to troubleshoot why it wouldn't render the error message, then I discovered it was the old "feature not a bug".

Re: htmx 2.0.0-beta1

#32

Post by thom »

traceroute66 wrote: post #15

There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes). Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled grac…

This is all handled in an extension:

https://htmx.org/extensions/response-targets

I don’t know what kludge you’re referring to, it requires you to add basically two attributes to your HTML, it’s really no hardship at all.

Re: htmx 2.0.0-beta1

#33

Post by leptons »

mamcx wrote: post #30
wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

Htmx is what you want for making websites . This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication. So, if you are serving HTML, then htmx. When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop). (and in short amounts like…

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX.

Seems that HTMX requires unsafe-eval?

https://github.com/bigskysoftware/htmx/issues/2260

Re: htmx 2.0.0-beta1

#34

Post by jfengel »

paulddraper wrote: post #5
hu3 wrote: post #3

> DELETE requests now use parameters, rather than form encoded bodies, for their payload (This is in accordance w/ the spec.) As someone who rarely use DELETE requests, what's the best practice for passing parameters and why?

Query params. DELETE cannot have request body, just like GET cannot have a request body. (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.)

Question: what is the proper verb to use with a query? I always thought of it as a GET and passing the query via the body. You are GETting information, rather than trying to add information.

For that matter I've never quite figured out when to use POST vs PUT. POST doesn't feel right for a query.

Re: htmx 2.0.0-beta1

#35

Post by ForHackernews »

merpnderp wrote: post #19
wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

Isn’t this really just going back to the server side templating days and using jquery to load html snippets?

Yes, it's an implementation of the radical idea that we should deliver HTML (rather than a giant blob of JS) to clients purpose-built for rendering HTML.

See also https://hotwired.dev/

Re: htmx 2.0.0-beta1

#36

Post by pfraze »

leptons wrote: post #33
mamcx wrote: post #30

Earlier quoted context omitted.

Htmx is what you want for making websites . This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication. So, if you are serving HTML, then htmx. When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop). (and in short amounts like…

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260

I’m guessing the issue is devs putting business logic constraints in the client and not duplicating them in the server

Re: htmx 2.0.0-beta1

#37

Post by traceroute66 »

thom wrote: post #32
traceroute66 wrote: post #15

There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes). Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled grac…

This is all handled in an extension: https://htmx.org/extensions/response-targets I don’t know what kludge you’re referring to, it requires you to add basically two attributes to your HTML, it’s really no hardship at all.

> This is all handled in an extension

And why should I need to load an extension to handle a 400-series ? That's just nuts.

The kludge is loading the following JS snippet on your page:

   if(evt.detail.xhr.status >= 400 && evt.detail.xhr.status

Re: htmx 2.0.0-beta1

#38

Post by tomcam »

ledgerdev wrote: post #22
wqtz wrote: post #4

I am interested in learning about how something is being used and in what context, instead of what it has to offer. Can anyone tell me if they are using HTMX in a proven environment, like a user-facing environment? I think adopting HTMX as a framework would be difficult to switch from a React, Vue, etc. environment. I think using it inside internal tooling or a hobby project will not be able to justify its merit. I u…

I used htmx to build a now in production multi-step payment form that's currently in use by several hundred thousand people per month. It's been great, but not perfect and I would say a less well trodden path to get the edge cases right. I would absolutely say it's been a simpler overall solution for us as a small team than a full js client side framework would have been. Things that were hard to get right were setti…

Super balanced & informative writeup, thank you. Can you tell me what you mean by tab sleep restoration?

Re: htmx 2.0.0-beta1

#39

Post by sebazzz »

traceroute66 wrote: post #15

There's a lot to like about htmx, but one thing that does not sit well with me is its opinionated design decision that it will only render content if its sent with a 200 OK (tech TL;DR: shouldSwap defaults to false for non-200 response codes). Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled grac…

> Most sane services will only return a 200 OK if, well, things went OK. Most sensibly designed services will return 400 range if an error has occurred that has been handled gracefully.

Yes, but you are not designing your MVC controller as a REST service, and are not trying HTMX to your REST API directly. This makes sense if you think of it from this perspective, like the classic MVC view-rendering controller behind your HTMX page.

Re: htmx 2.0.0-beta1

#40

Post by Terretta »

leptons wrote: post #33
mamcx wrote: post #30

Earlier quoted context omitted.

Htmx is what you want for making websites . This means, that almost all uses of react and friends are wrong, a waste, or an unnecessary complication. So, if you are serving HTML, then htmx. When you reach for react? If you are making an app of the kind that you should have use a non-web thing (because is now necessary to bend with major complicated hacks HTML to make a clone of Photoshop). (and in short amounts like…

Curious what part of React you think makes it "hacker friendly". React can be done very simply, and I see no part of it that makes it any friendlier to "hackers" than HTMX. Seems that HTMX requires unsafe-eval? https://github.com/bigskysoftware/htmx/issues/2260

Actual hackers, the ones who try to hack your e-commerce site.

For such things, if you're not doing everything Server Side to Render fully validated and sanitized data safely, you should be.

Post reply on HN