4 ms·

I read through this and I don't get it. Recreating an entire form on the backend and swapping it with the current one, and then missing the update of the label

I read through this and I don't get it. Recreating an entire form on the backend and swapping it with the current one, and then missing the update of the label status? Then solving this by recreating the entire stepper html at each step, with the added complexity that if it contains something you want to keep "it's a nightmare"? Then having to create a temporary server-side session to store data that somehow the browser can't keep between two clicks? Etc.. it's write web apps like it's 1999.

junon 1y ago
Also the title itself does a disservice to HTMX; wasn't it billed as sort of "modern frameworks are bloated and difficult, let's go back to Simple"?
- fvdessen 1y ago
  HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either. After a decade of frontend dev and being tired of react/vue/etc, I tried HTMX, wanting for something leaner, but IMHO it has big problems, and I am back to react/vue. The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare. The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess. The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
  - bookofcooks 1y ago
    Yes, this was what I wanted to get across with the article (although I utterly failed to do so). I think I would stick to HTMX for other reasons (which I've made clear in my top-level comment on this thread), but I now I see it an occasional tool to use for something simple and not long-term. > The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare. Or you can create a large session object (which stores all the state) on the server, and have a sessionId in the URL (although I'd prefer a cookie) to associate the user with that large session object.
    - deleted 1y ago
      [deleted]
  - jgalt212 1y ago
    Server side rendering requires JavaScript on the server. So then you very often, but not always, violate "the clean and unbreakable separation of the back and front."
    - colejohnson66 1y ago
      Not necessarily JavaScript, but some kind of rendering or templating engine. As shown in the blog post, Go works.
      - jgalt212 1y ago
        right, but the person I was responding to mentioned JavaScript frameworks. > Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
  - withinboredom 1y ago
    > you need to put the whole app state in the URL and that quickly becomes a nightmare. You should be doing this anyway ... it's so annoying when my wife sends me a link at work and it just goes to a generic page instead of the search results she wanted to share with me. She ends up mostly sending me screenshots these days because sharing links don't work.
    - Cthulhu_ 1y ago
      Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state).
      - foobarbecue 1y ago
        Presumably you mean search query input, not search results, right?
        LeFantome 1y ago
        I think you are saying the same thing. They mean that their wife is trying to send them search results. You are pointing out that the link would contain the search query.
        foobarbecue 1y ago
        Not really same thing. If you share the search query, you'll be re-submitting the query at a later time, so the results are likely to be different when the receiver uses that URL. It would be possible (but pretty terrible) to embed the actual search results in the url. A more reasonable implementation of sharing search results would be to store results on the server and have a storedResults id key in the url.
      - PaulHoule 1y ago
        You have choices, especially all the choices that 1999-style web applications have. The shopping cart can be kept on the back end and referenced by an id stored in a cookie. You can keep partially filled out forms in hidden form variables and can send them back in either GET or POST. Not all requests require all the form data, for instance my RSS reader YOShInOn is HTMX based -- you can see two forms from it here: https://mastodon.social/@UP8/114887102728039235 https://mastodon.social/@UP8/114887102728039235 in the one at the upper left there is a main form where you can view one item and evaluate it which involves POSTing a form with hidden input fields but above that I can change the judgements of the past five items by just flipping one of the <selects> which needs to only submit the id and the judgement selected in the select. I guess on clicking one of the buttons in the bottom section I could redraw the the bottom section, insert a <select> row at the bottom of the list and the delete the one at the top, but it just redraws the whole form which is OK because I don't have 200k worth of open graph and other meta data in the <head> and endless <script> tags and any CSS other than bootstrap and maybe 5k of my own, which all caches properly.
  - chrisandchris 1y ago
    > HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either. Then it is not simple (as in simple I understand it) it's just the same we already have, reinvented. If it would be simple and lean, it would solve the most common problems by itself (like I don't need to care about the HTTP part in .Net - it's a one liner and the framework solves it for me).
  - mpweiher 1y ago
    > The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. Yeah, that also bothered me. To me it looks like the page (template) should fetch that partial from the same endpoint that will deliver the partial via the wire to HTMX.
    - L3viathan 1y ago
      You can do that if you want to. It'll just be slower.
      - mpweiher 1y ago
        Will it? I haven't gotten around to it yet, but my plan is to use in-process REST with Objective-S, so that accessing the internal endpoint will be the cost of a function call. The HTTP wrapper for external access is generic.
  - nsonha 1y ago
    > HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple I think it should be obvious that if a software is easy and convenient to the author to write (simple and lean), then the complexity falls onto the users.
