4 ms·

what makes it unmaintainable in your opinion?

• gedy 3y ago
  Not OP but: spreading a UI amongst a bunch of files, which themselves have server side templating and logic in them and can't be run, imported, or tested in isolation. I was never a JS fanboy but the modern JS/TS frameworks that let you organize and test the UI without an entire system running is better for maintenance imho.
• halfcat 3y ago
  It’s unmaintainable when you don’t organize your endpoints well. Which is no different with React, or anything else. It’s a non-point.
  • nprateem 3y ago
    No it's a point because the number of endpoints and partials explodes to support every action in the page that uses the "get HTML and replace it" pattern.
    • mejutoco 3y ago
      Cant you type your partials in some way? I think for complicated things with htmx you need to write a thin layer to manage this explosion of templates.
      • nprateem 3y ago
        It's more just the fact that a single page gets unnecessarily split across multiple files (where there's no reuse with other pages). It makes refactoring difficult and slows development IME.
        • mejutoco 3y ago
          Having some sort of typing of tgese fragments would help finding all their uses and refactoring.
        • halfcat 3y ago
          How is this different from React? Every page in the app is made up of components from numerous other files. Do you think we have a bunch of HTML files spread out everywhere, and that we aren’t generating all of those endpoints automatically? We don’t even write 95% of the endpoints with HTMX. They’re generated from the ORM class. It was amusing when I heard about RSC, since we’d basically been doing that for years at that point, except in whatever language the backend team is already well versed in.
      • zarzavat 3y ago
        Isn’t that just pushing the complexity somewhere else? The selling point of HTMX is that it’s simple because you don’t need to deal with frameworks or JS, just write HTML! But if you have to start adding layers to support it then all that’s happening is the complexity is being moved out of the framework and into your code. Stone soup development…
        • mejutoco 3y ago
          I get what you mean, but for me the target is not deciding if htmx is up to x standard, but getting things done. Writing a thin layer as described above solves these issues for me.
          • halfcat 3y ago
            Yes. Writing a thin layer is a minor task, compared to say, introducing a client-side store and trying to manage all of the complexity of state synchronization. If I need to add one boolean variable to a page, in React/Vue land I need to update 7 files and create a mutator and a fetcher and an actor and a dispatcher. In HTMX land that one added variable requires editing, one file…
            • zarzavat 3y ago
              I don’t understand what HTMX has to do with state synchronization. If you want to implement a thin client authoritative server architecture in React (or another JS framework), you can just do it that way. React doesn’t have any opinion on how information flows between client and server. State in React is optional, you can do everything with props if you want to.
              • halfcat 3y ago
                You’re right. It can be done with React, if your team knows React. State was just an illustrative example that “writing a thin HTMX layer” is not necessarily a bigger lift than “just use a framework”. There’s a big gap between “write some small thing in PHP” or whatever your team knows, and “learn React well enough to do it the right way”. As the person I replied to said, it’s not about what’s possible. It’s about getting something done today.
    • hombre_fatal 3y ago
      Also, when your front-end html changes, any number of these partials might have to change. Versus just returning data (json) and letting the front-end render what it needs from it. The latter seems like an obvious ideal compared to the former.
    • halfcat 3y ago
      If you assume the people building the backend are incompetent, then I guess you have a point? We don’t write 95% of the endpoints. They’re auto generated. And this may be a shocking idea to you, but when we do need to build a custom endpoint, we still build it as a component (just like you would in React).
• nprateem 3y ago
  Because instead of needing separate partials for your inline edit template and all the other actions, you just stuff them into the page as hidden divs. This means you have a single template per page and only need to split out partials for things that are actually shared, rather than for every action on a single page.