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.
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...
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.
https://tools.ietf.org/html/rfc6648
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.
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 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?
I’m guessing people do this to make it less likely to have a name conflict with a custom attribute used by another library.
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.
Oh wow, it gets a lot worse...
Happy to answer questions.
to better simulate real network latency for things like progress indicators, etc.
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?
- you got deep into the custom headers
- you used ic-action heavily
- you used the path-dependency mechanism heavily
On a sibling comment I mentioned some new features in htmx:
- no jQuery dependency
- trigger filters: https://htmx.org/attributes/hx-trigger/
- HTML validation integration: https://htmx.org/docs/#validation
- Out of band swaps: https://htmx.org/docs/#oob_swaps
- htmx has a more advanced swapping mechanism (swap and settle, not documented well yet) that makes it easier to use CSS transitions
Happy to help out with the transition if you jump on the discord:
I'll move that into the /js directory instead, thanks for the heads up
By the way, thanks!
- no jQuery dependency
- trigger filters: https://htmx.org/attributes/hx-trigger/
- HTML validation integration: https://htmx.org/docs/#validation
- Out of band swaps: https://htmx.org/docs/#oob_swaps
- htmx has a more advanced swapping mechanism (swap and settle, not documented well yet) that makes it easier to use CSS transitions
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?
https://htmx.org/attributes/hx-target/
You can also use Out of Band swaps to replace arbitrary DOM content:
There are a couple of places in the code where eval()/Function code are fire off which require some security-thinking:
https://htmx.org/attributes/hx-trigger/
hx-trigger evaluate expressions for the event filter. This typically isn't an issue since you would be unlikely to use user input in this context.
https://htmx.org/attributes/hx-vars/
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:
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
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
Reference: https://stimulusjs.org/
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:
Perhaps i just need to learn more “htmx-like” code patterns, but they didn’t come that naturally to me.
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>
<div hx-get="/contact/42/summary" hx-swap="outerHTML" ...>
...
</div>
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.
Htmx might be the perfect tool to stay with classic server-side rendering and still have the "pop" of SPAs.
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.
All link clicks are ajax'd via the hx-boost attribute:
Unpoly just has bad marketing.
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.