7 ms·

Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as

by rednb 19d ago

Maybe a contrarian view, but as someone very knowledgeable about .NET API backends + angular on the frontend, I've found that HTMX made things more difficult as it required me to move back to mixing presentation concerns with business-logic and data concerns (basically have the backend produce the UI, which is whole point of HTMX). This is not a criticism but I suspect that the people enjoying HTMX are either people preferring old-school server-side rendering or react users. Just sharing my experience, because HTMX is the absolute darling of hacker news. Since i mainly develop real SPA, i found that is more complex than just using typscrpit if you build something non-trivial as managing state on the server is not fun at all. In my opinion if you are happy using angular, you'll find that HTMX is a step backward in terms for dev experience. Can't speak about react, but since it is not a battery included stack unlike Angular, i can understand why many people find they'd be better off moving things server-side instead of messing around with 15 third-party libraries. My 2 cents

perardi 19d ago
I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.) Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite. Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)
- embedding-shape 19d ago
  Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches. I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.
  - perardi 19d ago
    Ha, that was me and Hugo, back in the day, for static sites. And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.
  - tyre 18d ago
    As someone who has conducted a ton of systems design interviews, the "I used these tools at my last job so I will use them for this completely different problem" is bamboozling. OTOH, there are advantages to comfort picks. You know the APIs, you know the common libraries in the ecosystem, you know the quirks and pitfalls. It might not be optimal—and in production it compounds—but for dinky personal projects or finite-scoped professional things, it's understandable.
- kvirani 19d ago
  Nice. Curious about your views on SolidJS?
