6 ms·

I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type

I’ve been using htmx for over a year now for our internal management application (order monitoring, partner management, CAD model uploading and management type stuff) and I continue to be delighted at how quickly I can add features and iterate existing ones. I write way less client side JS, the app is very fast and responsive and I don’t have to write the app twice like with a SPA + API.

meowtimemania 2y ago
I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.
- synergy20 2y ago
  i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.
- taberiand 2y ago
  I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
  - aurareturn 2y ago
    So why complicate things and just use something like React + Next.js, which is already designed for complex apps?
    - emseetech 2y ago
      Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
      - kaoD 2y ago
        Web components are the stuff that nightmares are made of. The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way. The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic. Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app. Overall not a great experience for user-facing apps.
        emseetech 2y ago
        | Web components are the stuff that nightmares are made of. There's lit.dev for an easier approach. https://lit.dev https://lit.dev
        kaoD 2y ago
        But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities. At that point why not just use React? What do I get from using Lit instead?
        emseetech 2y ago
        I don't personally mind writing web components by hand, but for those who want something easier, lit.dev is popular. There's also slim.js and Stencil if you don't mind a compile step. The design of web components could be better, but I much prefer them to the true nightmare that React development has become. And the api is stable, which means a longevity that frameworks don't have. | no SSR nor progressive enhancement I have not been impressed by React SSR in the wild in terms of progressive enhancement. This seems like more of marketing promise than a real world experience. Do you have any examples to link?
    - taberiand 2y ago
      I've used both and I prefer the htmx approach. React/NextJS are what over-complicate things - particularly when it comes to server vs client side rendering and hydration, state management, passing props, caching, static site generation, slow and fragile development environment etc etc etc. I recently rewrote a site that was built in NextJS into Go+Echo+Templ+HTMX+AlpineJS, keeping just the Google Maps and Facebook components (but only injected as necessary, rather than needing a whole App wrapped around them) The result was about 50% of the size of code that is much easier to reason about and test, better performance, simpler and smaller (size and resource) deployment - essentially better in every way.
- emseetech 2y ago
  UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind. Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard. We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.
rtpg 2y ago
One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times). With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?
- BeefySwain 2y ago
  Check these out and see if they provide any insight for your specific issues :) - https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ - https://htmx.org/essays/10-tips-for-ssr-hda-apps/ https://htmx.org/essays/10-tips-for-ssr-hda-apps/
- djbusby 2y ago
  I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
  - hyperdang 2y ago
    [flagged]
    - esaym 2y ago
      rofl
  - hyperdang 2y ago
    [flagged]
  - librasteve 2y ago
    this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites
zerr 2y ago
For such an internal web app, why not do it in a fully traditional/multi-page/server-rendered manner?
- simonbarker87 2y ago
  I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA. Plus I wanted an excuse to use htmx.

meowtimemania 2y ago

I love htmx for internal dashboards. I find htmx difficult to use for user facing applications because it's difficult to get everyone on board with the constraints of htmx (no optimistic uis, simple ui/ux). When building complicated frontends with lots of popovers, modals, optimistic state, I like react.

