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.
HTMX has to be my favourite thing web related. I never really got React and always found it a bear to setup and use, but HTMX and server ride rendering? Easy and extremely productive for a non-frontend guy like me.
I really hope it or something like it becomes popular long term.
I just started using htmx in a new personal project. I’m pretty excited to see how it goes. I’m doing a sort of back to basics stack with PHP, simple classless css lib and htmx. So far it’s been a refreshing experience
Not op but classless CSS frameworks are awesome. The idea is to keep it simple and use the appropriate HTML tags where there were generally meant to go, and the framework will theme the page to improve usability and add flair. I've developed some great little sites with no classes at all!
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.
It's a CSS stylesheet you include in every page/view. You don't add any classes to your HTML and rely on the defaults of that stylesheet to style the semantic markup. If those defaults are good for your project, and you have some command of HTML elements beyond using divs and spans for everything, it saves a lot of time.
Yes indeed! The core aspect, however, is that your server is returning fragments of html that htmx places in the DOM extremely quickly. They have pretty good examples on their site illustrating some "modern" UI patterns.
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.
It’s much faster than that in practice, but of course it comes down to how well your backend is written. I’ve been using HTMX lately and I can blink and miss the UI updates.
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.
You for sure wouldn't want to build a spreadsheet type app with htmx because of that aspect. Many other types of web apps can benefit from the simplification of the architecture, however. And like my paging example, many times you need to go to the server anyway. But sure, like anything, I wouldn't use htmx for every situation.
True BizarreByte. I love how htmx let's you easily add animation indicators on actions, because many times it's too fast due to the small chunks coming back and getting placed so quickly in the DOM
What sort of slow backends do you work with? My PHP htmx application responds in ~30ms including network transmit. Even if you’re across an ocean it’s maybe 300ms.
How well does their example work over satellite internet with 1.2sec latency? How about my cell connection when T-mobile throttles me to 64Kbps for going over my data allowance? How about my sister's cell connection, as she is on an MVNO and deprioritized sometimes to 128Kbps, sometimes to 6Mbps, and sometimes it varies within a minute between those two?
FFS, people, learn to write proper software that does everything locally!
All of the environments you describe there sound to me like they would benefit from web apps that become responsive after an initial page load of less than 100KB, followed by ~10KB round trips to the server to fetch additional data.
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.
Any app with dynamic data would still need to make some sort of HTTP request before rendering some view with that new data. I don’t really get your point.
My mentor always taught "Program as if it has to run on the far side of Mars."
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).
And what kind of apps are you using? You think Amazon and whatever else doesn’t also start a rest call on basically every action, many of which are “blocking” the UX?
Versus the overwhelmingly common SPA counterexample where any change in the UI means sending a request to the server, waiting for it return your json response, parsing that json response, building html out of that json response, and updating the dom.
Personally I would use htmx and roundtrips for all sorts of modification including data (such as reorganizing two rows in a table). But you'd also do that in an SPA, right? How do you prevent desyncs there? Also for e.g. sorting you'd need a server roundtrip anyway in the (likely) case where you use something like pagination or lazy loading.
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.
htmx glosses over the difficult part, which would be keeping track of the relationship between all these hx-post and hx-target attributes, when they're all just strings in markup. That glossing over is why you don't see any well-established backend libraries on the server integrations page. (https://htmx.org/server-examples/)
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)
It’s not a difficult part if you already have a powerful web framework. We’re using Htmx with Servant which has type-safe URLs built in. For the targets, automatic name generation is fine.
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.
I built a tiny deno+htmx experiment, you can check it out at https://ssr-playground.deno.dev, it's all server-side rendered html with htmx attributes sprinkled around.
I love the concept, but for my case, I'd need more granular filters. In particular, I only buy TVs that have analog audio outputs so I can hook them up to any speakers. That's a minority of TVs these days, but there are still a few around. Finding the good ones would be useful to me.
Thanks. Speed and quality content is what I've been focused on. I was tired of Google search spam and Amazon review rot so built this to try expose good/trusted/authentic content.
Can the same server side code render that fragment, regardless of whether it's part of the initial page load or a subsequent update? You need an additional route for the Ajax call, right? Just curious how this gets structured.
I haven’t used it recently but I believe it sets a header on the request when it comes from HTMX so you can change whether you send the whole page or just the fragment back.
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).
I really hope it or something like it becomes popular long term.