7 ms·

Htmx 1.0.0 Release

107 points by skept 6y ago

ezequiel-garzon 6y ago
Has anybody built a site they’d like to share built with htmx? (If so, do share :)
- recursivedoubts 6y ago
  The htmx site uses htmx: https://htmx.org https://htmx.org All link clicks are ajax'd via the hx-boost attribute: https://htmx.org/attributes/hx-boost/ https://htmx.org/attributes/hx-boost/
  - SquareWheel 6y ago
    I like the site. I'm just curious, was it a conscious decision to not minify htmx.js? Seems you could save a fair few bytes that way.
    - recursivedoubts 6y ago
      Easier to debug
err4nt 6y ago
> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long as it begins with `data-`. https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes https://html.spec.whatwg.org/multipage/dom.html#embedding-cu...
- tmpfs 6y ago
  I agree, the `data-` variant should be enforced so that the markup is always valid.
- recursivedoubts 6y ago
  Practically, you are allowed to do so. I understand both sides of the argument, so I set it up so you could choose which one you preferred. I don't see a reason to force my preferences on anyone.
  - kzrdude 6y ago
    Using data- which is the niche made for this in the standard, seems to be the solution that's more likely to still work 15 years down the line.
    - recursivedoubts 6y ago
      fine by me
    - wongarsu 6y ago
      The only real practical concern is that if you don't use data- you might use an attribute that will become meaningful to future browsers. But what are the chances of html gaining an attribute that starts with hx-?
      - err4nt 6y ago
        When you camp on the platform namespace it ties the hands of standards bodies - we will not get <modal> in HTML for real because too many people already went ahead and did it. Same for <accordion>, etc. Look up 'Smooshgate' for a similar example in JavaScript. Our workflows should have us practice writing _valid_ code, which our tools can then take and transform into other _valid_ code. Any workflow where the humans practice doing the _invalid_ thing so the tool can magically fix it later is a bad idea IMO. Practice writing good code and use tools to make it even better!
  - 6y ago
tmpfs 6y ago
Congratulations on the release, i have been following htmx for a while and whilst have yet to use it, conceptually i think the ideas are solid. I think the trend towards SPAs and everything is Javascript/JSX has created a situation where people build SPAs then add SSR as an afterthought. This is anathema to the ideas of document driven web pages and i think htmx could be a good middle ground. Of course for some applications SPAs are the correct choice but I see many people reaching for them as the default rather than creating pages and enhancing when necessary. I am working on some tooling in this space and hope to see how htmx could fit into progressively enhanced websites.
- recursivedoubts 6y ago
  It isn't perfect yet, but hx-boost is supposed to be the progressive enhancement option in htmx: https://htmx.org/attributes/hx-boost/ https://htmx.org/attributes/hx-boost/
recursivedoubts 6y ago
I'm the creator of htmx, glad to see this make HN. Happy to answer questions.
- no_wizard 6y ago
  This is very similar to Stimulus which i don’t find much difference from. Who’s your target developer? Reference: https://stimulusjs.org/ https://stimulusjs.org/
  - recursivedoubts 6y ago
    :) It's very different than stimulus. htmx extends HTML as a hypertext, it isn't tied to any particular backend and doesn't have any binding concepts. It's really a complete different concept. I'd recommend reading the docs: https://htmx.org/docs/ https://htmx.org/docs/
    - no_wizard 6y ago
      Sure okay, the DSLs are different. So who’s the target audience? I’m curious to know the typical developer attracted to libraries like this. That is t saying it’s bad or anything. It’s different enough I have a genuine curiosity
      - recursivedoubts 6y ago
        The target audience is all of them. :) I think htmx scales up and down pretty well: web developer newbs who don't want to sink a ton of time into a JS framework, as well as veteran web developers who want to stick with hypertext for the majority of their web apps.
      - clarkevans 6y ago
        HTMX encodes server interaction in hypertext rather than in Javascript. For those with intensive back-end logic and only light interface needs, HTMX offers a incremental way to add front-end interactivity without having to take the deep dive into Javascript frameworks. Longer term, the concept of encoding server interaction in hypertext seems rather novel to me. Perhaps this approach may be one of many missing pieces towards an ecosystem of interoperable hypertext-based web components?
deleted 6y ago
[deleted]
bobthebuilders 6y ago
Apologies if I missed it, but how would authentication work? I'm trying to figure out where ok the scale from Spring Security to JWT and React it falls on.
- recursivedoubts 6y ago
  Authentication works the normal way: you login via a login screen and that typically would establish a session cookie. You can also use events to hook in CRSF tokens if you need to do so. But it tries to use the original security model of the web as much as possible.
