7 ms·

I have been using htmx to build a web app and came to the conclusion that it is a dead-end. The main problem is that the state of your frontend application is

I have been using htmx to build a web app and came to the conclusion that it is a dead-end. The main problem is that the state of your frontend application is in the URL. This is not flexible enough for modern UI where you might have many different zones, widgets, popups, etc. that all need their own local navigation, activation states etc. Putting all of this in a single global url is extremely hard. Designing your app so that you don't need to put it all in the global url is harder. This problem is trivially solved by React / Vue that all provide their version of a state store that can hold the state, and make it easy as well to have elements shared or not between the tabs of your browser. If you build your applications like phpBB forum this is not a problem, but nowadays users expect better.

mervz 1y ago
It's a dead end for your use case, let's be very clear about that. And it's funny that you think anything about React and/or Vue is 'trivial'.
- nawgz 1y ago
  Surely you’re not saying the frameworks famous for ui = f(state) actually suck at managing state…
  - jaredcwhite 1y ago
    kinda does, tbh.
  - the_gipsy 1y ago
    If it only were true. React is nothing like ui = f(state). More like ui = f(some_trivial_state) + lifecycles magic + probably global_state. Garbage. But effective devrel.
    - nawgz 1y ago
      This type of dismissive attitude is so strange to me. The only reason "lifecycles magic + probably global_state" would be causing your app to behave unpredictably is - this is going to shock you - because you closed your mind to a tool by dismissing it as garbage before you used it, and then failed to use it properly because you think its popularity boils down to PR. For instance, you could entirely forgo the influence of lifecycles and global state by putting everything in a top-level Context with 1 state object that you only ever update by calling `setState`. After that, you might find reasons to optimize your app, which could lead you to more interesting approaches like reducers or state management libraries or memoization, but I'm guessing you would never get that far and just go back to what you were doing before, since YOUR preferences are battle hardened and reliable software, while things you don't know about are only popular because of Facebook. Obviously.
      - the_gipsy 1y ago
        So, redux? It's either redux or, sorry, "lifecycles magic + probably global_state". And who uses redux in 2025?
        nawgz 1y ago
        Honestly, if you’re getting thru life with this attitude, good for you, but you might want to consider if it’s the only way
        the_gipsy 1y ago
        I'm doing fine, thank you. Perhaps you didn't understand what I said. My best ballpark guess for global redux usage in react projects is between 25% and at best 50% if you include redux/TEA-like libraries, but not non-pure usage. So yes, saying that react is `ui = f(state)` does everyone a disservice. It might be true for you, but it's probably not even the average.
        nawgz 1y ago
        Well, for anyone using Vue you get automatic observability baked in, right? And reactive programming state management libraries within react are plenty popular, not to mention the built in state management being quite literally UI = f(state). The fact people use the tortured disaster that is redux isn’t really a knock on react in any sane person’s view, we all know the JS community is full of beginners who don’t know better
fmbb 1y ago
React and Vue does not solve anything users expect.
JodieBenitez 1y ago
> The main problem is that the state of your frontend application is in the URL. There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL. It's not a black or white, one actually has to think about what the application must achieve. > modern UI where you might have many different zones, widgets, popups, etc. This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day. > React / Vue that all provide their version of a state store that can hold the state And many times they duplicate what's already available server-side.
- fvdessen 1y ago
  > There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL. > It's not a black or white, one actually has to think about what the application must achieve. You are explaining quite well why it's hard to manage the state in a htmx app. As your app grows up all this mumbo jumbo of url, session cookies, cookies, database models becomes tangled spaghetti. You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
  - JodieBenitez 1y ago
    > You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks. Well... I don't know what to say. What you call complexity is what I consider web development 101 really. And it is well worth the price: Better user experience, better performance, less code, better adherence to standards, easier app maintenance and more. But what did I expect ? These days web developers resort to gigantic dependencies list for the most basic things.
vb-8448 1y ago
maybe for very complex use cases, but I'm using htmx(and unpoly) + alpinejs + localstorage and still didn't find a case that doesn't fit.
andersmurphy 1y ago
Hypermedia can do all of that fine. You don't need to stick it all in the url. Using simple session and cookie/tab id state can be shared and or isolated between tabs. Then just do a lookup in your backend database. Hypermedia is also way better for realtime and multiplayer. If anything where HTMX falls short is it doesn't put enough state on the backend, if anything it's not radical enough.
- b_e_n_t_o_n 1y ago
  You mean I should be storing the state of a popup menu in my database?
  - andersmurphy 1y ago
    Correct. That's literally what happens with the scroll position, and share modal in this demo (QR code is generated on the fly on the backend): https://checkboxes.andersmurphy.com https://checkboxes.andersmurphy.com
    - julianz 1y ago
      300ms of latency to click a checkbox is a horrible experience, though.
      - christoff12 1y ago
        not really in this case
      - andersmurphy 1y ago
        Feels surprisingly good to me.
    - andersmurphy 1y ago
      Not sure why this is getting downvoted. I'm literally showing an example of storing popup state in the database as per the parents question. > You mean I should be storing the state of a popup menu in my database?
skeezyjefferson 1y ago
have you tried a native language with a networking and gui library to achieve the same thing?
the_gipsy 1y ago
> This problem is trivially solved by React / Vue that all provide their version of a state store that can hold the state What exactly are you talking about, for React? What provides "a state store"?

