I don't like the fact that the site is forcing light mode on me. For people like me, who suffer from retinal/macular issues, when visiting a website, there are several possible outcomes:
- some websites support both dark and light modes and they automatically switch depending on OS-level preference. These are the best.
- some websites support only the light mode, but my Chromium's flag "force dark mode" still manages to somehow display them in dark mode. These are the majority of websites today.
- some websites support only the light mode in such a way that they even defeat Chromium's force-dark-mode and still show up in light mode. These are the worst.
I agree with your analysis re: good/better/best approaches – or more like unacceptable/acceptable/good – and I shipped a website in the unacceptable state.
Let me see if I can fix that today.
I personally prefer the Safari browser, and I use an extension (Noir) for forcing dark mode. So where you rely Chromium's "force dark mode", Noir detects if a website has a built-in dark mode available and uses that, otherwise it just applies its own dark mode. This has been working well on hypertemplates.net, and that was acceptable during my documentation sprint over these past few weeks, but I'd rather not leave my visitors UX up individual browser configurations (via extensions or chrome flags).
I use about 10 different browsers on my desktop and about 5 different browsers on my mobile, and, on both platforms only one of those browsers is set with the force-dark-mode, and that one is set as the default browser. Like a decontamination chamber of sorts. All interesting and well behaved sites continue on to other browsers, some even find their permanent place. Sites that do not cooperate with force-dark-mode are extremely rare, and if they happen to be of utmost importance then I can enable a desktop utility which inverts the colors for the whole screen, but this happens maybe two or three times a year.
I'm more familiar with htmx than alpine (TIL!), although I've never used either one. I have read the excellent HyperMedia Systems book though, and I was nodding my head the entire time.
I think the main differences between these projects is in their goals and their opinions about JavaScript.
HyperTemplates is a templating system first, and static site generator second. I have built a templating system for building and composing HTML layouts [1] [2], and a tool that combines the templating system with a lightweight, file-based CMS [3] to construct entire websites. HyperTemplates doesn't have any opinions about how to incorporate JavaScript into a website other than it's hyper-focus (see what I did there?) on HTML, which makes it compatible with literally any Javascript tooling you might want to layer on top of it - including 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].
I don't like the fact that the site is forcing light mode on me. For people like me, who suffer from retinal/macular issues, when visiting a website, there are several possible outcomes:
- some websites support both dark and light modes and they automatically switch depending on OS-level preference. These are the best.
- some websites support only the light mode, but my Chromium's flag "force dark mode" still manages to somehow display them in dark mode. These are the majority of websites today.
- some websites support only the light mode in such a way that they even defeat Chromium's force-dark-mode and still show up in light mode. These are the worst.
Thanks for this feedback!
I agree with your analysis re: good/better/best approaches – or more like unacceptable/acceptable/good – and I shipped a website in the unacceptable state.
Let me see if I can fix that today.
I personally prefer the Safari browser, and I use an extension (Noir) for forcing dark mode. So where you rely Chromium's "force dark mode", Noir detects if a website has a built-in dark mode available and uses that, otherwise it just applies its own dark mode. This has been working well on hypertemplates.net, and that was acceptable during my documentation sprint over these past few weeks, but I'd rather not leave my visitors UX up individual browser configurations (via extensions or chrome flags).
Thank you for understanding.
I don't use extensions as I don't trust them.
I use about 10 different browsers on my desktop and about 5 different browsers on my mobile, and, on both platforms only one of those browsers is set with the force-dark-mode, and that one is set as the default browser. Like a decontamination chamber of sorts. All interesting and well behaved sites continue on to other browsers, some even find their permanent place. Sites that do not cooperate with force-dark-mode are extremely rare, and if they happen to be of utmost importance then I can enable a desktop utility which inverts the colors for the whole screen, but this happens maybe two or three times a year.
Thanks.
This is again a nice take on HTML templating.
Would also like to know how is this different from alpine, htmx and the likes?
Could I also see some examples if available on how to implement form submission or is it plain html form action?
Great question!
I'm more familiar with htmx than alpine (TIL!), although I've never used either one. I have read the excellent HyperMedia Systems book though, and I was nodding my head the entire time.
I think the main differences between these projects is in their goals and their opinions about JavaScript.
HyperTemplates is a templating system first, and static site generator second. I have built a templating system for building and composing HTML layouts [1] [2], and a tool that combines the templating system with a lightweight, file-based CMS [3] to construct entire websites. HyperTemplates doesn't have any opinions about how to incorporate JavaScript into a website other than it's hyper-focus (see what I did there?) on HTML, which makes it compatible with literally any Javascript tooling you might want to layer on top of it - including 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