synergy20 2y ago
i used it for simple dashboard, worked well but for complex projects it leads to spaghetti code for me, I had to stick to react for that.
taberiand 2y ago
I don't think htmx should be used on its own when implementing ui/ux - htmx has the job of getting the blocks of html, with data embedded, from the back-end to the front-end (and posting back up as necessary); once it's there, front-end client-only ui/ux can be handled by other tools in JavaScript
- aurareturn 2y ago
  So why complicate things and just use something like React + Next.js, which is already designed for complex apps?
  - emseetech 2y ago
    Alternatively, use web components which are baked into the browser, don't require a compile step, integrate well with HTMX and are much more stable than React.
    - kaoD 2y ago
      Web components are the stuff that nightmares are made of. The amount of boilerplate I had to write just to keep DOM attributes and JS properties in sync was not fun, the impedance mismatch between them (DOM attributes being strings) was painful to deal with, and templates/slots felt much worse than the React way. The DOM didn't seem like a great model for moderately complex apps. Feels like web components didn't take off for a reason. IMO they feel like the solution you come up with when you create an abstraction in paper instead of writing a real-world thing that will solve your immediate problems. Not very pragmatic. Plus they only work with JS enabled, unlike React+SSR where you can progressively enhance your app. Overall not a great experience for user-facing apps.
      - emseetech 2y ago
        | Web components are the stuff that nightmares are made of. There's lit.dev for an easier approach. https://lit.dev https://lit.dev
        kaoD 2y ago
        But that's yet-another-layer-of-abstraction with its own set of tradeoffs (e.g. I think CSS-in-JS is a trap, which seems to be the way for Lit; slots are still a thing; no SSR nor progressive enhancement; decorators!?!?!; etc.) which builds on top of what already feels like the wrong abstraction in the first place, only to provide React-like capabilities. At that point why not just use React? What do I get from using Lit instead?
        emseetech 2y ago
        I don't personally mind writing web components by hand, but for those who want something easier, lit.dev is popular. There's also slim.js and Stencil if you don't mind a compile step. The design of web components could be better, but I much prefer them to the true nightmare that React development has become. And the api is stable, which means a longevity that frameworks don't have. | no SSR nor progressive enhancement I have not been impressed by React SSR in the wild in terms of progressive enhancement. This seems like more of marketing promise than a real world experience. Do you have any examples to link?
  - taberiand 2y ago
    I've used both and I prefer the htmx approach. React/NextJS are what over-complicate things - particularly when it comes to server vs client side rendering and hydration, state management, passing props, caching, static site generation, slow and fragile development environment etc etc etc. I recently rewrote a site that was built in NextJS into Go+Echo+Templ+HTMX+AlpineJS, keeping just the Google Maps and Facebook components (but only injected as necessary, rather than needing a whole App wrapped around them) The result was about 50% of the size of code that is much easier to reason about and test, better performance, simpler and smaller (size and resource) deployment - essentially better in every way.
emseetech 2y ago
UX designers are immersed in this world of React and frontend frameworks, so their designs are built with that in mind. Doing things the "htmx way" on a team requires buy-in from more than just devs and that can be hard. We should be careful not to push htmx too past what it was meant for, as well. I remember how much I admired React when it was released for its simplicity.

rtpg 2y ago

One thing I've been struggling with using HTMX... with an app and a frontend REST API I've found I can really kinda quickly craft a frontend by filtering down whatever resources I need (though it's honestly pretty wasteful at times). With HTMX I'm finding myself needing to have as many backend views as I have ways of interacting with a page. I still have to write the frontend, and on top of that I gotta make a bunch of one-off backend views for many interactions. What am I doing wrong?

BeefySwain 2y ago
Check these out and see if they provide any insight for your specific issues :) - https://htmx.org/essays/template-fragments/ https://htmx.org/essays/template-fragments/ - https://htmx.org/essays/10-tips-for-ssr-hda-apps/ https://htmx.org/essays/10-tips-for-ssr-hda-apps/
djbusby 2y ago
I make htmx sites built around view fragments rather than pages. And when I need a page it's just a set of fragments. I make "API" endpoints fir the needed fragments and call via ssr on first paint, then as needed from the htmx side.
- hyperdang 2y ago
  [flagged]
  - esaym 2y ago
    rofl
- hyperdang 2y ago
  [flagged]
- librasteve 2y ago
  this is my medium term intent with HTMX & Raku ... I have in mind a programmatic / functional style of building websites where I can compose whole pages and sites

zerr 2y ago

For such an internal web app, why not do it in a fully traditional/multi-page/server-rendered manner?

simonbarker87 2y ago
I guess I could have done but the server was initially set up to respond with JSON and then the pages aspect got added in later and it felt easier to boot in htmx and bolt in the partials system and keep the json endpoints that are still needed than rearchitect for a proper MPA. Plus I wanted an excuse to use htmx.