imtringued 1y ago
What the author of this blog is doing is essentially server side react, but without the VDOM diffing. If there was DOM based diffing, then the only things that would change are a bunch of class attributes that affect which step becomes visible. To avoid the cost of updating the entire page, htmx only fetches a parent element and all of its children, but this runs into the problem that you must choose the common parent element for all the elements you want to update. So the author reaches the conclusion that htmx is not meant to be used for SPA style apps. It's meant to add a little bit of interactivity to otherwise static HTML.
- bookofcooks 1y ago
  > To avoid the cost of updating the entire page, htmx only fetches a parent element and all of its children, but this runs into the problem that you must choose the common parent element for all the elements you want to update. Not exactly, you can use Out-Of-Band updates, which means the server can arbitrarily choose to update specific elements outside the parent. > So the author reaches the conclusion that htmx is not meant to be used for SPA style apps. It's meant to add a little bit of interactivity to otherwise static HTML. Can you clarify where I seemed to have come to this conclusion, as this is not what I intended to express.
  - nsld 1y ago
    I think what OP mean to say is that he came to that conclusion. I did not draw that conclusion from reading the blog post. But rather that HTMX is a good tool, but it's not all sunshine and roses, some features takes some work to get working.
deleted 1y ago
[deleted]

junon 1y ago

Also the title itself does a disservice to HTMX; wasn't it billed as sort of "modern frameworks are bloated and difficult, let's go back to Simple"?

fvdessen 1y ago
HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either. After a decade of frontend dev and being tired of react/vue/etc, I tried HTMX, wanting for something leaner, but IMHO it has big problems, and I am back to react/vue. The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare. The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. You need a lot of discipline to prevent it from turning that into a mess. The final nail on the coffin for me was that the thing I wanted to avoid by picking HTMX; making a rest api to separate the frontend and the backend, was actually a good thing to have. After a while I was missing the clean and unbreakable separation of the back and front. Making the rest api was very quickly done, and the frontend was quicker to write as a result. So HTMX ended up slower than react / vue. Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
- bookofcooks 1y ago
  Yes, this was what I wanted to get across with the article (although I utterly failed to do so). I think I would stick to HTMX for other reasons (which I've made clear in my top-level comment on this thread), but I now I see it an occasional tool to use for something simple and not long-term. > The two biggest problems with HTMX is that being fully server side controlled you need to put the whole app state in the URL and that quickly becomes a nightmare. Or you can create a large session object (which stores all the state) on the server, and have a sessionId in the URL (although I'd prefer a cookie) to associate the user with that large session object.
  - deleted 1y ago
    [deleted]
- jgalt212 1y ago
  Server side rendering requires JavaScript on the server. So then you very often, but not always, violate "the clean and unbreakable separation of the back and front."
  - colejohnson66 1y ago
    Not necessarily JavaScript, but some kind of rendering or templating engine. As shown in the blog post, Go works.
    - jgalt212 1y ago
      right, but the person I was responding to mentioned JavaScript frameworks. > Nowadays react/vue provide server side rendering as well so i'm not sure what Htmx has to bring.