Epskampie 6y ago
I recently tried to use htmx because i like the idea. I made a table where you could click lines to expand them. Now, clicking a line would request the subcontent and insert it, easy-peezy. But now i want you to be able to click the line again to close. Hmm, in htmx this means that i’ll have to return a new parent line from the server as well... guess ill make a special template for that. Repeat this a few times and my backend templates were getting so many special cases that i just switched back to jQuery. Perhaps i just need to learn more “htmx-like” code patterns, but they didn’t come that naturally to me.
- recursivedoubts 6y ago
  The htmx way to do this would be something like this (assuming a contact model per row): The summary rows would handle a click to load the detail HTML for the contact, and replace the entire row <div hx-get="/contact/42/details" hx-swap="outerHTML" ...> ... </div> The detail rows would handle a click to load the summary HTML for the contact, and replace the entire row <div hx-get="/contact/42/summary" hx-swap="outerHTML" ...> ... </div> So you would flip the row back and forth between summary and detail views. This would involve two templates server side, which seems about right, and would place the logic inside separate and fairly simple server side logic. Note that here the URLs are encoding the row state, so we are using Hypertext As The Engine of Application State (HATEOAS) without thinking too hard about it.
midrus 6y ago
I find unpoly so much better and complete than this. Unpoly just has bad marketing.
- deleted 6y ago
  [deleted]
- recursivedoubts 6y ago
  That's fine, unpoly is a reasonable approach to building front end code, but it's a very different model. htmx is focused on improving html qua html. It doesn't have any notion of the server side beyond that which html has: URLs. As such it is attempting to say within the original model of the web: a hypertext architecture with REST/HATEOAS as the bedrock. It isn't a complete framework in the flavor of unpoly, and so it won't have the expressive power of unpoly in many cases. That's an intentional tradeoff based on the core motivating concept of the library. Which is fine: different strokes for different folks.
rasso 6y ago
This looks amazing! I never adopted any of the frameworks (vue, react, angular, ...) because I think they should only be used for web apps, but not for classic websites. JS for everything frontend-related in my opinion just has too many downsides for an open web (possibly bad SEO for crawlers that don't support javascript, reliance on the users device for rendering) Htmx might be the perfect tool to stay with classic server-side rendering and still have the "pop" of SPAs.

Htmx 1.0.0 Release

107 points by skept 6y ago

ezequiel-garzon 6y ago

Has anybody built a site they’d like to share built with htmx? (If so, do share :)

recursivedoubts 6y ago
The htmx site uses htmx: https://htmx.org https://htmx.org All link clicks are ajax'd via the hx-boost attribute: https://htmx.org/attributes/hx-boost/ https://htmx.org/attributes/hx-boost/
- SquareWheel 6y ago
  I like the site. I'm just curious, was it a conscious decision to not minify htmx.js? Seems you could save a fair few bytes that way.
  - recursivedoubts 6y ago
    Easier to debug

err4nt 6y ago

> It's worth mentioning that, if you prefer, you can use the `data-` prefix when using htmx I don't know why people who make frameworks either prefer invalid HTML, or if they do allow people to write valid HTML they seem to show the invalid code in the docs You are not allowed to invent any old attributes you want and add them to any element and have it be valid HTML, but you can invent any attribute you want so long as it begins with `data-`. https://html.spec.whatwg.org/multipage/dom.html#embedding-custom-non-visible-data-with-the-data-*-attributes https://html.spec.whatwg.org/multipage/dom.html#embedding-cu...

tmpfs 6y ago
I agree, the `data-` variant should be enforced so that the markup is always valid.
recursivedoubts 6y ago
Practically, you are allowed to do so. I understand both sides of the argument, so I set it up so you could choose which one you preferred. I don't see a reason to force my preferences on anyone.
- kzrdude 6y ago
  Using data- which is the niche made for this in the standard, seems to be the solution that's more likely to still work 15 years down the line.
  - recursivedoubts 6y ago
    fine by me
  - wongarsu 6y ago
    The only real practical concern is that if you don't use data- you might use an attribute that will become meaningful to future browsers. But what are the chances of html gaining an attribute that starts with hx-?
    - err4nt 6y ago
      When you camp on the platform namespace it ties the hands of standards bodies - we will not get <modal> in HTML for real because too many people already went ahead and did it. Same for <accordion>, etc. Look up 'Smooshgate' for a similar example in JavaScript. Our workflows should have us practice writing _valid_ code, which our tools can then take and transform into other _valid_ code. Any workflow where the humans practice doing the _invalid_ thing so the tool can magically fix it later is a bad idea IMO. Practice writing good code and use tools to make it even better!
- 6y ago

tmpfs 6y ago

Congratulations on the release, i have been following htmx for a while and whilst have yet to use it, conceptually i think the ideas are solid. I think the trend towards SPAs and everything is Javascript/JSX has created a situation where people build SPAs then add SSR as an afterthought. This is anathema to the ideas of document driven web pages and i think htmx could be a good middle ground. Of course for some applications SPAs are the correct choice but I see many people reaching for them as the default rather than creating pages and enhancing when necessary. I am working on some tooling in this space and hope to see how htmx could fit into progressively enhanced websites.

recursivedoubts 6y ago
It isn't perfect yet, but hx-boost is supposed to be the progressive enhancement option in htmx: https://htmx.org/attributes/hx-boost/ https://htmx.org/attributes/hx-boost/

recursivedoubts 6y ago

I'm the creator of htmx, glad to see this make HN. Happy to answer questions.

no_wizard 6y ago
This is very similar to Stimulus which i don’t find much difference from. Who’s your target developer? Reference: https://stimulusjs.org/ https://stimulusjs.org/
- recursivedoubts 6y ago
  :) It's very different than stimulus. htmx extends HTML as a hypertext, it isn't tied to any particular backend and doesn't have any binding concepts. It's really a complete different concept. I'd recommend reading the docs: https://htmx.org/docs/ https://htmx.org/docs/
  - no_wizard 6y ago
    Sure okay, the DSLs are different. So who’s the target audience? I’m curious to know the typical developer attracted to libraries like this. That is t saying it’s bad or anything. It’s different enough I have a genuine curiosity
    - recursivedoubts 6y ago
      The target audience is all of them. :) I think htmx scales up and down pretty well: web developer newbs who don't want to sink a ton of time into a JS framework, as well as veteran web developers who want to stick with hypertext for the majority of their web apps.
    - clarkevans 6y ago
      HTMX encodes server interaction in hypertext rather than in Javascript. For those with intensive back-end logic and only light interface needs, HTMX offers a incremental way to add front-end interactivity without having to take the deep dive into Javascript frameworks. Longer term, the concept of encoding server interaction in hypertext seems rather novel to me. Perhaps this approach may be one of many missing pieces towards an ecosystem of interoperable hypertext-based web components?

