Raku.org Chooses Htmx
The official https://raku.org programming language website has been rewritten using HTMX and Pico CSS. This reflects the power of HTMX to return languages other than JavaScript to the web backend.
The official https://raku.org programming language website has been rewritten using HTMX and Pico CSS. This reflects the power of HTMX to return languages other than JavaScript to the web backend.
The tabs on the page switch between different static content. Yet each time you click, it requires a new network call to load the content.
Why not have a little bit of vanilla JS or alpine JS? The alpine homepage has similar tabbed content, but it doesn't need new HTTP calls to load each one. https://alpinejs.dev/
I feel like the Raku site would be better in HTML + vanilla JS. There's almost no interactivity, and this HTMX interactivity is worse than vanilla JS.
fair point
https://harcstack.org was used to built the new site in the spirit of use your own dogfood (other raku web modules are available)
HARC stack is centred on HTMX (thus the 'H') and Pico CSS (other CSS libs coming)
This version of HARC Stack implements the HATEOS version of tabs https://htmx.org/examples/tabs-hateoas/ since that allows for dynamic content service (but admittedly that is overkill for the current site)
Wow! The Tabs example on the HTMX is faked! They serve the tabbed content using faked JS calls instead of network calls. It makes the idea of using HTTP for small amounts of content changes not seem crazy because it's instant on their site, but when you implement it on your site it will be slow because it's making actual HTTP calls!
HATEOS is okay for APIs. But doesn't seem useful for small static sites. Dogfooding is great! But so is using the right tool for the job. HTMX is not over-engineering things, it's made the Raku site worse than plain HTML and CSS (you can do tabbed content in pure CSS even!)
I respectfully disagree that HTMX (or AJAX) is a bad choice for tabs in general. The classic idea of getting incremental content from the server is important. These HARC stack tabs will work fine if you have eg a set of editable boxes or live timers to present. Following your logic no one would ever reach for React.
https://x.com/htmx_org/status/1964783993129517320 - good to make head grug happy
Any reason to use Pico CSS over Tailwind?
Two reasons - (i) tailwind is not really a good start if you want a nice set of design patterns already built for you (sure there are good tailwind component libraries, but HARC is an antidote to JavaScript I hope) and (ii) HARC leans into FP (Air::Functional) for HTML code and a semantic HTML library such as Pico helps to avoid clutter in the source code and imo improves maintainability. But, unlike TW you need to submit to some kind of structure for your style … but HARC components help to maintain a good locality of behaviour (LOB).
Nevertheless HARC will add some TW themes soon - next on the list after Bulma.
I just tried out Pico in a small site. The resultant HTML looks more semantic and readable compared to that of Tailwind.
Though, Claude Code ended up injecting a bunch of CSS definitions, which you can't avoid I suppose.
https://github.com/srid/Naivete-CoM/pull/1/files