Htmx in a Nutshell

Do you have any specific suggestions for resources for exercising grid & shadow dom knowledge/chops?

I'm updating my CSS understanding after having left the front end for ~6 years (but having done a lot of front-end work for the previous 10), loving custom properties and am intrigued with some of the systems built around them (e.g. Pollen), trying to figure out where else I should be directing attention.

I bought Tailwind UI and am using all their components (or as much as I can). I don't disagree with anything you said but I do like the tailwind features and design philosophy.

I have completely ignored web components and need to learn all about them.

Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend.

I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced" in the positive sense. It keeps you honest.)

https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV.

https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx.

If you hate SPAs and are chafing against Vue for building your app, it's probably worth considering if your app absolutely needs to be a JS/frontend-heavy product, or if it would be viable using a more traditional HTML+AJAX design.

I default to using Vue.js imported via a script tag inside static html pages styled on bootstrap. It’s perfect for basic apps and you don’t really lose a lot on interactivity. Backend, current fav is FastAPI.

Quasar framework seems to fit UI heavy and supported wide range of UI components. I have manage to integrate Tailwind.

I still have some API things and I like the router and serializers.

Web isn’t the only interface. DRF might also serve REST API to mobile or webhooks etc.

HTMX can be used with templates and JSON with extensions.

Not sure I agree. Yes, it requires more work on the back end: rendering templates for whole pages and parts of pages, then integrating them. I've done it with Python (FastAPI/Jinja2 & htmx). My only SPA experience is with dotnet on the back end and Angular on the front. Based on that experience:

1. Python with htmx has less accidental complexity. It doesn't get rid of intrinsic complexity of the domain, but it does reduce technology-induced overhead.

2. Dotnet/Angular tech split has organisational implications, tending to encourage a division between front end and back end developers. Communication and coordination overhad goes up correspondingly (Conway's law).

3. htmx is stable. There's a lot less churn than with Angular. I haven't measured this, but subjectively, there's less time spent updating packages and re-testing. Keeping FastAPI/Django/Python update is approximately equivalent keeping the dotnet back end up to date.

4. State management is simpler. There's no front end caching to deal with, and so no corresponding cache invalidation questions.

I'm not building tech unicorn sites, so can't comment on whether the technical overhead is justified at that scale. I _have_ been pleasantly surprised at the level of UI sophistication that can be achieved with server side rendering and htmx.

I'm not a big javascript fan generally, so definitely have bias. I also have an increasingly allergic reaction to accidental complexity, so am constantly looking for ways to minimise it.

Based on those biases and experiences, my default starting point is SSR+htmx. In my experience the accidental complexity is lower, productivity higher, and intra-team communication better. YMMV obviously.

I imagine that by moving this to the backend you could guarantee (at compile time) that all Ajax calls on the client have an associated backend endpoint. This eliminates dead urls, and gives you more opportunities for code generation or IDE-style autocomplete when creating Htmx views.

Do this in a static functional language and your whole app will more “deterministically pure”.

So yes, it causes more work on backend but, given more tooling, it can provide more opportunities for less code written overall via code-generation (like how creating a model in Rails generates lots of helpers).

In a lot of cases you can go a long way without having to adapt the backend at all - just request the full page at the existing url and pick which part you want to replace. Works well enough with a page that presents paginated items for example.

I second Tailwind as I can't stand complexity, so I'm trying to simplify the entire stack down for _just_ my needs. Tailwind is a big part of simplifying my life.

The other part is that I'm trying to simply "fix HTML", and I believe HTMX is pretty great. I'm taking a different approach as I have a reactive backend, and I can make the HTML simply be a template of a streaming JSON object. It's like mustache with reactive data binding.

I'm enjoying, but I'm not a consultancy so I don't need to push the framework for every usecase.

I've tried Tailwind, and as a back end dev who only really understands the basics of CSS I find it a bit overwhelming and open ended. Seems it's designed for people with already a really deep knowledge of CSS who can could create beautiful components with it if they wanted but for whom hooking up the CSS to the components is painful. If you aren't good enough to create components with CSS in the first place, seems better to stick with things like bootstrap/bulma no?

Agree. The idea of Tailwind just feels wrong because it goes at the opposite of everything we can believe regarding content/style separation. But the fact is, it's amazing to use.

Maybe it's not for everyone, but it really is worth a try, with an open mind.

For me, it clicked immediately. It is a simple way to partial updates of the UI, without having to worry about a ton of tooling. It also pushes most of the logic to the backend, which is nice. It also constrains some of the UX decisions, leaving less room for useless craziness.

IME, HTML-driven web applications (to say nothing of simple pages) in the field are generally more screen reader friendly than SPAs, though you can certainly achieve good accessibility with the right team and resources.

Agreed that it is a breath of fresh air. It totally eliminates heavy complexity in the development environment and networking protocol layers. What makes me happy is that it completely reinvigorates the server side language you prefer to use.

Same here, also using Janet + htmx!

The JavaScript we use is now much, much less. Actually, most times we just sprinkle in a bit of hyperscript for the times we need something a bit more dynamic than plain htmx. _hyperscript is a separate library by the same author that provides an HTML type of scripting in the attribute tags.

Still, in general, because we are generating fragments of hypermedia (HTML) on the server and returning that to target elements in the browser directly, the need for JavaScript directly in our code lessens dramatically. As you mentioned, though, you do need to include the hmtx JavaScript libary with a script tag. That library is very small though when min - something like 12k.

Amazingly, you can build some pretty dynamic web apps using htmx and sprinkling in a little vanilla JavaScript or _hyperscript if you are daring! The main key for us though is thinking from a hypermedia point of view with SSR; that coupled with the elimination of the complicated development configurations, is a huge win in simplicity and productivity. No more versioning our endpoints too!

I will say, the :advanced flag for the closure compiler has caused us some real headaches in production, enough to where we needed to migrate to only the :simple flag.

The reason being, is we needed to do some code gen of Svg components in React Native, and in the build process (via shadow-cljs), the closure compiler was munging the definitions in the.

Off the top of my head an svgr component which looked like: // generated component import React from 'react'

function SomeSvg(props) { return React.createElement(..., ...merged props..., ...children...) }

was getting "optimized" to be used as: function $SomeSvg(props) { return $R.$c($$..., $$...merged props..., $$...children...) }

The above is psuedo-ish code, but I think covers the point. There were also some edge cases where not includeing a ^js reader macro before using js values caused crashes, due to the symbol being munged in the background. As a result, whenever we used any sort of js, we needed to mark it w/ a ^js reader macro, which began to get really noisey and error prone if you forgot. :simple has made the code based more stable. Could be user error on our end, but the fact that we ran into so much with :advanced and our application stabilized significantly after that one configuration change, it makes me think using :advanced can be too involved.

In addition (to an already winded comment), cljs needs to include the cljs runtime. I haven't benched the size, but it is no negligible (think in the 100's of KB), on top of what react/reagent/re-frame may bring in, you can easily end up w/ a compiled cljs app of > 1MB.

