Hmm. Well, so much for that theory 🙂

There is a way

I think boosted links have a marker on them. Will check at home

Ok, awesome. Thanks! The best solution is probably to make the preload extension smarter.

I will say I’ve had it in for hx-boost for a while 🙂 A more “violent” solution might be to change hx-boost so that it’s more easily recognizable.

Well, other than an attached htmx click event handler, I can't see any other markers on boosted links. Intercooler injects the same attributes onto the links, as what you normally would add manually (i.e.

ic-get-from

, which is the equivalent of

hx-get

), when you use

ic-enhance

(the equivalent of

hx-boost

).

But I'll leave it to you clever folks to figure out.. and then swoop in and pick the fruits of your labour afterwards 😁

Would it be possible for hx-boost to just add an

hx-get

attribute to the anchor?

HEy @mysterious-toddler-20573, could you elaborate? Is that a property we can (or will be able to) search for? Or is that a function that we might add? Is this something that is (or could be) exposed to extensions?

If you have an anchor DOM element, you can be a very bad person, and access the 'htmx-internal-data' property on it

If it exists, there may be a

boosted

property on it, indicating that it has, in fact, been boosted

this is very bad of you to do

but it will work

Gotcha. So I can quote you that this is an officially supported feature? 😉

I will not change this name for at least five

months? days?

but seriously, that seems like a good solution. I’m happy to make the change, or help with a PR from anyone else who can get to it before me 🙂

sometimes it takes a tough man to make a tender chicken

but it's nothing that a unit test couldn't guarantee

😉

The htmx way of doing

ic-on-beforeTrigger

, is to use trigger filters, correct? Some attribs like `ic-on-beforeTrigger`and

ic-on-complete

you can stick on a parent element, to handle common functionality for multiple child elements (e.g. custom validation on multiple submit buttons in a form). Is there a similar pattern available with htmx (or in combination with hyperscript)?

Or is it a case of specifying the trigger filter on each element individually?

hyperscript would be the answer for those, or using

htmx.on

on a parent element

I just realized that the way I explain my joy of using htmx to other developers is very different from the current htmx.org page. > htmx allows you to access AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext > I use these words "With htmx you can update snippets of a page. You can have three forms on a page and submit them individually. No serialization to/from JSON is needed. It is the well-known GET/POST interface which we used in the past. The server sends html snippets to the client". Is the term "**html snippet**" correct according to your point of view? I think this is the term which make the people (who are familiar with React/Vue) get it.

I think "HTML fragment" is more appropriate, snippet makes me think of something you'd copy-paste from a GitHub gist into your code

fwiw I agree with "html fragment" over "html snippet" 👆

The term "**fragment**" is not on this page yet: https://htmx.org/ Has anybody an idea where could be integrated? My intention: I think htmx is great. But I have a bit of fear that up to now the landing page (htmx.org) is not yet super easy to understand. I don't want to add abstract advertisement blabla, I want to opposite: it needs to be super easy, to understand the simple magic. I think there needs to be an introduction to "html over the wire" at the top of the page. Maybe this: {{{ # HTML over the wire Serializing data to json on the server and parsing the json on the client is the way many frameworks (Angular, React Vue) work. They realized that SSR (server side rendering) has benefits and frameworks like nextjs or nuxt where created. But why this complicated stack? Why not create HTML on the server without big frameworks? All we need is a way to transfer html fragments. The html and CGI specification only allows full page reloads. htmx extends html in a way to enable submiting and loading html fragments. }}}

That's quite well-explained, though I think "But why this complicated stack?" could be offputting to SPA devs exploring htmx (it doesn't feel complicated to them). Maybe "But is there a simpler way?" just an opinion