6 ms·

Can I ask you how long you have been using this stack for and what are your findings ? Do you have a complex UI heavy application and can you deterministically

Can I ask you how long you have been using this stack for and what are your findings ? Do you have a complex UI heavy application and can you deterministically say that this stack can replace frameworks like React/Vue for JS heavy frontend ? Is HTMX really mature and stable for production and massive UI heavy apps ? I am asking because we are starting a big project in Django, Postgres, Tailwind and for frontend, still trying to use VueJS and we hate SPAs so curious what our options are.

deleted 4y ago
[deleted]
Quekid5 4y ago
Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend. I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced" in the positive sense. It keeps you honest.)
- fatboy 4y ago
  Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start. I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.
  - Quekid5 4y ago
    The only real advice I can offer is: Try to implement an example of the most complicated UI interaction that you have in your (conceptual) application in both and then decide. Development-by-random-recommendation is usually a recipe for disaster.
    - fatboy 4y ago
      That is sound advice and I take it to heart. I was mainly wondering if you'd hit any roadblocks whose existence might not have been obvious from the outset?
      - Quekid5 4y ago
        Nothing in particular that I wouldn't have predicted (from a detailed reading of the tech). I guess one thing to always keep in mind that these are frameworks that are limited by the client<->server interaction as a critical path. If you're doing a full SPA-type-thing you have to option to do optimistic updates and that sort of thing, but IME that's advanced stuff that only major orgs should even attempt to do.
    - pbowyer 4y ago
      This is the best advice in the entire discussion. Everyone's definition of 'complicated UI' is different, as is the amount of reactivity you have in your app (e.g. when this data changes, what else in the UI needs to change?). There is one caution I will give: try and predict where you will be in 2-5 years. 5 years ago I built an app with complicated screens server-rendered with a smattering of Vue to enhance them. We are now moving more and more of the screen into Vue because the reactivity has increased. It would've been better to decide to build _this section of the app_ in Vue from the start, though situational constraints (aka the budget) would have prevented us from doing so anyhow.
    - techdragon 4y ago
      For extra credit look for places in your UI where you need to work with as much data as possible from as many different places as possible. One of places that justifies heavier front end frameworks and SPAs is when you can precompute things on the client side that make it more performant. Things like efficient updates of large tables of data in the browser that was constructed out of multiple database tables… things like order + shipping status + customer shipping address… lots of day to day business stuff is like this and while you can manage to do it with just HTML and forms with or without JavaScript … it’s very easy to fall into performance traps between big form data submissions, potentially tricky JavaScript loops to shrink the data submission and backend N+1 query updates… it gets pretty tricky sometimes. The point is the most complicated part of your UI may not be the most visually complex part. It can be just a simple data grid or html table… it can be the intersex of your requirements around the data being handled, the workflow/interactions on the data, and the performance/usability requirements of the users (offline editing + sync on reconnect basically requires a SPA)
  - dsego 4y ago
    Have you considered https://inertiajs.com https://inertiajs.com? It's still SPA-ish, but keeps server-side routing and controllers. To me it sort of looks like templates rendered in the browser with almost no need to keep state and juggle xhr calls, the app component just re-renders with new props whenever something is submitted to the server.
    - cooperadymas 4y ago
      This comment chain: "HTMX is great." "I'm burnt out on frontend frameworks. HTMX has been a good change to JS heavy alternatives." "Can you give more thoughts on it for heavy interactions?" "You might try LiveViewJS." "Can you tell me about your experience with LiveViewJS?" "Have you considered InertiaJS?" I have no intent here other than I found this circular chain amusing. Let it go on long enough and someone will without a doubt recommend HTMX as if it's something they don't expect the parent has heard of. Is it any wonder the OP was burnt out on web dev?
  - cmoski 4y ago
    Positive experience with Phoenix LiveView here. I don't know what you mean when you say heavily interactive but I've got: via JS hooks: drag and drop and charts; and hand built with live view: data tables with filter+sort, query builder and a simple report builder. It's pretty easy to hand off to JS when the need arises.
czx4f4bd 4y ago
https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV. https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx. If you hate SPAs and are chafing against Vue for building your app, it's probably worth considering if your app absolutely needs to be a JS/frontend-heavy product, or if it would be viable using a more traditional HTML+AJAX design.
- rgrieselhuber 4y ago
  After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.
  - papertokyo 4y ago
    SvelteKit just hit 1.0. Out of all the 'modern' meta frameworks, it's the one that feels most like just writing HTML.
    - pcthrowaway 4y ago
      I'm not sure why you're posting this on a thread about HTMX. HTMX is almost certainly more like "just writing HTML" Svelte lets you keep HTML, JS, and CSS all together, so that's nice, but it's typical use case involves writing a fair bit of Javascript/Typescript
  - stickfigure 4y ago
    Wait till you end up on a fever swamp project involving templated HTML generation. Or even a fever swamp project involving jQuery.
    - rgrieselhuber 4y ago