I see bnert gave a very good answer to your question in a reply. So to echo what bnert said, as far as the java template frameworks like jsp and thymeleaf, htmx is complementary to them. Here is a good scenario in this blog post by someone. https://www.wimdeblauwe.com/blog/2021/10/04/todomvc-with-thy...

Also like bnert, when using Clojure we prefer to use a library on the server-side called hiccup to generate HTML from Clojure data structures instead of a template library. Either way, template engine or hiccup HTML generation, the principle is the same. You are coding everything on the server-side and rendering HTML back to the browser - something it is VERY good at rendering. :) As part of that HTML rendering, you are putting attributes on some HTML elements that htmx understands from the browser side.

ClojureScript is a totally different concept, as it basically allows a Clojure developer to write JavaScript in Clojure - it generates JS. With the server-side rendering model above, we still code 100% in Clojure, but we get to jettison a lot of the complexity of the ClojureScript model (Reagent etc), and development set-up. It is far simpler.

Other benefits of the hypermedia approach provided by htmx: 1. It is obviously true HATEAOS, so we don't worry about end-point versioning issues. 2. The barriers of the UI team and Server team negotiating and re-negotiating end-points is gone. We have all transitioned to "full stack developers" - sanely. 3. As mentioned above, it is language and server-side agnostic, so use what you prefer and have competitive advantage with using. 4. Simpler mental model. The team thinks in hypermedia terms from a server rendering perspective only. That lets you wrap your brain more easily around the business problems. 5. You have the full power and capability of your database at your disposal instead of going through and desigining the correct endpoints to get there first.

Hope that made sense

After a quick glance, it seems like htmx would complement thymeleaf, if the web page/app you're writing doesn't need any sort of eager client (eager as in, treat and interaction with a remote service as "successful" and resolve the error in the background somehow).

W/ htmx + clojure, you can define your ui like so:

  (def counter (atom 0))
  
  (defn partial-count-markup [c]
    [:span (str "Pressed: " c)])

  ; Handler for /partial/count
  (defn partial-count []
    (swap! counter inc)
    (partial-count-markup @counter))
  
  ; Handler for index.html
  (defn handler []
    [:button {:hx-put "/partial/count" :hx-swap "innerHtml"}
      (partial-count-markup @counter)])

Also if it isn't clear, you can also keep all your markup as Clojure data structures, which means you can write an `html` function which has the common styles/scripts/etc.. necessary so you get a ton of re-use with an already similar syntax vs needing to learn a new templating syntax w/ its own conventions.

W/ clojurescript, to get the same behavior you need:

  - clojurescript toolchain w/ some configuration of how you'll bundle/package it
  - an idea of how you'll distribute your application (serve spa from same API service? S3/Object store? another web service? How to reconcile state?)
  - an idea of how you'll reconcile state between local/server, if you want to go that route. If only local, nbd. If server, you add a handler and fetch data once SPA or cljs has loaded.
  - and idea of what format you want to consume (JSON, HTML, XML,text) and then write the translation between that format and your markup.

