16 ms·

htmx 2.0.0-beta1

139 points by eatox 3y ago

seanwilson 3y ago
Does general usage of HTMX require `unsafe-eval` in your Content Security Policy (CSP) to allow JavaScript eval? Or there's workarounds that still keep things simple?
- p_l 3y ago
  Not unless you plan on explicitly executing sent snippets of JS, iirc
- mhitza 3y ago
  Probably yes if you use the inline event handler feature it has. https://htmx.org/essays/web-security-basics-with-htmx/#bonus-content-security-policy https://htmx.org/essays/web-security-basics-with-htmx/#bonus...
  - seanwilson 3y ago
    From the link: > Some htmx applications make use of inline scripting—the hx-on attribute is a generalized attribute listener that can evaluate arbitrary scripts (although it can be disabled if you don’t need it). Sometimes inline scripts are appropriate to preserve locality of behavior on a application that is sufficiently secured against XSS, sometimes inline scripts aren’t necessary and you can adopt a stricter CSP. It all depends on your application’s security profile—it’s on to you to be aware of the options available to you and able to perform that analysis. Is hx-on required often? How clunky does it get to avoid hx-on everywhere?
mkl95 3y ago
There's a kind of satisfaction I get when I browse hypertext that loads in less than 100ms that I never get with slower sites.
hu3 3y ago
> 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?
- paulddraper 3y ago
  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.)
  - jfengel 3y ago
    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.
  - chuckadams 3y ago
    DELETE and GET can have bodies, the spec is just vague about it. Elasticsearch commonly uses request bodies for GET, treating it identically to POST. It's not always regarded as a good idea, but it does work.
    - paulddraper 3y ago
      That's why I said: > (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.) To quote RFC 9110: > Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET 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. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. For this reason, Elasticsearch also accepts queries as POST.
wqtz 3y ago
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 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?
- shouldcode 3y ago
  You might want to check out https://hypermedia.gallery https://hypermedia.gallery Disclosure: I built it (without HTMX).
- mr90210 3y ago
  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.
  - jonathanberger 3y ago
    By “sit on” do you mean “keep using” or “avoid”?
    - mr90210 3y ago
      Keep using… Apologies for the lack of accuracy.
- ysleepy 3y ago
  The premise of migrating away from an SPA framework might make it seem weird, but I don't think that's the common adoption path. There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment. It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.
traceroute66 3y ago
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 gracefully. I am aware that you can kludge a hack in the form of a JS snippet to force htmx to render content on !=200, but it shouldn't be that way IMHO.
- danielvaughn 3y ago
  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.
  - andrewstuart2 3y ago
    All response codes should really be able to contain content that doesn't look terrible. A 404 can be a nicely formatted "not found" page that's consistently styled and looks like the rest of the app, for example.
  - traceroute66 3y ago
    > 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".
- thom 3y ago
  This is all handled in an extension: https://htmx.org/extensions/response-targets 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.
  - traceroute66 3y ago
    > 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 <= 499 ) { evt.detail.shouldSwap = true; }