- withinboredom 1y ago
  > you need to put the whole app state in the URL and that quickly becomes a nightmare. You should be doing this anyway ... it's so annoying when my wife sends me a link at work and it just goes to a generic page instead of the search results she wanted to share with me. She ends up mostly sending me screenshots these days because sharing links don't work.
  - Cthulhu_ 1y ago
    Depends on what the commenter means by app state. Anything bookmarkable - like search results - should be in the URL, but "state" should not (I consider things like partially filled in forms, shopping carts, etc to be state).
    - foobarbecue 1y ago
      Presumably you mean search query input, not search results, right?
      - LeFantome 1y ago
        I think you are saying the same thing. They mean that their wife is trying to send them search results. You are pointing out that the link would contain the search query.
        foobarbecue 1y ago
        Not really same thing. If you share the search query, you'll be re-submitting the query at a later time, so the results are likely to be different when the receiver uses that URL. It would be possible (but pretty terrible) to embed the actual search results in the url. A more reasonable implementation of sharing search results would be to store results on the server and have a storedResults id key in the url.
    - PaulHoule 1y ago
      You have choices, especially all the choices that 1999-style web applications have. The shopping cart can be kept on the back end and referenced by an id stored in a cookie. You can keep partially filled out forms in hidden form variables and can send them back in either GET or POST. Not all requests require all the form data, for instance my RSS reader YOShInOn is HTMX based -- you can see two forms from it here: https://mastodon.social/@UP8/114887102728039235 https://mastodon.social/@UP8/114887102728039235 in the one at the upper left there is a main form where you can view one item and evaluate it which involves POSTing a form with hidden input fields but above that I can change the judgements of the past five items by just flipping one of the <selects> which needs to only submit the id and the judgement selected in the select. I guess on clicking one of the buttons in the bottom section I could redraw the the bottom section, insert a <select> row at the bottom of the list and the delete the one at the top, but it just redraws the whole form which is OK because I don't have 200k worth of open graph and other meta data in the <head> and endless <script> tags and any CSS other than bootstrap and maybe 5k of my own, which all caches properly.
- chrisandchris 1y ago
  > HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple either. Then it is not simple (as in simple I understand it) it's just the same we already have, reinvented. If it would be simple and lean, it would solve the most common problems by itself (like I don't need to care about the HTTP part in .Net - it's a one liner and the framework solves it for me).
- mpweiher 1y ago
  > The other is that the code of components is split in two, the part that is rendered on the first time, and the endpoint that returns the updated result. Yeah, that also bothered me. To me it looks like the page (template) should fetch that partial from the same endpoint that will deliver the partial via the wire to HTMX.
  - L3viathan 1y ago
    You can do that if you want to. It'll just be slower.
    - mpweiher 1y ago
      Will it? I haven't gotten around to it yet, but my plan is to use in-process REST with Objective-S, so that accessing the internal endpoint will be the cost of a function call. The HTTP wrapper for external access is generic.
- nsonha 1y ago
  > HTMX is indeed simple and lean, but unfortunately that doesn't mean solving common frontend problems with HTMX is simple I think it should be obvious that if a software is easy and convenient to the author to write (simple and lean), then the complexity falls onto the users.

imtringued 1y ago

What the author of this blog is doing is essentially server side react, but without the VDOM diffing. If there was DOM based diffing, then the only things that would change are a bunch of class attributes that affect which step becomes visible. To avoid the cost of updating the entire page, htmx only fetches a parent element and all of its children, but this runs into the problem that you must choose the common parent element for all the elements you want to update. So the author reaches the conclusion that htmx is not meant to be used for SPA style apps. It's meant to add a little bit of interactivity to otherwise static HTML.

bookofcooks 1y ago
> To avoid the cost of updating the entire page, htmx only fetches a parent element and all of its children, but this runs into the problem that you must choose the common parent element for all the elements you want to update. Not exactly, you can use Out-Of-Band updates, which means the server can arbitrarily choose to update specific elements outside the parent. > So the author reaches the conclusion that htmx is not meant to be used for SPA style apps. It's meant to add a little bit of interactivity to otherwise static HTML. Can you clarify where I seemed to have come to this conclusion, as this is not what I intended to express.
- nsld 1y ago
  I think what OP mean to say is that he came to that conclusion. I did not draw that conclusion from reading the blog post. But rather that HTMX is a good tool, but it's not all sunshine and roses, some features takes some work to get working.

deleted 1y ago

[deleted]