htmx

g the excellent HTMX. I won't pretend to be an expert on HTMX just from reading their book (and watching a few videos), but I think their website does a good job of explaining that the goal is to extend the capabilities of HTML by exposing some commonly used Javascript functionality as HTML attributes (e.g. AJAX, CSS transitions, websockets, and server sent events). Where HyperTemplates and HTMX might appear the most similar is in that both are designed to work with HTML fragments (e.g. HTML files with a single layout component), but HyperTemplates "includes" those fragments during static site builds, and the default HTMX approach is to fetch them client-side (requiring the appropriate cautions about XSS [4]). I think the best evidence that HyperTemplates and HTMX are more complimentary than competitive is in the fact that the htmx.org website isn't built using only htmx, some static HTML files, and some markdown for content. It uses a static site generator called Zola [5], which uses a templating engine called Tera [6] that is itself not purely HTML. I haven't tried this myself since I have reached for HTML Web Components for my JS needs, but I would guess that using HyperTemplates for low level templating and static site generation with HTMX for further extending HTML functionality would be a fantastic authoring experience. I'm the least familiar with Alpine, but I like that the author is also named Caleb! Maybe the Calebs are meant to build things for the web? I digress... At first glance the alpine attributes appear very similarly "DOM scripting" oriented, like HyperTemplates, but it describes itself as "jQuery for the modern web" which is directionally a different goal than HyperTemplates. The Alpine Templating documentation [7] highlights that, like HTMX, Alpine's DOM manipulation happens client side as opposed to prerendering the HTML, so it has to warn about XSS vulns [8] as a result. From there Alpine looks like it would appeal to JavaScript junkies – and I'm not using that in the pejorative sense because I love JavaScript! But the Alpine templating examples look like most JS framework examples in that they are full of <div>s and mostly ignore the existence of built-in HTML elements and their implicit meaning; although I'm sure Alpine could be compatible with a more semantic approach. I'm also not understanding how the x-data attribute, Alpine.data() method, and Alpine.store() are meant to work. Is the actual content of a page meant to be embedded in the layout, as shown in most of the examples? I must be missing something obvious RE: the CMS workflow, as I would expect the ability to separate layouts and their contents (church and state). Ultimately I think the emphasis on reactivity (see: State [9], and Events [10]), and the focus of the "Start Here" guide [11] on components and not websites highlights that the goals of Alpine and HyperTemplates are very different. Between these three tools, Alpine feels the most opinionated about JavaScript since it encourages you to embed JSON in HTML attributes and inline some JavaScript in your components/layouts. This is obviously a biased analysis, but I hope it helps. I'm just about the furthest thing you can find from an expert on HTMX and Alpine, so take my comments with a few lumps of salt (and by consulting the linked docs). But I am grateful for your question since it forced me to write some words about this topic which has been floating around in the back of my mind. I suspect I'll need to turn these notes into a blog post at some point. Finally, with regards to your question about forms, HyperTemplates lets you create reusable form components (HTML fragments) that you can compose layouts from, and then hydrate form element attributes from template data [12] in Markdown, YAML, or JSON format. And HyperTemplates can template HTML element attributes [13], so it can be used to customize <form> element attributes [14] (including global attributes [15] and data attributes [16]). But HyperTemplates sole focus is on the HTML templating, so it doesn't assert any opinions beyond whats available via the HTML form attributes. This again highlights how HyperTemplates is more complementary to something like HTMX than competitive. Again, the answer is in the goals and the #1 motivation for HTMX is "Why should only <a> & <form> be able to make HTTP requests?", so it naturally has more opinions about forms [17]. [1]: https://hypertemplates.net/docs/#introduction-to-templating [2]: https://hypertemplates.net/docs/reference/core/layouts/ [3]: https://hypertemplates.net/docs/reference/cms/ [4]: https://htmx.org/essays/web-security-basics-with-htmx/ [5]: https://github.com/bigskysoftware/htmx/blob/master/www/READM... [6]: https://www.getzola.org/documentation/templates/overview/ [7]: https://alpinejs.dev/essentials/templating [8]: https://alpinejs.dev/directives/html [9]: https://alpinejs.dev/essentials/state [10]: https://alpinejs.dev/essentials/events [11]: https://alpinejs.dev/start-here#building-a-counter [12]: https://hypertemplates.net/docs/reference/core/data/ [13]: https://hypertemplates.net/docs/reference/core/attributes/ht... [14]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... [15]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... [16]: https://developer.mozilla.org/en-US/docs/Web/HTML/How_to/Use... [17]: https://htmx.org/docs/#synchronization

having 190 top-level functions, which, with all due respect, I think indicates a lack of architecture. Again, the issue is less about the specifics, and more about the fact that HTMX is not living up to its promise of simplicity because of how impenetrable the codebase is in this regard. As mentioned, so far I have found Stimulus and Turbo to be better implementations of what HTMX appears to promise to be. More activity in this space from anyone and everyone is great here though! [0]: https://github.com/bigskysoftware/htmx/issues/1476 [1]: https://github.com/bigskysoftware/htmx/issues/1736 [2]: https://github.com/bigskysoftware/htmx/pull/1960

hose regions. Then they are announced by the screen reader. This is nothing special to htmx of course; every app needs to work the same way.