HN Reader

It is amazing how quickly a simple, traditional, "collection of pages" type website actually works if you don't do annoying things to slow it down. Most websites would be absolutely fine if a) HTTP was used reasonably well to set things like cache headers, and so (as mentioned in the article) and b) if a load of user-irrelevant stuff like tracking and advertising code wasn't thrown in as well. A simple page with standard HTML, passably optimised assets where needed, and only the JS needed for actual functionality, should be almost instant on most modern connections.

> Like any new tool, especially a tool that got popular as quickly as htmx, there are differing schools of thought on how best to use it. My approach—which I believe necessary to achieve the results described above—requires you to internalize something that htmx certainly hints at, but doesn’t enforce: use plain HTML wherever possible.

That’s the path for ultimate long term functional web pages!

Anyone replace some HTMX usage with the View Transition API that's now in Chrome and Safari? https://developer.chrome.com/docs/web-platform/view-transiti...

This looks appealing where it makes sense (page transitions, table sorting/pagination) and if Firefox gets around to adding it.

Does anyone have examples of non trivial websites or apps built with Htmx?

There are two sides to the argument which I think should be treated separately: a) Is it a good idea overall? and b) is htmx implementation good enough?

a) I think so, yes. I've seen much more spa that have a completely broken page navigation. This approach does not fit all use cases, but if you remember that the whole idea of htmx is that you rely on webserver giving you page updates as opposed to having a thick js app rendering it all the way it makes sense. And yes, js libraries should be wrapped to function properly in many cases, but you would do the same with no react-native components in any react app for example

b) I don't think so. htmx boost functionality is an afterthought and it will always be like this. Compare it with turbo [1] where this is a core feature and the approach is to use turbo together with stimulus.js which gives you automagical component life cycle management. Turbo still has it's pains (my favorite gh issue [2]), but otherwise it works fine

[1]: https://turbo.hotwired.dev/ [2]: https://github.com/hotwired/turbo/issues/37

>Triptych—the HTML proposals that Carson and I are working on—would render htmx obsolete for the type of website I describe here.

Which we discussed here [1], is still no where near getting even looked at. Browser maker are not interested in anything HTMX. Vast majority of browser developers still want JS driven web apps, served with AVIF image.

[1] https://news.ycombinator.com/item?id=42615646

Yea, in my opinion, hx-swap or turbolinks is a bit of an antipattern. Seems to me you get worst of both worlds:

- something that kinda looks like full reload

- but with all problems of client side routing

- and without preserving the DOM state like SPA would

- and you don't get the immediate response that is the main reason to build the SPA in the first place

In fact, it's often even slower than native navigation, because native navigation can start processing the stream during download and there's overhead with pre and post processing of the response in the boosted link version. Try to profile GitHub links to see what I'm talking about, opening a link in new tab can be 2x faster than clicking in the same tab.

I have used htmx just a little bit; but I have found htmx + solid.js for some small reactive components to be ... very, very pleasant and very much else of what this blog post says to be accurate.

I've written a lot more html than I have in the past and it just ... feels good? html has upgraded quite a bit in the last decades since I learned it.

> Updates that users would not expect to see on a refresh (or a new page load)

I always hated this idea. As a user, a refresh indicates that something is happening and it's abundantly clear when something is wrong. People don't always handle errors and in all fairness they shouldn't - a developer has no way of knowing what custom stuff I have on my browser, whether I'm using any blockers or pi-holes or whatever and they should not know. Simple navigation, refreshes and server side rendering is something which worked great, the web was fast and could run on anything with a graphical output. These days a single page eats up 150+ mb while it loads. All that so the page doesn't "refresh".

> “You didn’t solve anything! Doing validation is complex and you just magic wanded it away by designing a perfect interface for it.” Yes. Exactly. That is what interfaces are supposed to do. Better semantics make it possible for the programmer to describe what the element does, and for someone else to take care of the details for them.

Gosh I couldn't agree more, what a wonderfully succinct way to communicate what I spend a ridiculous amount of time trying to explain to my colleagues when designing programs!

[EDIT]: I just realized I had read this on one of the linked articles https://unplannedobsolescence.com/blog/behavior-belongs-in-h...

While I agree that full page refreshes probably shouldn't use HTMX, I'll also claim that it's pretty rare that you would do a full page refresh. Almost every website I create has context that is present on every single page. Typically the branding at the top and the site map at the bottom does not change and hence there are no full refreshes.

How do you get flicker free navigation using htmx without using hx-swap or boost? I see that this article refers to https://unplannedobsolescence.com which has a header that remains the same, but it also doesn't change. Normally a header will do some type of change, e.g. showing which menu item is currently selected. That's when the flickering starts, in my experience.

I like Hotwire/Turbo more than HTMX because of its core philosophy: start by building a fully functional page without any JavaScript, and then layer in enhancements only as needed. That approach has stayed consistent for years and feels really straightforward to work with.

(2024)

> In practice, this is virtually impossible to get right

Somehow every other JS frontend framework manages to hook into the History API just fine?

> The idea here is that the website still has a sound URL structure, which is managed by the core browser functionality, while interactivity is carefully layered on top, with targeted updates.

It’s a long time since I have to work with websites. JQuery was the hot stuff back then. But we didn’t used it. It was all HTML and a Java backend. This sentence implies that right now basic stuff isn’t managed by the browser (but by React, Vue and so on?) which seems to be simply wrong.

I thought HTMX is useful mostly for SPA style apps. If you want a website with individual pages you can mostly use HTML and a bit of vanilla JS for the stuff that needs to be dynamically updated.

Yes if you click a regular link in a modern browser on a noJS or lowJS reasonable size page it is darn fast.

And the predictability is a boon. Open in new tab, back button etc.

> In my opinion, most websites should be using htmx

In my opinion, in five years no one uses htmx, but another shiny toy. Hence, how about not starting to use it at all?

While I get the emotional appeal, I still don't understand the use-case for htmx. If you're making a completely static page, you just use HTML. If you're making a dynamic page, then you want to push as much logic to the client as possible because far more users are latency-limited than compute-limited (compare [1] vs [2]), so you use normal frontend technologies. Mixing htmx and traditional frontend tech seems like it'd result in extra unnecessary complexity. What's the target audience?

Edit: "Normal/traditional frontend" here means both vanilla (HTML+JS+CSS) and the most popular frameworks (React, Angular, Vue, Next).

[1] https://danluu.com/slow-device/

[2] https://danluu.com/web-bloat/