5 ms·

We did this 20 years ago and you just end up with piles of unmaintainable partials all just used for a single page. It's far better to use something that at le

We did this 20 years ago and you just end up with piles of unmaintainable partials all just used for a single page. It's far better to use something that at least embeds the templates in the web page with some simple js to show it (eg alpinejs) and a simple, private API.

d-z-m 3y ago
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…
    - 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.
viraptor 3y ago
How does your solution fix the issue you described? You still need a pile of partials, they're just moving where they're rendered.
- nprateem 3y ago
  You only need partials for shared templates instead of multiple per action on a single page.
  - naasking 3y ago
    You don't need any partials at all, so this objection just doesn't apply. The server can return full pages and only parts of it are updated.
  - viraptor 3y ago
    Sorry, I don't get it. If you have client side rendering, you need a template for every thing you want to replace, at whatever level you choose (from full page to single element). If you do htmx, you do the same - provide a template for each replaceable part (from full page to single element). In each case, it's your choice how granular you want the updates to be - it can be one per action, or just rerendering the whole page. Why do you think the client side requires fewer partials, if you use the same scope of data changes?
  - brabel 3y ago
    With HTMX you shouldn't have a "template" per action. Most actions work on some "entity", and the "entity"'s page should be returned by the action, as it's very common for an action that change one bit of the "entity" to affect more than one part of the "entity" rendering. So you don't need one template per action, you need one template per entity, and different actions may replace the same entity. This is almost exactly what you would do in React, with "entities" being "components". I've designed a HTMX app this way and actually called the "templates" components. Each component is either a function or an actual (Kotlin) class with a render method. I can test the components in isolation, just like you can with JS frameworks, but all code is on the server - despite the app itself feeling just as reactive as any JS framework-based app.
fzumstein 3y ago
For the Python/Jinja world, there is Jinja2-fragments that allows you to return blocks of the template without having to extract it to partials. I am sure there are similar solutions for other template languages. See https://github.com/sponsfreixes/jinja2-fragments https://github.com/sponsfreixes/jinja2-fragments.
smallerfish 3y ago
Use a well organized hierarchy of components. You don't have to rely on a bunch of raw templates.

d-z-m 3y ago

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…
  - 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.

viraptor 3y ago

How does your solution fix the issue you described? You still need a pile of partials, they're just moving where they're rendered.

nprateem 3y ago
You only need partials for shared templates instead of multiple per action on a single page.
- naasking 3y ago
  You don't need any partials at all, so this objection just doesn't apply. The server can return full pages and only parts of it are updated.
- viraptor 3y ago
  Sorry, I don't get it. If you have client side rendering, you need a template for every thing you want to replace, at whatever level you choose (from full page to single element). If you do htmx, you do the same - provide a template for each replaceable part (from full page to single element). In each case, it's your choice how granular you want the updates to be - it can be one per action, or just rerendering the whole page. Why do you think the client side requires fewer partials, if you use the same scope of data changes?
- brabel 3y ago
  With HTMX you shouldn't have a "template" per action. Most actions work on some "entity", and the "entity"'s page should be returned by the action, as it's very common for an action that change one bit of the "entity" to affect more than one part of the "entity" rendering. So you don't need one template per action, you need one template per entity, and different actions may replace the same entity. This is almost exactly what you would do in React, with "entities" being "components". I've designed a HTMX app this way and actually called the "templates" components. Each component is either a function or an actual (Kotlin) class with a render method. I can test the components in isolation, just like you can with JS frameworks, but all code is on the server - despite the app itself feeling just as reactive as any JS framework-based app.

fzumstein 3y ago

For the Python/Jinja world, there is Jinja2-fragments that allows you to return blocks of the template without having to extract it to partials. I am sure there are similar solutions for other template languages. See https://github.com/sponsfreixes/jinja2-fragments https://github.com/sponsfreixes/jinja2-fragments.

smallerfish 3y ago

Use a well organized hierarchy of components. You don't have to rely on a bunch of raw templates.