Much more prefer the htmx way of SSR parts of the page dynamically. Also, totally server-side agnostic, so we can use what we prefer. Clojure in our case.
I really hope it or something like it becomes popular long term.
Obviously this approach has its limits, but it works well for proof-of-concept sites or sites that don't need to be very complex or dynamic. Just a sensible font size, nicer looking form elements, etc.
Here is a list of classless CSS frameworks: https://github.com/dbohdan/classless-css
As an example, you may have an HTML table on your page that you want to insert a new row for some reason on let's say a button click. You place some attributes that htmx understands on your button that will call for the TR HTML chunk from the server. You can imagine replacing all the rows for a paging click etc.
Again check out the example for cool stuff.
I wish I had numbers, but in my experience it’s far better than you’d expect. Basically take the length of a REST call you’d have to make anyway and add a few milliseconds for the rendering.
It won’t be the right choice in all cases, but it’s a great option in many.
How about you try it and see?
Both, I guess.
And I have written a library that does the full SSL handshake/upgrade cycle off of tcp sockets, and managed my own private CA, so I'm not a total idiot.
Also the latency of your connection matters.
HTMX is fine with showing loading icons are the like if needed, but yah, connection latency is going to have an effect.
FFS, people, learn to write proper software that does everything locally!
As opposed to the >2MB initial page loads that have become so common with heavy React SPAs in exchange for the theoretical benefits of avoiding more page loads for further interactions.
Software that doesn't need the internet for its function shouldn't connect to the internet. Software that does need the internet should be able to operate under adverse network conditions.
The Voyager probes are 160 AU away, far past Pluto, with a roundtrip latency of 37 hours. The radio transmitter onboard is only about 10x more powerful than a cell phone. The hardware has been in the cold vacuum and hard radiation of space for four and half decades. In spite of this, NASA maintains active two-way communication with it today, and continues to receive scientific telemety data of the outer solar system.
I don't expect web devs to design for deep space, but the core functionality of a website should still work for a rural user with a spotty satellite uplink. Don't do go loading JavaScript or other resource calls until the basics are received. I still remember the days of Facebook being fully functional on a 2G cellular connection, using little or nothing more than static HTML and CSS (and that was before the magic tricks HTML5 can do).
For sending data, you would just have a reply that instructs HTMX to display a success message. On an SPA you'd have the same. With both, you can interact with the page while the data is being sent.
Of course, sometimes you want purely 'cosmetic' actions, such as an "add row" button that pops open some data entry fields. For something like that you should not use htmx itself, but instead basic vanilla JS or a simple library such as https://alpinejs.dev/ which complements htmx nicely for client-side stuff.
What I typically do is render the first bit of data on the server and have the client JS use that as a <template> for changes or new records. That ensures that anything done on the client always matches without you needing to code cosmetics in multiple places but also means your pages load seconds faster than a SPA because the first view is ready to go. When the user saves the entry, you can swap what you generated with the server response a few milliseconds later.
It's not suitable to everything, but it works really well. I'm not advocating switching to it right now, but it's looking very promising.
Elixir solves this in a much smarter way, because the bindings to reactive values can be validated at compile time, inside the HEEx templates. It's all located together, but you still get the diff passing behavior. (https://hexdocs.pm/phoenix_live_view/assigns-eex.html)
I prefer the unopinionated, language agnostic simplicity of htmx, just like HTML, over more tightly bound language specific frameworks. It provides a vocabulary that will translate across backend languages and probably endure over competitor frameworks.
For me the biggest advantage is eliminating the need to learn, debug, and maintain components on an additional frontend framework (Angular/React/Vue).
I just built a rough toy project [0] that was my first time with FastAPI and HTMX and it was fun and fast.
[0] https://www.truebuy.com/ (like rotten tomatoes for product reviews but just for TVs right now)
But still, I'm pretty sure, one day I'm going to get one of these optical -> analog boxes.
You can also just send the whole page and use other features to select just the part that you want to update (obviously that has a cost of sending the whole page though).