- rednb 19d ago
  > Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite. > Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS) My concern with is that i build line of business applications for a living, and literally, every project i work on ends up growing in scope such that even the simplest ones, reach a point where the customer asks for items that are just much simpler to do with a front-end framework. And these are often cross cutting concerns, such that it is not as easy as simply adding some js to one page. Example: "i want to be able to reorder all the columns of all the tables of the website, and hide some columns, with my preferences remembered for each table". Customers pull that kind of thing off their hat every time, such that even "basic websites" can move out of the trivial territory any time. And this is just the most trivial example i can think of. I want the tech stacks i use to be future proof, as in not having to rewrite everything when requirements become more complex (as it is also typically a time where we aren't given much time budget, as they need it for yesterday). For something for which i fully control the roadmap, i may consider htmx (but even then, even my own products grow in ambition rapidly) however for customer projects i find this choice way too risky. I need to be able to capitalize on the tech infrastructure i've built as requirements get complex, both due to customer time constraints and because this is where we get some of the highest profit margin from our work. Having to rework most of what i've done every time a complex requirement comes up, would be inefficient with this regard. To me it's a case of knowing your tools in depth, to make meet most requirements (including from a performance perspective). Maybe erlang or go would have been more suited for a project from a philosophical perspective but since i specialize in .NET + angular, unless there is hard blocker, i'll use this tech stack, and everything is fine from the perspective of the customer. But i gain that the project is future proof and i won't need to reengineer it when it moves of its initial sweetpot.
  - jacques_chester 19d ago
    From the same author: https://grugbrain.dev/#grug-on-saying-no https://grugbrain.dev/#grug-on-saying-no
radicalbyte 19d ago
There are an army of people using SPAs for problems best served by a simple and more traditional website. It has been a thing since SPAs started showing up so you have a whole generation who think that Next.js is just how you build for the web. Then HTMX is to them what the micro-ORMs were for me (and, if you've been in .Net for a couple of decades, I suspect you too).
- Cthulhu_ 19d ago
  It was so bizarre seeing people go from pure SPAs, to the concept of "hydrating" a website (ok still makes sense to a point), to coming up with server-side rendering like it's novel. I mean sure, things like Next, Gatsby, etc can theoretically create the best of both worlds - static site for search engines and no-js users, content first, and very fast client-side rendered content afterwards. But that's a lot of extra engineering, considering a good server-side rendered website is also fetched and rendered within milliseconds.
xp84 19d ago
> managing state on the server is not fun at all. Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.
- mexicocitinluez 18d ago
  I haven't used sessions in over a decade and haven't regretted that decision once. It opens up a whole new class of problems you don't have when using client-side frameworks.
  - yawaramin 18d ago
    So what do you use instead?
    - mexicocitinluez 17d ago
      It depends on the specific data. Do you have anything that you store in session in mind? Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.
      - yawaramin 17d ago
        I’m talking about auth, like a session cookie. What do you use for auth?
        mexicocitinluez 16d ago
        I use Entra, so the session cookies are created through login.microsoft.com. Which means I'm not actually managing the session. When I said I don't use sessions, I should have specified I don't use them for application state (or roles and stuff).
fatplexer 19d ago
I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression. Seriously DB->json->client->toHtml DB->toHtml->client Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice. Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.
- turtlebits 19d ago
  Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.
  - fatplexer 18d ago
    [dead]
  - devalexwells 18d ago
    As far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc). Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?
aidenn0 19d ago
> ... managing state on the server is not fun at all. Do you not have a database for your backend? Managing state is kind of their thing.
- mexicocitinluez 18d ago
  Are you not familiar with building web apps? So, when building for the web you'll essentially have 2 different categories of state: server and client. Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.
  - aidenn0 18d ago
    I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.
    - mexicocitinluez 17d ago
      We are talking about how state is stored, not about CSS. And it makes me think you haven't had as much experience as you think. How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
      - aidenn0 17d ago
        > How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server? For really simple stuff you can use CSS sibling selectors: https://jsfiddle.net/Kqscu/4/ https://jsfiddle.net/Kqscu/4/ For more complicated stuff, it is in the html as elements. With htmx you can often do this by making a request to the server to update a subtree; the server doesn't need to know the state that the user is seeing, just what is happening in the specific request. Sometimes just updating html subtrees isn't quite enough, and then I use javascript. Transient state that is only concerned with what is presented to the user is probably not best done on the server.
intrasight 19d ago
> mixing presentation concerns with business-logic That's on you not on your platform
splawn 19d ago
I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic? Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Unix socket. Obviously those representations matter at the presentation/transport boundary, but why should choosing HTML force that concern into the business logic?
- troupo 18d ago
  HTMX requires you to return HTML chunks (and calls that hypermedia) that get dumped directly into the client-side HTML. So instead if returning data (JSON, XML, whatever), every part of your API now needs to return parts of client-side UI, and be aware of changes in it.
  - splawn 18d ago
    I know. HATEOAS... I understand the issue of mixing state models.. angular SPA style vs HATEOAS. But that still doesn't answer what I was asking about mixing presentation concerns into business logic. Returning HTML means the presentation layer has to know about HTML. Why would that require the business logic to know about it?
mhitza 18d ago
For me htmx is a utility library to spruce up a couple of interfaces here and there that benefit from a bit of reactivity. Anything more complex I really don't feel that it's the right tool. Or that there is any great tool to build SPAs. There is sometimes this trends on projects of using anything like a universal hammer. And then they SPA their project.
tetha 18d ago
I agree this is a scope or focus thing. Different tools for different things. If you are already maintaining a tool chain, a supply chain and skills in an SPA framework for multiple customer-facing, client-driven projects, I don't think you have much of a use for HTMX. Hence why at work, we have our full-time frontend engineers doing this, because it gives you the most flashy quality. I am an infrastructure engineer. I have privately tried out a couple of SPA frameworks, The complexity to set this up for the first time is immense. And if you have rarely touched projects, the churn of the tooling and dependency ecosystem is taking up a significant amount of time for something that may be nice to have at work, or a pet project at home. It's not cool if you have half a day to touch an old project and everything has rotted away around it so nothing interesting gets done. Something like Pydantic, Flask or Django + Jinja generally doesn't do that. And HTMX can make it nicer fairly cheaply.
- deleted 18d ago
  [deleted]
cbeach 18d ago
I totally agree. When we started splitting presentation from content (CSS) that was a wonderful step forwards. And splitting back-end and front-end concerns similarly makes for a cleaner and more elegant design in both codebases. IMO HTMX is a weird regression in our design patterns. Hopefully a temporary anomaly. I'd never choose to work in a company that adopted this mixing of front and back end code - it's a red flag as far as I'm concerned.

by rednb 19d ago

perardi 19d ago

I agree. We are moving away from HTMX at work, to React. (After we moved away from Angular. That was…a choice…that I didn’t make.) Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite. Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS)

embedding-shape 19d ago
Yeah, typically I end up building websites (for myself and others) in basically three "lanes". Static HTML/CSS files, great for docs, presentations, reports and similar. Or, websites with some interactive/dynamic elements, HTMX is great for this. Or, fully fledged "client-side apps" where it's more of an application than website, then I go full out dynamic programming with ClojureScript and similar approaches. I'm not sure why so many people seemingly fall into the trap of trying to find one tool and then use that absolutely everywhere. I mean, I'm familiar with it as in "it's fun" as I used Nix as a framework for a static website builder, but I keep seeing people making those sort of choices professionally too. Like when React first became popular, then suddenly people try to jam it into absolutely everything, until they slowly walk back and then after some years agree that maybe it's good for some things, not for everything and not as a default.
- perardi 19d ago
  Ha, that was me and Hugo, back in the day, for static sites. And, yeah, HTMX is truly great for sites with limited interactivity. You really, really do not want or need a full React Leaning Tower of Pisa stack for a simple presentational website.
