htmx 2.0.0-beta1
v2-0v2-0.htmx.org
htmx 2.0.0-beta1
1–10 of 88 posts
Re: htmx 2.0.0-beta1
#2There's a kind of satisfaction I get when I browse hypertext that loads in less than 100ms that I never get with slower sites.
Re: htmx 2.0.0-beta1
#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?
Re: htmx 2.0.0-beta1
#4I 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 understand that it is just a simple framework and it addresses an industry-related issue, but migration is a lot of effort. Does HTMX really provide enough value to justify the engineering investment required?
Re: htmx 2.0.0-beta1
#5> 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.)
Re: htmx 2.0.0-beta1
#6> 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?
I think this is the relevant bit from RFC 9110:
> A client SHOULD NOT generate content in a DELETE request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.
By way of analogy with POSIX, `cat` (GET) and `rm` (DELETE) both just take a file path, whereas writing or overwriting a file (POST/PUT) also require something (a request body) to write.
Re: htmx 2.0.0-beta1
#7> 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?
I tend to make DELETE work without parameters, but allow them in the body (JSON) for non-essential but helpful options. And example is allowing a flag to override delete protections. I doubt this is a “best” practice but I’ve never had a problem with it, or been asked to change it for compatibility.
Re: htmx 2.0.0-beta1
#8> 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?
The resource to be deleted should be identified in the URL, so there is no need to pass a body. This is the same for `GET`.
Re: htmx 2.0.0-beta1
#9> 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?
The resource to be deleted should be identified in the URL, so there is no need to pass a body. This is the same for `GET`.
This is how I've used DELETE. Something like DELETE /users/{uniqueUserId}. In ~10 years of building CRUD apps I don't think I've ever sent a body or query params with a request.
Re: htmx 2.0.0-beta1
#10I 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…
For now I’ve decided to sit on React/Nextjs and actually focus on solving problems rather than playing the framework/UI library game that leads me nowhere.
I totally get your sentiment.