I hope the above answers your question, or at the very least offers another perspective.

As a quick postscript, I think it is underestimated how convoluted templates/templating engines are, given they have the tendency to implement their own language/semantics outside of the PL you're using. I have much respect for the authors of template engines/spec, the engineering that goes into them is impressive, however, most I have come across tend to be a leaky abstraction. Once I experienced writing markup as Clojure data structures, it ruined me for templates permanently. I don't want to go back to writing templates, and doing an assessment of "what language does this template engine implement, and is it simple/easy to learn?" is an exercise I do not miss.

Note: I've been Clojure/ClojureScript developing professionally for almost two years now and have debated most of the above internally during that time. Done some templating w/ JS, Go.

Sounds like you should be writing some blog posts about writing complex applications with this stuff

I recorded a short video about it here https://youtu.be/JE3zQpEAaxk

For something between static html pages (good for information websites no need for HTMX) and SPA (good for complex SaaS services outgrown HTMX).

Maybe, but probably not because it wouldn't help with paginated data sets displayed in tables. You don't want to sort only the items you currently see, but across the whole data set most of which is likely not loaded.

Absolutely! I will definitely do that when you can save and share playgrounds :)

It was just an example, replace SSN with password if you'd prefer.

I don't think UI is part of HTMX's concerns. It is a library for submitting data and loading HTML fragments. For general UI components, I like https://shoelace.style/.

But you can already do that. I was doing it in the 90s, Ruby on Rails supports it, etc. Just send the HTML if you want to and call `el.innerHTML = response.body`.

The false dichotomy here is that it's either htmx or React. Why not... neither?

Yeah, that I understand. I am not a huge fan of sending JSON that's not backwards compatible. Sending HTML is probably a good choice for some applications, but that was already well supported 20 years ago. Why is htmx better than one line of javascript saying `onload = function() { e.innerHTML = response.body` } ?

Hmm so like how Wicket Ajax works, but as something you can bolt on to any framework? That's cool, although I'm not sure how well it would work if the framework isn't component-oriented in the first place.

Yeah, but why? Why is it better to remember a bunch of attributes than to remember 3-4 javascript functions?

I've looked at a few of those and I still don't understand. Also, hilariously, several of them are already broken. (Like the table one that's not updating.)

EDIT: Sorry, nevermind. The Bulk Edit example does work, I think it either does not like Safari, or something failed to load before, but it works in Chrome.

You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.Then you can get rid of almost all your js code.

The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.

> Just write HTML5. It's fine. Add javascript for the 2-3 bits of interactivity you actually need.

Why write any JS at all if you don't have to? Htmx extends HTML to replace the need for a lot of the JS that's out there. It gives you client/server interaction and dynamic page behaviours without a single line of code.

Sure you can do without it. You could always do it all in vanilla JS or jQuery, at the cost of debugging it yourself.

> Also if you build stuff on top of hypermedia APIs then bye bye performance.

This is not obvious to me.

> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON

HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed over.

Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly. Whereas HTML produced by the backend (properly) contains all the information someone could need.

:) I didn't make alpine, that caleb porzio (a genius)

I did make https://hyperscript.org, which is kinda in the same space but very different than pretty much everything else

:) agree 100%, htmx shouldn't have to exist!

i agree

and here is a perfect place for you to contribute to the project! :)

heya, i don't know of any terminal-based hypermedia, but that's an interesting concept

maybe gopher as a prototype example?

adam stepinski (creator of hyperview) is one of the heroes of hypermedia in that he didn't just develop a hypermedia format but also developed a hypermedia client, and you need both for a proper hypermedia system

so, I would say... maybe you are lookin' at the person in the mirror who is going to make that terminal app hypermedia?

htmx doesn't do anything on an error by default, but you can override this behavior using the extensive event system it has:

https://htmx.org/events/#htmx:responseError

It’s pretty simple to use the htmx events on the Response to handle errors dialogs or other behavior

I use Unpoly and not HTMX but similar idea, what you do for components entirely is up to you.

My components look like this. The JS and CSS is included in the application's bundles. Ruby renders HTML on the server side.

  app/components/breadcrumbs
    - _breadcrumbs.scss
    - breadcrumbs_component.rb

  ...
  app/components/search_field
    - _search_field.scss
    - search_field_component.rb
    - search_field.js
    - selections.html.haml

I'm not sure if I've entirely grokked the idea of components, but can't you define them server-side? So write them as some template magic that creates the "inner HTML". Then you just need some HTMX to enable using the component in a richer way.

It's not really Web Components as specified, but iirc those are generally pretty much JS-dependent? But hypermedia's reliance on server side rendering means that you can just move this logic to the server.

Why wouldn't htmx work with web components? It just does asynchronous fetches and DOM swaps. Web components are just pieces of DOM. There should be absolutely no issue with them working together?

consulting as a side gig of my day job, which is a CS prof

unfortunately I don't know webpack really well, although I'd love docs contributions on it if the existing docs aren't good