- tyre 18d ago
  As someone who has conducted a ton of systems design interviews, the "I used these tools at my last job so I will use them for this completely different problem" is bamboozling. OTOH, there are advantages to comfort picks. You know the APIs, you know the common libraries in the ecosystem, you know the quirks and pitfalls. It might not be optimal—and in production it compounds—but for dinky personal projects or finite-scoped professional things, it's understandable.
kvirani 19d ago
Nice. Curious about your views on SolidJS?
rednb 19d ago
> Here’s the thing: there’s still a place for HTMX. Lots of places. But “building an SPA but not actually and SPA” is not a lane for HTMX. Nor do they promote HTMX for that purpose. Really quite the opposite. > Different tools for different jobs. (Me? I honestly love React, just a more minimal stack. Zustand and TanStack and Vite. No Redux or Next.JS) My concern with is that i build line of business applications for a living, and literally, every project i work on ends up growing in scope such that even the simplest ones, reach a point where the customer asks for items that are just much simpler to do with a front-end framework. And these are often cross cutting concerns, such that it is not as easy as simply adding some js to one page. Example: "i want to be able to reorder all the columns of all the tables of the website, and hide some columns, with my preferences remembered for each table". Customers pull that kind of thing off their hat every time, such that even "basic websites" can move out of the trivial territory any time. And this is just the most trivial example i can think of. I want the tech stacks i use to be future proof, as in not having to rewrite everything when requirements become more complex (as it is also typically a time where we aren't given much time budget, as they need it for yesterday). For something for which i fully control the roadmap, i may consider htmx (but even then, even my own products grow in ambition rapidly) however for customer projects i find this choice way too risky. I need to be able to capitalize on the tech infrastructure i've built as requirements get complex, both due to customer time constraints and because this is where we get some of the highest profit margin from our work. Having to rework most of what i've done every time a complex requirement comes up, would be inefficient with this regard. To me it's a case of knowing your tools in depth, to make meet most requirements (including from a performance perspective). Maybe erlang or go would have been more suited for a project from a philosophical perspective but since i specialize in .NET + angular, unless there is hard blocker, i'll use this tech stack, and everything is fine from the perspective of the customer. But i gain that the project is future proof and i won't need to reengineer it when it moves of its initial sweetpot.
- jacques_chester 19d ago
  From the same author: https://grugbrain.dev/#grug-on-saying-no https://grugbrain.dev/#grug-on-saying-no

radicalbyte 19d ago

There are an army of people using SPAs for problems best served by a simple and more traditional website. It has been a thing since SPAs started showing up so you have a whole generation who think that Next.js is just how you build for the web. Then HTMX is to them what the micro-ORMs were for me (and, if you've been in .Net for a couple of decades, I suspect you too).

Cthulhu_ 19d ago
It was so bizarre seeing people go from pure SPAs, to the concept of "hydrating" a website (ok still makes sense to a point), to coming up with server-side rendering like it's novel. I mean sure, things like Next, Gatsby, etc can theoretically create the best of both worlds - static site for search engines and no-js users, content first, and very fast client-side rendered content afterwards. But that's a lot of extra engineering, considering a good server-side rendered website is also fetched and rendered within milliseconds.

xp84 19d ago

> managing state on the server is not fun at all. Really? I've never found that difficult. Sessions exist, URL parameters exist... Perhaps in a complex SPA you can have trouble, but so many of the "applications" I've worked on are just glorified documents.

mexicocitinluez 18d ago
I haven't used sessions in over a decade and haven't regretted that decision once. It opens up a whole new class of problems you don't have when using client-side frameworks.
- yawaramin 18d ago
  So what do you use instead?
  - mexicocitinluez 17d ago
    It depends on the specific data. Do you have anything that you store in session in mind? Having the client/server split has made this a lot easier to reason about. I store client state on the client and server state stays on the server.
    - yawaramin 17d ago
      I’m talking about auth, like a session cookie. What do you use for auth?
      - mexicocitinluez 16d ago
        I use Entra, so the session cookies are created through login.microsoft.com. Which means I'm not actually managing the session. When I said I don't use sessions, I should have specified I don't use them for application state (or roles and stuff).

fatplexer 19d ago

I'll shill datastar for a second, there's barely a notion of frontend state management if you treat HTML as a projection surface with interactivity. I'd argue HTML is the most efficient wire format for interactive web apps, especially with streaming + compression. Seriously DB->json->client->toHtml DB->toHtml->client Just imagine if that html wire format also conveyed the interactivity too and you eliminate the issues. And you can always seperate whatever concerns you want in whatever tpl lang of your choice. Also htmx 4 is kinda just an worse datastar funnily enough In it's own way.

turtlebits 19d ago
Datastar relies way to much on IDs everywhere that it's not ergonomic and turns into a chore. It's also a bit too complicated for its own good trying to solve everything.
- fatplexer 18d ago
  [dead]
- devalexwells 18d ago
  As far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc). Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?

aidenn0 19d ago

> ... managing state on the server is not fun at all. Do you not have a database for your backend? Managing state is kind of their thing.

mexicocitinluez 18d ago
Are you not familiar with building web apps? So, when building for the web you'll essentially have 2 different categories of state: server and client. Server state is obviously what's pulled fromt the db, but that's 100% not where something like form state should be stored. Or button toggle state. Or whether a modal is open, etc.
- aidenn0 18d ago
  I have written web apps and about 80% of the sorts of things you are talking about can be handled with just html/css and I just use javascript for the other 20%. It's not like when you use htmx it disables all other javascript APIs.
  - mexicocitinluez 17d ago
    We are talking about how state is stored, not about CSS. And it makes me think you haven't had as much experience as you think. How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server?
    - aidenn0 17d ago
      > How do you deal with form state using CSS? Where does it get stored? In the html as elements? So not on the server? For really simple stuff you can use CSS sibling selectors: https://jsfiddle.net/Kqscu/4/ https://jsfiddle.net/Kqscu/4/ For more complicated stuff, it is in the html as elements. With htmx you can often do this by making a request to the server to update a subtree; the server doesn't need to know the state that the user is seeing, just what is happening in the specific request. Sometimes just updating html subtrees isn't quite enough, and then I use javascript. Transient state that is only concerned with what is presented to the user is probably not best done on the server.

intrasight 19d ago

> mixing presentation concerns with business-logic That's on you not on your platform

splawn 19d ago

I don't understand (possibly because I lack Angular experience): what is it about a .NET backend using HTMX that requires presentation concerns to be mixed with business logic? Don't you have to maintain that separation either way? Your core/application logic shouldn't know how its result is ultimately represented. That could be JSON or HTML over HTTP, Protobuf over a TCP stream, or a custom binary protocol over a Unix socket. Obviously those representations matter at the presentation/transport boundary, but why should choosing HTML force that concern into the business logic?

troupo 18d ago
HTMX requires you to return HTML chunks (and calls that hypermedia) that get dumped directly into the client-side HTML. So instead if returning data (JSON, XML, whatever), every part of your API now needs to return parts of client-side UI, and be aware of changes in it.
- splawn 18d ago
  I know. HATEOAS... I understand the issue of mixing state models.. angular SPA style vs HATEOAS. But that still doesn't answer what I was asking about mixing presentation concerns into business logic. Returning HTML means the presentation layer has to know about HTML. Why would that require the business logic to know about it?

mhitza 18d ago

For me htmx is a utility library to spruce up a couple of interfaces here and there that benefit from a bit of reactivity. Anything more complex I really don't feel that it's the right tool. Or that there is any great tool to build SPAs. There is sometimes this trends on projects of using anything like a universal hammer. And then they SPA their project.

tetha 18d ago

I agree this is a scope or focus thing. Different tools for different things. If you are already maintaining a tool chain, a supply chain and skills in an SPA framework for multiple customer-facing, client-driven projects, I don't think you have much of a use for HTMX. Hence why at work, we have our full-time frontend engineers doing this, because it gives you the most flashy quality. I am an infrastructure engineer. I have privately tried out a couple of SPA frameworks, The complexity to set this up for the first time is immense. And if you have rarely touched projects, the churn of the tooling and dependency ecosystem is taking up a significant amount of time for something that may be nice to have at work, or a pet project at home. It's not cool if you have half a day to touch an old project and everything has rotted away around it so nothing interesting gets done. Something like Pydantic, Flask or Django + Jinja generally doesn't do that. And HTMX can make it nicer fairly cheaply.

deleted 18d ago
[deleted]

cbeach 18d ago

I totally agree. When we started splitting presentation from content (CSS) that was a wonderful step forwards. And splitting back-end and front-end concerns similarly makes for a cleaner and more elegant design in both codebases. IMO HTMX is a weird regression in our design patterns. Hopefully a temporary anomaly. I'd never choose to work in a company that adopted this mixing of front and back end code - it's a red flag as far as I'm concerned.