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.
Not only do browser manufacturers disregard that request, I observe that IETF has gone back on their idea of prefixing application protocols with 'X-`. See RFC 6648: "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols"
If the HTML standard changes so much as to collide with 'hx-` then application developers using HTMX will likely have bigger compatibility problems to deal with. Besides, regex replacement on your HTML templates isn't hard.
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-?
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!
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.
Those five letters are the difference between safe code and unsafe code. If you've used data-* you can rest assured your attributes will always be author-defined and not interfere with any future real attributes defined by HTML, whatever those may be.
But if you invent and use invalid attributes, any browser could do something with that, any day, for any reason, and it wouldn't be a bug - you're the one that would have chosen to build on top of undocumented and non-standard behaviour. Does that sound like a reasonable approach to you when the safe and future-proof approach is so clearly marked and cheap and easy to do?
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.
How does writing invalid HTML help toward the goal of correct parsing exactly? To me it would seem to open up an infinite variety of edge cases that simply don't need to exist if you're working with 100% standard code.
That assumes that HTMX wants to be fully compliant HTML code, which, by the author's optionality on data- vs non data- attributes, does not seem to be the case. This then is basically like JSX, it looks like HTML but isn't really, just syntactic sugar over structure, presentation, and logic operations.
Custom attributes (without data-*) are invalid HTML unless you're using them on a custom HTML element. If you're defining a custom element, you're responsible for defining what its attributes mean - outside of that, no they aren't allowed and yes they are unsafe to use, and restrict the standards bodies from being able to move forward freely without risking breaking the web because of invalid code in the wild.
JavaScript libraries may use the custom data attributes, as they are considered to be part of the page on which they are used. Authors of libraries that are reused by many authors are encouraged to include their name in the attribute names, to reduce the risk of clashes. Where it makes sense, library authors are also encouraged to make the exact name used in the attribute names customizable, so that libraries whose authors unknowingly picked the same name can be used on the same page, and so that multiple versions of a particular library can be used on the same page even when those versions are not mutually compatible.
This is saying that if you have `data-thing`, then putting your own name in there is better, like `data-mylib-thing` to tell it apart from `data-yourlib-thing`, but the ultimate in flexibility and compatibility is if the end-user of your library can configure this part so they can safely tell `data-yourlib-v3-thing` apart from `data-yourlib-v4-thing` etc.
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 :)
I'm also grateful for HTMX and the excellent development community that the project owner has grown. Like the parent, I'm also using HTMX + tailwindcss; rather than Rust, I'm using Julia.
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.
It definitely helps improve your security complexity over things like, say, GraphQL, where row-level security is necessary to prevent people from firing off random queries from the browser console.
There are a couple of places in the code where eval()/Function code are fire off which require some security-thinking:
hx-vars evaluate expressions to include in the request. This is a bit more dangerous, because you might try to pass values through with this mechanism. If this includes user input then you should use hx-vals instead:
I know htmx is a good idea, still waiting to see if hyperscript pans out. :)
It still needs some pretty basic stuff like for loops and so forth. The goal is for it to be a embeddable, DOM-friendly & transparently asynchronous scripting language so you don't need to deal w/ callbacks:
on click
add .throb to me
wait 3s
remove .throb from me
end
I'd like to make ajax and web workers trivial to use from it. I hope to have a lot more time for it in the next year, now that htmx is stable. We'll see. Suggestions welcome!
edit: one thing I'm pretty sure about is that I'm going to go back to an interpreted runtime over the transpilation I'm doing now
What are the advantages of switching to an interpreted runtime?
Btw I used htmx for a small project a few months ago and it was super easy to get working. Definitely recommend it, and looking forward to trying out 1.0 as soon as I have a chance!
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 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.
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?
In our agency augmented HTML (Htmx/Intercooler, AlpineJS, etc.) is very useful for web designers, they can go further with interactions and behaviors while staying in a HTML/CSS environment. Also it helps a lot in the communication between the design and developer teams, because there is a lot more understanding of what's going on.
That's great to hear and one of the big benefits to an HTML-first architecture: it's much easier to understand the entire stack, for feature development as well as optimization.
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.
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.