sibit 3y ago
I'm not someone who usually gets excited by new major releases of frameworks/libraries but this one feels different. I got my start with CRUD PHP websites with jQuery. I've been using HTMX for the last year and it fills me with nostalgia while also allowing me to move faster when building UIs.
PreInternet01 3y ago
So, I absolutely love htmx, and this new version offers some incremental improvements that make things even better (unless you were using WebSockets or server-sent events, I guess, but the plug-in model doesn't look too bad?). Unlike all-or-nothing approaches like React, htmx allows you to add just the right amount of partial updates to your web app, using just the technologies that were already there to begin with. I realize that this approach doesn't appeal to everyone, but being able to map simple requests to simple responses was an absolute life-saver for my projects many times over. Migrating to a truly-truly minimalist approach (see: https://www.stefanjudis.com/notes/htmz-a-176-bytes-htmx-alternative/ https://www.stefanjudis.com/notes/htmz-a-176-bytes-htmx-alte...) is still on my to-do list, but for now, I'm quite happy with the htmx status quo.
j3s 3y ago
sick! i’ve been using htmx for a few personal projects & i have to say, it feels like exactly what i was looking for. light, well documented, snappy, easy to work with - i love the idea of endpoints returning pure html instead of json - it feels obvious.
deleted 3y ago
[deleted]
pyrossh 3y ago
Newretrowave fan here. Who would have thought that the creator of htmx listens to synthwave.
minimaxir 3y ago
How much of a performance gain does htmx grant compared to other front-end frameworks? A talk from 2022 implies a significant benefit relative to React but in front-end development years that's an era ago: https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywjNXch-RPQJuAkTiLpleYFQjI/edit#slide=id.g156942fc762_0_105 https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywj...
infogulch 3y ago
I'm just glad I was able to submit my patch before 2.0 released: "Add config option to ignore nested oob-swaps instead of processing them (#1235)" Setting this config makes it easier to use 'template fragments' with oob-swaps, since you can set the hx-swap-oob=true attribute on the element and reuse it to render a whole page or just a fragment of the template. Very nice to use with Go template blocks for example. https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/

139 points by eatox 3y ago

Does general usage of HTMX require `unsafe-eval` in your Content Security Policy (CSP) to allow JavaScript eval? Or there's workarounds that still keep things simple?

p_l 3y ago
Not unless you plan on explicitly executing sent snippets of JS, iirc
mhitza 3y ago
Probably yes if you use the inline event handler feature it has. https://htmx.org/essays/web-security-basics-with-htmx/#bonus-content-security-policy https://htmx.org/essays/web-security-basics-with-htmx/#bonus...
- seanwilson 3y ago
  From the link: > Some htmx applications make use of inline scripting—the hx-on attribute is a generalized attribute listener that can evaluate arbitrary scripts (although it can be disabled if you don’t need it). Sometimes inline scripts are appropriate to preserve locality of behavior on a application that is sufficiently secured against XSS, sometimes inline scripts aren’t necessary and you can adopt a stricter CSP. It all depends on your application’s security profile—it’s on to you to be aware of the options available to you and able to perform that analysis. Is hx-on required often? How clunky does it get to avoid hx-on everywhere?

mkl95 3y ago

There's a kind of satisfaction I get when I browse hypertext that loads in less than 100ms that I never get with slower sites.

hu3 3y ago

> 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?

paulddraper 3y ago
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.)
- jfengel 3y ago
  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.
- chuckadams 3y ago
  DELETE and GET can have bodies, the spec is just vague about it. Elasticsearch commonly uses request bodies for GET, treating it identically to POST. It's not always regarded as a good idea, but it does work.
  - paulddraper 3y ago
    That's why I said: > (Well, it's a syntactically valid HTTP message, but there's no semantic meaning to the body.) To quote RFC 9110: > Although request message framing is independent of the method used, content received in a GET request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT generate content in a GET 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. An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. For this reason, Elasticsearch also accepts queries as POST.

wqtz 3y ago

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 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?

shouldcode 3y ago
You might want to check out https://hypermedia.gallery https://hypermedia.gallery Disclosure: I built it (without HTMX).
mr90210 3y ago
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.
- jonathanberger 3y ago
  By “sit on” do you mean “keep using” or “avoid”?
  - mr90210 3y ago
    Keep using… Apologies for the lack of accuracy.
ysleepy 3y ago
The premise of migrating away from an SPA framework might make it seem weird, but I don't think that's the common adoption path. There are a lot of server side templated web facing applications out there, and htmx provides a simple and gradual UX improvement with very litte investment. It depends on what you deem "internal tooling" but a lot of b2b software isn't built to be flashy.

traceroute66 3y ago

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 gracefully. I am aware that you can kludge a hack in the form of a JS snippet to force htmx to render content on !=200, but it shouldn't be that way IMHO.

danielvaughn 3y ago
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.
- andrewstuart2 3y ago
  All response codes should really be able to contain content that doesn't look terrible. A 404 can be a nicely formatted "not found" page that's consistently styled and looks like the rest of the app, for example.
- traceroute66 3y ago
  > 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".
thom 3y ago
This is all handled in an extension: https://htmx.org/extensions/response-targets 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.
- traceroute66 3y ago
  > 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 <= 499 ) { evt.detail.shouldSwap = true; }

sibit 3y ago

I'm not someone who usually gets excited by new major releases of frameworks/libraries but this one feels different. I got my start with CRUD PHP websites with jQuery. I've been using HTMX for the last year and it fills me with nostalgia while also allowing me to move faster when building UIs.

PreInternet01 3y ago

So, I absolutely love htmx, and this new version offers some incremental improvements that make things even better (unless you were using WebSockets or server-sent events, I guess, but the plug-in model doesn't look too bad?). Unlike all-or-nothing approaches like React, htmx allows you to add just the right amount of partial updates to your web app, using just the technologies that were already there to begin with. I realize that this approach doesn't appeal to everyone, but being able to map simple requests to simple responses was an absolute life-saver for my projects many times over. Migrating to a truly-truly minimalist approach (see: https://www.stefanjudis.com/notes/htmz-a-176-bytes-htmx-alternative/ https://www.stefanjudis.com/notes/htmz-a-176-bytes-htmx-alte...) is still on my to-do list, but for now, I'm quite happy with the htmx status quo.

j3s 3y ago

sick! i’ve been using htmx for a few personal projects & i have to say, it feels like exactly what i was looking for. light, well documented, snappy, easy to work with - i love the idea of endpoints returning pure html instead of json - it feels obvious.

deleted 3y ago

[deleted]

pyrossh 3y ago

Newretrowave fan here. Who would have thought that the creator of htmx listens to synthwave.

minimaxir 3y ago

How much of a performance gain does htmx grant compared to other front-end frameworks? A talk from 2022 implies a significant benefit relative to React but in front-end development years that's an era ago: https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywjNXch-RPQJuAkTiLpleYFQjI/edit#slide=id.g156942fc762_0_105 https://docs.google.com/presentation/d/1jW7vTiHFzA71m2EoCywj...

infogulch 3y ago

I'm just glad I was able to submit my patch before 2.0 released: "Add config option to ignore nested oob-swaps instead of processing them (#1235)" Setting this config makes it easier to use 'template fragments' with oob-swaps, since you can set the hx-swap-oob=true attribute on the element and reuse it to render a whole page or just a fragment of the template. Very nice to use with Go template blocks for example. https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/