mervz 1y ago

It's a dead end for your use case, let's be very clear about that. And it's funny that you think anything about React and/or Vue is 'trivial'.

nawgz 1y ago
Surely you’re not saying the frameworks famous for ui = f(state) actually suck at managing state…
- jaredcwhite 1y ago
  kinda does, tbh.
- the_gipsy 1y ago
  If it only were true. React is nothing like ui = f(state). More like ui = f(some_trivial_state) + lifecycles magic + probably global_state. Garbage. But effective devrel.
  - nawgz 1y ago
    This type of dismissive attitude is so strange to me. The only reason "lifecycles magic + probably global_state" would be causing your app to behave unpredictably is - this is going to shock you - because you closed your mind to a tool by dismissing it as garbage before you used it, and then failed to use it properly because you think its popularity boils down to PR. For instance, you could entirely forgo the influence of lifecycles and global state by putting everything in a top-level Context with 1 state object that you only ever update by calling `setState`. After that, you might find reasons to optimize your app, which could lead you to more interesting approaches like reducers or state management libraries or memoization, but I'm guessing you would never get that far and just go back to what you were doing before, since YOUR preferences are battle hardened and reliable software, while things you don't know about are only popular because of Facebook. Obviously.
    - the_gipsy 1y ago
      So, redux? It's either redux or, sorry, "lifecycles magic + probably global_state". And who uses redux in 2025?
      - nawgz 1y ago
        Honestly, if you’re getting thru life with this attitude, good for you, but you might want to consider if it’s the only way
        the_gipsy 1y ago
        I'm doing fine, thank you. Perhaps you didn't understand what I said. My best ballpark guess for global redux usage in react projects is between 25% and at best 50% if you include redux/TEA-like libraries, but not non-pure usage. So yes, saying that react is `ui = f(state)` does everyone a disservice. It might be true for you, but it's probably not even the average.
        nawgz 1y ago
        Well, for anyone using Vue you get automatic observability baked in, right? And reactive programming state management libraries within react are plenty popular, not to mention the built in state management being quite literally UI = f(state). The fact people use the tortured disaster that is redux isn’t really a knock on react in any sane person’s view, we all know the JS community is full of beginners who don’t know better

fmbb 1y ago

React and Vue does not solve anything users expect.

JodieBenitez 1y ago

> The main problem is that the state of your frontend application is in the URL. There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL. It's not a black or white, one actually has to think about what the application must achieve. > modern UI where you might have many different zones, widgets, popups, etc. This is completely independent from the HTMX matter, but not all your application functionality has to fit one screen / one URL. There's a thin line between "modern" and bloat. Unfortunately this line is crossed every day. > React / Vue that all provide their version of a state store that can hold the state And many times they duplicate what's already available server-side.

fvdessen 1y ago
> There are plenty of ways to maintain state, including server store, sessions, localstorage, cookies, etc. Say you want the user to be able to customize the app layout: that doesn't need to be in the URL. Now say you provide a search functionality where the user can share the results: now your search criterias definitely should be in the URL. > It's not a black or white, one actually has to think about what the application must achieve. You are explaining quite well why it's hard to manage the state in a htmx app. As your app grows up all this mumbo jumbo of url, session cookies, cookies, database models becomes tangled spaghetti. You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks.
- JodieBenitez 1y ago
  > You don't have to do any of this in a Vue / React app, and that reduction of complexity alone is worth the weight of those frameworks. Well... I don't know what to say. What you call complexity is what I consider web development 101 really. And it is well worth the price: Better user experience, better performance, less code, better adherence to standards, easier app maintenance and more. But what did I expect ? These days web developers resort to gigantic dependencies list for the most basic things.

vb-8448 1y ago

maybe for very complex use cases, but I'm using htmx(and unpoly) + alpinejs + localstorage and still didn't find a case that doesn't fit.

andersmurphy 1y ago

Hypermedia can do all of that fine. You don't need to stick it all in the url. Using simple session and cookie/tab id state can be shared and or isolated between tabs. Then just do a lookup in your backend database. Hypermedia is also way better for realtime and multiplayer. If anything where HTMX falls short is it doesn't put enough state on the backend, if anything it's not radical enough.

b_e_n_t_o_n 1y ago
You mean I should be storing the state of a popup menu in my database?
- andersmurphy 1y ago
  Correct. That's literally what happens with the scroll position, and share modal in this demo (QR code is generated on the fly on the backend): https://checkboxes.andersmurphy.com https://checkboxes.andersmurphy.com
  - julianz 1y ago
    300ms of latency to click a checkbox is a horrible experience, though.
    - christoff12 1y ago
      not really in this case
    - andersmurphy 1y ago
      Feels surprisingly good to me.
  - andersmurphy 1y ago
    Not sure why this is getting downvoted. I'm literally showing an example of storing popup state in the database as per the parents question. > You mean I should be storing the state of a popup menu in my database?

skeezyjefferson 1y ago

have you tried a native language with a networking and gui library to achieve the same thing?

the_gipsy 1y ago

> This problem is trivially solved by React / Vue that all provide their version of a state store that can hold the state What exactly are you talking about, for React? What provides "a state store"?