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.
> 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-`.
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.
There seems to be a bit of irony citing whatwg in your attempt at shaming here —- the standard that was created to be a living document tracking what web developers and browser creators were implementing in the real world.
I’m not sure there is a good reason to require web authors to type an extra 5 character prefix every time they want to attach data to an element. This is supported by the fact that browsers can figure this out.
But prepending with data can be annoying both from a "quickly reading" perspective, and an aesthetic one. The goal isn't to provide valid HTML necessarily but just allow the library to parse it correctly.
I only wanna to say thanks for this project. I make a ecommerce platform on Rust (not yet public) and it become one of the main reason I could do this as fast as it have. Combining with tailwindcss I think is near the holy grail for backend-first web apps :)
Congratulations! I've been using Intercooler for a while now and haven't tried htmx yet, but am looking forward to switching over. I really appreciate that you're continuing to work on tools that make this approach to webdev easier.
I know the post says not to do it, but I'm planning to convert an existing project from Intercooler. Anything specific that I should watch out for while doing it, or recommendations for new capabilities that I could take advantage of as part of the switch?
I really, really, really enjoyed working with intercooler.js on a previous project... I understand there’s no immediate need to upgrade, but what new features does this provide for new projects?
htmx sounds great! I am interested in this from the security angle. If browsers were to natively support htmx (or something similarly declarative), it might reduce the need for Javascript and hence improve security.
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.
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.
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.
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.
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.
[+] [-] tmpfs|5 years ago|reply
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|5 years ago|reply
https://htmx.org/attributes/hx-boost/
[+] [-] err4nt|5 years ago|reply
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-cu...
[+] [-] recursivedoubts|5 years ago|reply
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.
[+] [-] tmpfs|5 years ago|reply
[+] [-] oconnore|5 years ago|reply
I’m not sure there is a good reason to require web authors to type an extra 5 character prefix every time they want to attach data to an element. This is supported by the fact that browsers can figure this out.
[+] [-] satvikpendem|5 years ago|reply
[+] [-] tarsinge|5 years ago|reply
[+] [-] ezequiel-garzon|5 years ago|reply
I’m guessing people do this to make it less likely to have a name conflict with a custom attribute used by another library.
[+] [-] aecay|5 years ago|reply
Oh wow, it gets a lot worse...
[+] [-] recursivedoubts|5 years ago|reply
Happy to answer questions.
[+] [-] mamcx|5 years ago|reply
[+] [-] Scarbutt|5 years ago|reply
[+] [-] Deimorz|5 years ago|reply
I know the post says not to do it, but I'm planning to convert an existing project from Intercooler. Anything specific that I should watch out for while doing it, or recommendations for new capabilities that I could take advantage of as part of the switch?
[+] [-] heavyset_go|5 years ago|reply
[1] https://i.imgur.com/lIiQuE6.png
[+] [-] cmclaughlin|5 years ago|reply
By the way, thanks!
[+] [-] machinelabo|5 years ago|reply
The way I understand htmx, it will replace the tag itself with an ajax response from the server. This is great for submit feedback and flash messages.
What if you want to click a htmx-button and replace something else outside of the tag with htmx?
[+] [-] hrjet|5 years ago|reply
[+] [-] oconnore|5 years ago|reply
[+] [-] no_wizard|5 years ago|reply
Reference: https://stimulusjs.org/
[+] [-] Epskampie|5 years ago|reply
Perhaps i just need to learn more “htmx-like” code patterns, but they didn’t come that naturally to me.
[+] [-] recursivedoubts|5 years ago|reply
The summary rows would handle a click to load the detail HTML for the contact, and replace the entire row
The detail rows would handle a click to load the summary HTML for the contact, and replace the entire row 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.
[+] [-] rasso|5 years ago|reply
Htmx might be the perfect tool to stay with classic server-side rendering and still have the "pop" of SPAs.
[+] [-] bobthebuilders|5 years ago|reply
[+] [-] recursivedoubts|5 years ago|reply
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.
[+] [-] ezequiel-garzon|5 years ago|reply
[+] [-] recursivedoubts|5 years ago|reply
https://htmx.org
All link clicks are ajax'd via the hx-boost attribute:
https://htmx.org/attributes/hx-boost/
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] midrus|5 years ago|reply
Unpoly just has bad marketing.
[+] [-] recursivedoubts|5 years ago|reply
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.
[+] [-] unknown|5 years ago|reply
[deleted]