Could you explain your position on this? I'm far from front-end, but from the user experience, current stack seems excessive and bloated. A button/link which sends a request and gets a chunk of HTML back to replace without reloading the whole page seems like a logical workflow covering the needs of 90% pages. Looks like HTMX simulates this and thus looks attractive to me.
> A button/link which sends a request and gets a chunk of HTML back to replace without reloading the whole page
1. My whole app is distributed now. To determine what will render after any given action, I need to go find my backend renderer for this specific endpoint, which itself seems likely to reference another piece of code that it uses as an endpoint, adding a fresh layer of indirection on every single UI interaction.
Also, this HTML renderer logic needs to be aware of the rest of my app, so the reverse is true; when I'm going to write some new UI, I have to go put it somewhere random, associate it with a frontend route and backend endpoint it loads from, and then attach all the possible nested user-actions from this HTML.
Have you heard of separation of concerns? This does the opposite: it joins my rendering concern with my loading concern, and distributes my User-facing concern.
2. Everything is async
You know what I love as a user? When I have to wait for a network trip before the Button I clicked on does anything.
How do you show a loader in HTMX?
3. Graceful async handling
So, you read my complaint #2, and said to yourself: well, I'll simply make a custom Button which upon being clicked can disable further clicks until it is updated about the status of the action it just distributed!
So, real quick: where are you going to put this button so that you can easily reuse it in your other backend renderers? Are you going to write JavaScript to do this? Does it need to communicate with other parts of the app dynamically?
Wow, that sure sounds like it'd be nice if I could write it once in a 'client' folder and easily pass information from its parent to it... It would also be quite cool if I could make the network layer a pure abstraction so it could be mocked...
I know some libraries that help with that outside of HTMX, does HTMX have the toolkit for this stuff?
CONCLUSION
HTMX is "good enough" in the sense that it can produce decent static pages and bolt on a small amount of interaction. But you can't seriously tell me that you want to use UIs that require constant network round trips, and you can't tell me that you seriously want to be writing UIs that constantly require you to eject from the framework to actually make the user interactions feel good.
People who like HTMX dislike good UIs, it's that simple.
There is always so much cognitive dissonance for me when I read performance complaints like this from React/JS folks. They will complain that the user might have to wait 60-100ms extra for an interaction (not ideal at all granted), but totally ignore the 20 seconds spent waiting for megs of JS to download and execute for a new visitor or cache eviction (which happens all too often).
And then they're snappy :)
- Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity
- Opening Google Calendar on my MacBook (2017, dual core) took about 5s
- Opening Google Calendar on my MacBook with an "Empty Cache and Hard Reload" took about 10s
I'm not sure what your expectations are but it looks to me like web was faster than native for this use case, and even in the worst case under a factor of 2 slower.
Pray tell, how long does your phone take to open your calendar?
Are you using the personal version of Workspaces, or just the free version? I use the enterprise version of Google Workspaces, which has a lot more going on than the free version of Google's apps. Maybe that's a big part of the difference. To be clear, I get a 20-25 sec. cold start time on both my i7 Windows work laptop, my new AMD Linux machine, and a personal Windows machine with both OSes using different browsers (i.e., Chrome and Firefox).
> I'm not sure what your expectations are...
Your acceptance of a 10-second start time, while sneering at the possibility of maybe waiting 50-100ms for an interaction, is precisely the cognitive dissonance I mentioned originally. Possibly waiting 100ms for an interaction to complete is not good... but waiting 10 secs. (and more) to even begin working is very solidly in the "also not good category". Both approaches clearly have compromises. Knowing when to use each approach and resisting latching on to one approach due to personal affinity, is where our trade craft hopefully shines through. I know I don't always live up to that ideal, but we all (hopefully) try to move in that direction every day.
Your inability to read the conversation is hilarious
I just showed you that native mobile apps have the exact same startup time. You have exactly 0 evidence to the contrary, actually you ignored the question, and now you're saying I have cognitive dissonance.
Philosophically speaking: application toolkits take a moment to load, and then they behave like applications. Static views requiring server confirmation before UI updates DO NOT and NEVER WILL behave like applications, and so I hate using them, regardless of if the first view is a few seconds quicker. Any "time savings" are erased instantly by morale, and any real clock gains are wiped out by the time just a few interactions have gone by. If I'm using a tool to do significant work, and I have to wait for a server roundtrip before I can move between stages of that work, I'm going to be less efficient. This is why I've been saying HTMX has its use case - for shit UIs.
You are advocating for building shit UIs because the first load is faster. Go away, that's not a compromise.
- Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity
- Opening Google Calendar on my MacBook (2017, dual core) took about 5s
- Opening Google Calendar on my MacBook with an "Empty Cache and Hard Reload" took about 10s
...
Your inability to read the conversation is hilarious
I just showed you that native mobile apps have the exact same startup time.
>>>
You referenced "Opening Google Calendar" on several devices where a web browser is the only option. I had assumed you were talking about "Opening Google Calendar" in a mobile browser, since we've been talking about websites and browsers the entire time. If you wanted to add native mobile apps into the discussion, you ought to communicate that clearly.
> Go away, that's not a compromise.
Opinions vary, Basecamp/Hey is well thought of regarding their UI/UX and they use HTML over the wire, so I'm content. It sounds like you are content as well, so to each their own.
I felt like "web was faster than native for this use case" made it reasonably clear. The alternative would have been they tested some other office program and it took about 7 seconds but forgot to say that. Either way you decided to ignore "faster than native" in your rush to call cognitive dissonance, and that's on you rather than them.
I would say "50KB of zipped javascript framework" includes parsing and execution.
> not to mention the runtime overheads of every interaction having to go through megabytes of crap JS
...do I have the wrong number? Even when you decompress those 50KB, it's less than 150KB of javascript.
> instead of native, battle-tested browser code refined over 2 decades.
Browsers don't have native code for dynamically updating the page. Without javascript the solution is reloading, which adds a lot more overhead than the equivalent react.
- The `htmx-indicator` class can be used to show a loading spinner while an HTMX request is in progress.
- The `htmx-request` class is added to the element that makes an HTMX request. You can customize this class to disable pointer events, etc.
Example: https://codepen.io/arcanemachine/pen/ExeEzgG
(Stolen mostly from https://codepen.io/davidadeneye/pen/eYVrpxg)
Well, if it's a web app, getting the data from the server is inevitable. If it somehow can work without it, maybe it shouldn't be a web app? Or, as a last resort, it should be able to communicate the same way with the executable payload you served with the UI. If it's pure UI interaction you have the whole html+css at hand, it's huge and is rumored to be so capable, that people want to layout desktop UI's with it now.
2. > You know what I love as a user? When I have to wait for a network trip before the Button I clicked on does anything.
How can it do anything if it doesn't get a response from the server?
> But you can't seriously tell me that you want to use UIs that require constant network round trips.
Well, network roundtrips are often measured in ms, but a fat modern UI brings a netbook capable of compiling a kernel in less than half an hour to a crawl.
Don't get me wrong, I get some of your reasoning, but the issue is that functionality necessary for all these requirements you mention bleeds into basic hypertext model of the web and we get a byzantine chaos of today. So, we get blogs showing blank pages if JS is turned off, pages that won't show you the content unless you scroll and hover for a few seconds over each chunk of the page and all that insanity.
PS: It's easy to put people in boxes but it's never that simple.
I don't think you really read what I wrote. It is the CODE angle that I am addressing here; there is indirection in every piece of UI code because of what I said. It never is a piece of markup that is conditionally displayed based on state; it is the result of another hx-request, so I can never escape walking thru a graph that includes my entire UI and my entire backend while trying to build my UI. Yuck.
> 2. How can it do anything if it doesn't get a response from the server?
First of all, let's hope we all agree that each user action needs to be acknowledged and represented well by the UI. HTMX supports the most bare-bones "request is in flight" type of logic, but I usually like optimistic app behaviors when on the happy path. For instance, an object you created can show up in a list instantly even though the list came from the server. It's really easy to do this kind of stuff in normal UI frameworks, but HTMX outlaws it entirely.
On the flip side, I do want to acknowledge this point:
> we get blogs showing blank pages if JS is turned off
HTMX has a use-case, like I acknowledged: 'HTMX is "good enough" in the sense that it can produce decent static pages and bolt on a small amount of interaction'
This use-case definitely applies to things like blogs, but we have to be honest with ourselves. Blogs and this entire class of website aren't really a "user interface" or application so much as they are user-facing markup. Static content. I wouldn't call myself a "long-time UI guy" if I was building blog templates for a living.
HTMX falls apart the second you're building tools, if you care about the tool-user's experience as much as the tool developer's.
HTMX is great if you need "static website with forms and stuff"++ levels of interaction.
Basically anything that is database heavy CRUD stuff _without_: interactive and rich visualizations, complex document / rich text editing, drag and drop stuff etc. So it has very glaring limitations.
But I think it's very, very good within those constraints. It's very light and adds minimal overhead, it's very simple and it leans on _standards_, (HTTP/REST).
But there's an opportunity to combine this with another, very light, minimal overhead, simple library/tech that leans on standards. Namely web components.
I recently started a new project that we're going to ship as a JS bundle. It's basically just a UI that gets dynamically rendered on some site (that we don't control). So I gave lit/lit-html a go and it's been a breeze.
What I'm thinking now is why not use those two things together, solving separate problems? They are like ying and yang. Web components integrate with or can wrap more heavy weight interactive things easily. HTMX gives you a sensible, simple way of talking to the server.
[0] To say at least something about it, separating your UI layer is really more about sensible code organization and decoupling. If your tools/framework/libraries make this hard, kick them in the can.
Is this not true of react apps too? I don't write much UI code, but the react/vue codebases I've worked on perform REST/GraphQL requests all the time to render new data.
This takes me back to the top-of-chain comment I made: HTMX has its spot, but I see no world where HTMX needs another layer of JS on top of it. HTMX is not meant for highly-interactive domains, which is almost the exclusive use of JS. Why are we combining these? HTMX is the escape hatch from JS for people who want to do a bit better than true hypermedia but not write JS.
With `htmx` template literal tag recently added to PrimateJS, coupling of HTMX and PrimateJS looks much better in the code than previously. Meaning, single JS dev can do a lot even without knowing these two techs deeply, while leaving behind a code that is more likely to be maintainable. Both PrimateJS and HTMX aim to be simple to use and understand for someone being familiar with HTML and JS alone.
The quick start guide on primatejs.com is just an example of how to try PrimateJS quickly.
If React is what you're looking for feel free to try the PrimateJS React handler https://github.com/primatejs/primate-react.
If a project is appropriate to be built as a multi-page application (MPA), then HTMX can be added to it to give it some SPA like qualities (without having to resort to JS coding).
Moreover, you can implement HTMX along with support for graceful degradation, ensuring that the app continues to function even when JavaScript is disabled.
I see this flavor of opinion lot on HN and it always surprises me. How would you know? Kubernetes and Docker seem bloated to me, but I take good faith there's reasons to like them.
I think you make a good point. Reactive frameworks are quite comparable to Kubernetes. React addresses a number of issues but not without creating issues of its own. Kubernetes seems similar in this. It also seems quite "bloated" but it seems worth it.
Name a solution that adds value that doesn't also add a bunch of complexity.