deleted 6y ago

[deleted]

bobthebuilders 6y ago

Apologies if I missed it, but how would authentication work? I'm trying to figure out where ok the scale from Spring Security to JWT and React it falls on.

recursivedoubts 6y ago
Authentication works the normal way: you login via a login screen and that typically would establish a session cookie. You can also use events to hook in CRSF tokens if you need to do so. But it tries to use the original security model of the web as much as possible.

Epskampie 6y ago

I recently tried to use htmx because i like the idea. I made a table where you could click lines to expand them. Now, clicking a line would request the subcontent and insert it, easy-peezy. But now i want you to be able to click the line again to close. Hmm, in htmx this means that i’ll have to return a new parent line from the server as well... guess ill make a special template for that. Repeat this a few times and my backend templates were getting so many special cases that i just switched back to jQuery. Perhaps i just need to learn more “htmx-like” code patterns, but they didn’t come that naturally to me.

recursivedoubts 6y ago
The htmx way to do this would be something like this (assuming a contact model per row): The summary rows would handle a click to load the detail HTML for the contact, and replace the entire row <div hx-get="/contact/42/details" hx-swap="outerHTML" ...> ... </div> The detail rows would handle a click to load the summary HTML for the contact, and replace the entire row <div hx-get="/contact/42/summary" hx-swap="outerHTML" ...> ... </div> So you would flip the row back and forth between summary and detail views. This would involve two templates server side, which seems about right, and would place the logic inside separate and fairly simple server side logic. Note that here the URLs are encoding the row state, so we are using Hypertext As The Engine of Application State (HATEOAS) without thinking too hard about it.

midrus 6y ago

I find unpoly so much better and complete than this. Unpoly just has bad marketing.

deleted 6y ago
[deleted]
recursivedoubts 6y ago
That's fine, unpoly is a reasonable approach to building front end code, but it's a very different model. htmx is focused on improving html qua html. It doesn't have any notion of the server side beyond that which html has: URLs. As such it is attempting to say within the original model of the web: a hypertext architecture with REST/HATEOAS as the bedrock. It isn't a complete framework in the flavor of unpoly, and so it won't have the expressive power of unpoly in many cases. That's an intentional tradeoff based on the core motivating concept of the library. Which is fine: different strokes for different folks.

rasso 6y ago

This looks amazing! I never adopted any of the frameworks (vue, react, angular, ...) because I think they should only be used for web apps, but not for classic websites. JS for everything frontend-related in my opinion just has too many downsides for an open web (possibly bad SEO for crawlers that don't support javascript, reliance on the users device for rendering) Htmx might be the perfect tool to stay with classic server-side rendering and still have the "pop" of SPAs.