It looks like "primate" is another javascript-based HTTP request handler, with a template language.
I don't get the connection to htmx, though, which runs client-side. It looks like there's a separate template variant for "htmx" vs HTML, but why would you need a different server-side template handling for stuff that executes client-side?
I don't understand the point of the domains either... it somehow wraps an ORM but an ORM is already a wrapper (not to mention a server-side ORM seems an awkward fit for htmx, which wants the server to be stateless).
The lack of mentioning the original htmx is incredibly confusing considering that it does support at least some of the exact same functionality, down to the hx- attribute prefix.
Questions relating to this are probably going to dominate this thread, but I suppose that's what the author deserves.
It seems like they use some of the same syntax of hx-get and hx-post, but then some of the templating like you see in apline.js. But no mention of either project. This primatejs appears to be more of a node backend and provides some variation of the htmx library.
Speaking as a long-time UI guy... The only thing I can imagine being worse than HTMX's design philosophy is then writing another layer of JavaScript on top of it
Phaleth, can you say more about what this is and why? The whole repo, org, and sub-repos don't talk even once about the motivation behind the project. Finding it hard to understand what this post is soliciting in terms of feedback.
> The only thing I can imagine being worse than HTMX's design philosophy
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.
> 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.
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).
That seems like a strawman. Google Docs spins up a brand new doc - including back-end creation time, mind you - in 7 seconds to full interactivity. Code Sandbox for collaborative coding and hot-reloading in the browser might take 20 seconds. My own apps are usually <512kB because they're built with about 5 libraries outside the build tools, so they take in the region of 1s to interactivity.
First, I commend you for writing efficient and snappy apps. People who care about quality and user experience are rare in any field! However, Google Calendar (which I use a lot) takes 20-25 seconds to load on my relatively recent i7 laptop whenever its cache is evicted. I haven't timed Gmail, but it is also very slow (many seconds) when it needs to reload everything. Google's apps are some of the worst offenders, but Proton Mail's apps are similarly slow. This is all consistent across several devices, so I wouldn't call it a straw man at all. Honestly, who doesn't encounter sites with loading screens that last in the high single digit seconds? This is very common, and is completely unacceptable to my mind.
- 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?
> Opening Google Calendar on my personal phone with my personal calendar took about 6s to interactivity
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 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
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 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.
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.
That doesn't include the overhead of parsing & executing all that, not to mention the runtime overheads of every interaction having to go through megabytes of crap JS instead of native, battle-tested browser code refined over 2 decades.
> That doesn't include the overhead of parsing & executing all that
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.
1. > adding a fresh layer of indirection on every single UI interaction.
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.
> 1. getting the data from the server is inevitable
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.
Ok, thanks a lot for the detailed answers. I see we're coming at it from totally different angles. Can't say I'm 100% convinced but I'll be refining my understanding of the topic and my position further.
I came to similar conclusions as you at some point (minus your first point, which is more of an organizational or tooling/tech issue and not very interesting to me [0]):
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.
> you can't seriously tell me that you want to use UIs that require constant network round trips,
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.
I agree with this, do I not? I said: 'HTMX is "good enough" in the sense that it can produce decent static pages and bolt on a small amount of interaction.'
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.
HTMX allows to write less JS and for the most part less frontend code in general. That is the main benefit. HTMX is an escape hatch for backend JS devs too. Please, note that PrimateJS backend code is very compact, which itself allows to write less JS code as well.
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 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'm far from front-end, but from the user experience, current stack seems excessive and bloated
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.
As a front heavy full stack Dev I concur. The debate going on lately has maybe had some important points but also been quite lopsided.
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.
I’d argue the back end is pushing a bunch of complexity to the front end and then we all wonder why it’s so complex https://bower.sh/dogma-of-restful-api
I have a lot of experience in JS - even contributed to MooTools back in the day, until the team left to create React.
I run node on one server, Nginx with Php on another, and have plenty experience with many of the front end frameworks.
Try designing a web page - say the product page of a shoe store - multiple times. First try as though you have React (or Vue, Svelte, Angular, etc.), but never heard of HTMX, then try with HTMX as though you never heard of React, etc.
OK, its a bit of an apples to oranges comparison, especially if you would use hotwire or whatever.
Now, test those pages for responsiveness and ease of maintenance.
I did that, and the HTMX version won hands down. I was pretty surprised. You should try it; then comment again.
I now use HTMX extensively, and avoid frameworks unless they would really save time and effort.
This is good, a real objective evaluation. I think most of the critics of HTMX stems from pure front-end devs who are not really concerned of the back-end side.
While HTMX is tailor made/simple, for those who needs to build full-stack, while also having the great experience of SPAs.
Granted, it will never be able to compete with powerful JS frameworks on an apple-to-apple comparison, but that's not what it's designed for, It's an upgrade of HTML, not JS.
> "Using htmx is reminiscent of the dark times of web development directly over ftp without using a version control system."
Were those really the issues in the dark times?
To me those times are back when very incompatible scripting languages, with very incompatible browser DOM implementations roamed the land.
The simplicity of MPAs, the immediate feel of just writing to disk and refreshing the browser, without any slow transpilation process - this is how I remember the "dark times" of htmx.
I like HTMX. I just needed to put together a SPA and I have limited JS skills. HTMX was pretty easy to pick up and it was the easy bridge between my frontend and backend that I needed, while giving also allowing me to add some basic interactivity. I think its pretty cool.
I like it too for now. Htmx + Caddy (goodbye nginx), Bulma (css) and Fastapi (python backend). All this for a student management SPA. My day job as a school teacher means (A) I have to deal with outdated monolithic webapps daily, and (B) I don't exactly have all the time in the word to write software. This stack has been a godsend.
I don't get the connection to htmx, though, which runs client-side. It looks like there's a separate template variant for "htmx" vs HTML, but why would you need a different server-side template handling for stuff that executes client-side?
I don't understand the point of the domains either... it somehow wraps an ORM but an ORM is already a wrapper (not to mention a server-side ORM seems an awkward fit for htmx, which wants the server to be stateless).