todotask 4y ago
Quasar framework seems to fit UI heavy and supported wide range of UI components. I have manage to integrate Tailwind.
ramraj07 4y ago
I default to using Vue.js imported via a script tag inside static html pages styled on bootstrap. It’s perfect for basic apps and you don’t really lose a lot on interactivity. Backend, current fav is FastAPI.

deleted 4y ago

[deleted]

Quekid5 4y ago

Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend. I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced" in the positive sense. It keeps you honest.)

fatboy 4y ago
Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start. I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.
- Quekid5 4y ago
  The only real advice I can offer is: Try to implement an example of the most complicated UI interaction that you have in your (conceptual) application in both and then decide. Development-by-random-recommendation is usually a recipe for disaster.
  - fatboy 4y ago
    That is sound advice and I take it to heart. I was mainly wondering if you'd hit any roadblocks whose existence might not have been obvious from the outset?
    - Quekid5 4y ago
      Nothing in particular that I wouldn't have predicted (from a detailed reading of the tech). I guess one thing to always keep in mind that these are frameworks that are limited by the client<->server interaction as a critical path. If you're doing a full SPA-type-thing you have to option to do optimistic updates and that sort of thing, but IME that's advanced stuff that only major orgs should even attempt to do.
  - pbowyer 4y ago
    This is the best advice in the entire discussion. Everyone's definition of 'complicated UI' is different, as is the amount of reactivity you have in your app (e.g. when this data changes, what else in the UI needs to change?). There is one caution I will give: try and predict where you will be in 2-5 years. 5 years ago I built an app with complicated screens server-rendered with a smattering of Vue to enhance them. We are now moving more and more of the screen into Vue because the reactivity has increased. It would've been better to decide to build _this section of the app_ in Vue from the start, though situational constraints (aka the budget) would have prevented us from doing so anyhow.
  - techdragon 4y ago
    For extra credit look for places in your UI where you need to work with as much data as possible from as many different places as possible. One of places that justifies heavier front end frameworks and SPAs is when you can precompute things on the client side that make it more performant. Things like efficient updates of large tables of data in the browser that was constructed out of multiple database tables… things like order + shipping status + customer shipping address… lots of day to day business stuff is like this and while you can manage to do it with just HTML and forms with or without JavaScript … it’s very easy to fall into performance traps between big form data submissions, potentially tricky JavaScript loops to shrink the data submission and backend N+1 query updates… it gets pretty tricky sometimes. The point is the most complicated part of your UI may not be the most visually complex part. It can be just a simple data grid or html table… it can be the intersex of your requirements around the data being handled, the workflow/interactions on the data, and the performance/usability requirements of the users (offline editing + sync on reconnect basically requires a SPA)
- dsego 4y ago
  Have you considered https://inertiajs.com https://inertiajs.com? It's still SPA-ish, but keeps server-side routing and controllers. To me it sort of looks like templates rendered in the browser with almost no need to keep state and juggle xhr calls, the app component just re-renders with new props whenever something is submitted to the server.
  - cooperadymas 4y ago
    This comment chain: "HTMX is great." "I'm burnt out on frontend frameworks. HTMX has been a good change to JS heavy alternatives." "Can you give more thoughts on it for heavy interactions?" "You might try LiveViewJS." "Can you tell me about your experience with LiveViewJS?" "Have you considered InertiaJS?" I have no intent here other than I found this circular chain amusing. Let it go on long enough and someone will without a doubt recommend HTMX as if it's something they don't expect the parent has heard of. Is it any wonder the OP was burnt out on web dev?
- cmoski 4y ago
  Positive experience with Phoenix LiveView here. I don't know what you mean when you say heavily interactive but I've got: via JS hooks: drag and drop and charts; and hand built with live view: data tables with filter+sort, query builder and a simple report builder. It's pretty easy to hand off to JS when the need arises.

czx4f4bd 4y ago

https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV. https://htmx.org/essays/a-real-world-react-to-htmx-port/ https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx. If you hate SPAs and are chafing against Vue for building your app, it's probably worth considering if your app absolutely needs to be a JS/frontend-heavy product, or if it would be viable using a more traditional HTML+AJAX design.

rgrieselhuber 4y ago
After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.
- papertokyo 4y ago
  SvelteKit just hit 1.0. Out of all the 'modern' meta frameworks, it's the one that feels most like just writing HTML.
  - pcthrowaway 4y ago
    I'm not sure why you're posting this on a thread about HTMX. HTMX is almost certainly more like "just writing HTML" Svelte lets you keep HTML, JS, and CSS all together, so that's nice, but it's typical use case involves writing a fair bit of Javascript/Typescript
- stickfigure 4y ago
  Wait till you end up on a fever swamp project involving templated HTML generation. Or even a fever swamp project involving jQuery.
  - rgrieselhuber 4y ago

todotask 4y ago

Quasar framework seems to fit UI heavy and supported wide range of UI components. I have manage to integrate Tailwind.

ramraj07 4y ago

I default to using Vue.js imported via a script tag inside static html pages styled on bootstrap. It’s perfect for basic apps and you don’t really lose a lot on interactivity. Backend, current fav is FastAPI.