simonbarker87
3 days ago
I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.
rtpg
3 days ago
One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times).
With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
ysavir
3 days ago
This is the thing that makes me lose interest in HTMX. People talk about it like it eliminates the need for JS/React/etc, but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS. Which is convenient, but hardly "less code", just a different language, and that backend language probably lacks a lot of functionality you'd want for UI convenience. That's all fine if you'll never want those UI conveniences, by my experience has been that the want of those UI conveniences creep in over time, and eventually you regret not using something that makes them native and easy.
I haven't actually played around with HTMX, so I might be sizing it up wrong, but it's mission statement just never resonated with me enough to want to try it out.
prisenco
3 days ago
The value of HTMX is that state now resides solely on the server, and the browser becomes only a representation of that state. This simplifies applications considerably because maintaining two copies of the state between client and server is the source of a lot of complexity in modern applications.
It wasn't about writing less code (although it is about writing less javascript) but about working with the concept of hypermedia instead of against or around it.
rtpg
2 days ago
Something I dislike about this argument is that there are a lot of UX flows where "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state. And popular backend frameworks are not super up to the task!
I have the impression that older web frameworks did in fact have a good amount of statefulness built in, and that causes a whole host of issues, so I believe to understand _why_ modern backend frameworks really don't lean into that.
prisenco
2 days ago
You're absolutely right, htmx is not built for every UX flow.
But neither is React. And we've been reaching for it by default for everything and that's been a mistake.
So much of what's built these days could be stateless MPAs. Servers have gotten crazy fast, and I'd certainly rather optimize for page size and server latency than build a React app.
With the upcoming views transitions api, a bit of htmx, and custom web components and you get 95% of what React offers without anywhere near the package size or complexity. You don't even need a compile step.
I'd never argue htmx is best for all use cases, I would hate for it to mutate the way React has, trying to be everything to everyone. But I hope htmx is the start of re-thinking how they approach the web and realizing that there are significantly simpler ways to build a frontend.
lloydatkinson
2 days ago
I definitely think it’s important to note it’s not really React that’s mutated it’s damn Vercel with its extreme vendor lock in plan with Next that’s trying to force React to be server side as much as client side, especially now that Vercel employs some React core team members.
Unfortunately worked with someone I was reasonably sure was a ~~paid shill~~ part of some Vercel partner/influencer programme as they were adamant we must use Next (and Vercel but they lost that argument) for a project the team absolutely didn’t need to use it for.
In fact the rewrite of a project was worse than the original application. The original was snappy and instant and just worked meanwhile the Next version was slow, full page refreshes for every action, and just totally awful.
I couldn’t get off that team quick enough.
langcss
2 days ago
Next is odd because it gives lots of "high preformance" vibes with static rendering and image optimization. It is fast enough but not as fast as tuning up a classic MVC app which caching, avoiding JS bundles and React or deferring scripts etc. Send out the right cache headers and chuck a CDN in front.
Next is ironically fast if you prerender/static generate AND the client disables JS!
cies
2 days ago
> "tracking the state server-side" is a _major_ pain in the butt compared to having client-side state.
The issue with many SPAs I saw was that state had to be managed BOTH in the browser AND on the server. This resulted in more code, longer time to market, and reduced velocity.
The SPA route can be a requirement (e.g. when a highly interactive UX is warranted), in that case there's no way around it. But when it's simply a bunch of forms in a business app, that's usually not the case: in those cases I'd go with a traditional "multi page app" and/or HTMX.
omnimus
2 days ago
Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation. But in my experience it’s not a bad one because only very best designers i worked with were deliberate about state so they could use this advantage.
More likely than not you get designs that create all kinds of messy app states around and users then can’t properly use bookmarks or back button. This in turn leads to hotfixes and more mess in frontend. Forcing designers to think about urls and their names is in most cases very good.
naasking
2 days ago
> Server side frameworks force you to keep most state in the URL (or localstorage). This is a limitation.
Rather than limitation, I think of it as a constraint. The best engineering takes place under constraints, because when you're unconstrained you have a high chance of repeating mistakes that have known solutions. In this case, you rightly point out that the UX of the browser has certain limitations and making all state URL-addressable is the interface to that UX.
librasteve
2 days ago
this is the argument that resonates with me ... increasing complexity around event driven frameworks includes more cognitive load to reason about state information in two (or more) places whereas the web of olden times was conceived around stateless clients (plus some cookies)
as I say in the post, HTMX is not for you if you are building a web app that needs this ... but in 90% of cases web sites don't
ysavir
2 days ago
This isn't unique to HTMX though. You can do the same with any frontend framework. You can argue that HTMX forces this to be the case, but has a lot of trade offs in doing so.
the_gipsy
2 days ago
I haven't used htmx, but this doesn't seem to be true at all. The equivalent state would also be in the client, as URL and HTML.
prisenco
2 days ago
The state is represented by the url and html, but that's not the same as managing state in client-side memory using Javascript.
Hypermedia Systems is a great read, by the htmx creator, available here:
consteval
2 days ago
The client doesn't produce those URLs or HTML - the server does. That's just what the user sees.
langcss
2 days ago
There is client state. The URL plus the sum of whatever partial swaps you did since loading the page.
prisenco
a day ago
That's the representation of state, not the state itself.
omnimus
2 days ago
The approach actually is not that different if you realize that there isnt much difference between sending json and sending html. Htmx is like if you were using react and rendering raw html everywhere.
The main advantage people feel with htmx is that your routing is serverside and you dont have to keep quering/filtering/transforming data from your api to fit UI because you have access to everything. Do you suddenly need number of groups user is part of in this one only place? Well api doesnt have it so either extend api (figure out how to name it and where to put it) or you fetch all groups user is part of and count them on frontend. This middlelayer is something i realized i more often than not need. And when i need interactive UI i can initialize webcomponent or even have react island. Since htmx (and other similar tools) dont expect to overtake whole DOM but work with elements they can be very isolated if you want them to be.
miggol
2 days ago
At the end of the day, neather approach really has features over the other. HTMX doesn't forbid other JS components.
I think HTMX appeals to fullstack devs like me who often find themselves needing bespoke API calls for their frontend views anyway.
When writing tightly coupled backend code for a frontend view, I'm quick to think "well why am I not doing this entire feature in the backend, anyway?" And HTMX makes that super easy without giving much up.
But the opposite reaction would be equally valid.
naasking
2 days ago
> but as far as I can tell, you're still writing those same templates, just using your backend language instead of JS.
Yes.
> Which is convenient, but hardly "less code"
It is strictly less code because you're no longer validating on both client and server. It's also more than just "convenient", because it also forces you to stick to the well understood browser UX, ie. all state is URL-addressable.
scoofy
2 days ago
I would rather write 1000 lines of Python than 100 lines of JS.
Nothing wrong with JS, I'm just not fluent in it. Whereas, Python is my native programming language, and I can just see it without looking anything up. This is why I love HTMX. I just want basic web interaction without having to do it all in Javascript.
Cruncharoo
2 days ago
No, you're pretty much exactly right. I am not a programmer by trade and when searching around and trying different technologies the first one that really clicked for me was HTMX. For whatever reason, handling all of that logic on the backend felt more natural. I've since started learning React and it's amazing how much 'easier' some of those UI conveniences really are. However, in places where they aren't truly necessary it's hard to beat the convenience and ease of a small Flask/SQLite/HTMX app, for me.
But yeah, if that doesn't really fit your mental model then I don't see a huge reason to give it a try.. other than it IS fun!
BeefySwain
3 days ago
Check these out and see if they provide any insight for your specific issues :)
djbusby
3 days ago
I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
librasteve
2 days ago
this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
hyperdang
3 days ago
[flagged]
esaym
3 days ago
rofl
hyperdang
3 days ago
[flagged]
devjab
2 days ago
HTMX pairs incredibly well with something like Go’s templates. Giving you the “what you’d want react to be” experience for many scenarios. I imagine it’s similar with other languages with good templating engines, I just know it’s extremely easy to build things with Go and HTMX.
That being said, HTMX is not for everything. It’s great for internal tools as long as you don’t have very complex role-based access model. But security and access rights is where I think HTMX quickly becomes too complicated compared to a more traditional approach. As far as having “too many back end views” I do think that is down to you choosing an “incompatible” backend for your HTMX. It’s hard to say without knowing your details. You do say that you put a REST api behind it, but why would you do that with HTMX?
librasteve
2 days ago
In the article I show HTMX and Pico CSS with Raku and Cro templates (Cro is one of the leading Raku web frameworks - there are others such as Hummingbird) in the same role as Go and ... (put your favourite Go HTML template engine here) - I am currently implementing the basic htmx.org examples in Raku by translating from https://github.com/Konfuzian/htmx-examples-with-flask/tree/m... which has them in Python / Flask. The HMTX Discord has about 35 channels across all the various server side language options (including node).
Certainly agree that HTMX is not for everything. Nor is Raku ;-)
halfcat
3 days ago
When I build a page that uses HTMX, I go one of two ways.
Traditionally I first build it as a fully server-side rendered page. Once that’s working I setup my views to return HTML partials for different parts of the page.
So I might still have multiple views (or I might have single views that handle path parameters, query parameters, etc), but each is then basically just returning part of the existing template:
Full page: return render(request, "jobs/index.html", ...)
Some part of the page: return render(request, "jobs/index.html#status", ...)
You can sort of think of this the same as you would with JSON API endpoints, where you still need different endpoints handling different HTTP methods (GET, POST, etc) for the different CRUD operations, and there’s a tradeoff regarding how granular you get with views, but typically you can make the views pretty generic and reusable (the same way you can make JSON API endpoints that essentially just serialize database query results). There’s an article [0] that gives an example of a similar approach.
More recently I’ve been using a more component-based approach, using something like htpy [1] where I build up the page out of components (like you would in React), and sprinkle JS and CSS into the HTML with Alpine and Tailwind.
[0] https://www.circumeo.io/blog/entry/django-htmx-and-template-...
chromanoid
2 days ago
You may want to look at https://roca-style.org/
If you have problems filtering in the backend but it's easy in the frontend your backend technology is probably lacking.
_heimdall
3 days ago
I've tried HTMX with a few different back end frameworks and languages, my setup varies a lot based on which framework/language I use.
The pattern I've been happiest with is when I can have a templating language designed to work really well with a component (or partials) approach.
I break down the UI into smaller components as I add more HTMX interactions. The UI is effectively a tree of nested components, much like react or svelte. When an HTMX request is sent, the API handler logic runs and instead of returning a success response it sends back HTML for the individual component(s) that HTMX needs to update.
tl;dr; When a request comes in, check headers to see if it was an HTMX request. If it wasn't, handle the API logic and return the full HTML page. If it was an HTMX request, still run the API logic but send back only the rendered components/partials that changed.
rtpg
2 days ago
yeah it's just that when I have a REST API I get like... I guess 20 or so endpoints "for free" (since I can PATCH specific fields up in interesting ways).
Maybe I need to be writing REST-looking form submission endpoints.... but then I have the immediate issue of presentation.
imacrayon
3 days ago
Check out https://alpine-ajax.js.org it defaults to using the same template views you would in a typical JavaScript-less app, then you can sprinkle in fragments where you need to optimize requests.
stuckinhell
2 days ago
yea I'm seeing alot of people combine it with alpine, but then whats the point ?
meowtimemania
3 days ago
I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
prisenco
3 days ago
UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind.
Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard.
We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
taberiand
3 days ago
I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
aurareturn
3 days ago
So why complicate things and just use something like React + Next.js, which is already designed for complex apps?
taberiand
20 hours ago
I've used both and I prefer the htmx approach. React/NextJS are what over-complicate things - particularly when it comes to server vs client side rendering and hydration, state management, passing props, caching, static site generation, slow and fragile development environment etc etc etc.
I recently rewrote a site that was built in NextJS into Go+Echo+Templ+HTMX+AlpineJS, keeping just the Google Maps and Facebook components (but only injected as necessary, rather than needing a whole App wrapped around them)
The result was about 50% of the size of code that is much easier to reason about and test, better performance, simpler and smaller (size and resource) deployment - essentially better in every way.
prisenco
3 days ago
Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
kaoD
2 days ago
Web components are the stuff that nightmares are made of.
The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way.
The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic.
Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.
Overall not a great experience for user-facing apps.
throwitaway1123
2 days ago
> Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app.
You can SSR web components using the Declarative Shadow DOM API, which is finally supported in all of the major browsers and works without JS.
prisenco
2 days ago
| Web components are the stuff that nightmares are made of.
There's lit.dev for an easier approach.
kaoD
2 days ago
But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities.
At that point why not just use React? What do I get from using Lit instead?
prisenco
2 days ago
I don't personally mind writing web components by hand, but for those who want something easier, lit.dev is popular. There's also slim.js and Stencil if you don't mind a compile step.
The design of web components could be better, but I much prefer them to the true nightmare that React development has become. And the api is stable, which means a longevity that frameworks don't have.
| no SSR nor progressive enhancement
I have not been impressed by React SSR in the wild in terms of progressive enhancement. This seems like more of marketing promise than a real world experience. Do you have any examples to link?
librasteve
2 days ago
I have been musing in going in this direction - but your post has lowered this idea in my project plan for now ... thanks!
synergy20
3 days ago
i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.
zerr
2 days ago
For such an internal web app, why not do it in a fully traditional/multi-page/server-rendered manner?
simonbarker87
2 days ago
I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA.
Plus I wanted an excuse to use htmx.