Please Just Try HTMX

I use the two together regularly, and I like it, but there are some sharp edges. Specifically when the element triggering the request is in a table, or when the response that comes back has alpine attributes on it. They haven’t been awful to work around, but I’m thinking about using alpine-ajax next time I expect that I’ll need to interact heavily with alpine in fragments returned from the server. It seems like the sugar that makes alpine feel like htmx when a round-trip is needed, with less fiddling around client state.

<div x-data="{content: ''}">
    <button 
      @click="content = await fetch('/some/html').then(res => res.text())">
        Push the button, Frank.
    </button>
    <div x-html="content"></div>
</div>

For more advanced cases you can use morph.

And with the upcoming htmx 4 you won't even need that, you'll be able to just hook in your own fetch() function and tell htmx to use that. The fetch() function can become effectively a router that can return content from the page itself or even fetch it from remote sources.

It‘s basically the same as any other webapp, just that you render partial HTML documents instead of JSON.

If you use „real“ CSS instead of Tailwind, you can get by with very universal templates consisting of bare-bones HTML.

Besides, you can organize your SSR-code in components, too. It‘s different, but not templating hell by any means.

It's not strictly about HTMX, but in a Rust codebase I use maud for templating and have as many functions building html things as needed. I have functions returning buttons, forms, etc. with the same classes, etc. . And I have functions making whole pages with elements of pages being arguments to it. So I reuse html just like a I reuse code. I'll have render_page, or I'll render_navbar. For more complex things, I'll add a a builder pattern with bon.rs to make things customizable, etc. Everything is typed, and I can tell that to render a navbar, I need to pass a user session, no room for typing mistakes, mismatched tags, etc.

The requests handler just returns a whole page or just a given element, or even one or the other based on htmx header. It's quite easy and natural actually - reusing code and passing values is ... the most basic there is in programming. Not sure why web devs keep inventing so many layers of abstractions there. Especially trying to maintain a separate template in a separate file, using separate templating syntax, etc. seems completely counterproductive. Use the code, Luke. You already have a programming language, why invent another one just to look at something so ugly as raw html.

You don't need separate templates for every button, you can define them at whatever granularity makes sense.

Look at how it does swapping. The algorithm is pluggable and you can make sure it preserves element state for everything you need, so you can swap a full "article" or "card" or whatever without the user noticing.

I think it's nice how the paradigm encourages creating a nice set of independently renderable components.

Two ways to remedy that:

• use template fragments so you can render a whole page or just a part of it
• use hx-select to pick just part of the response to swap instead of its whole body

Oh no a template for each different kind of page we render. How will we survive this glory

You can use JSX or similar technologies on the server so that template partials are as easy as defining a function. See eg https://github.com/yawaramin/dream-html/tree/todoapp/app

What rich interactivity do you have, for example?