5 ms·

A technology like htmx seems to demand a “hypermedia” API. Whereas things like angular and react can consume a data API in many cases. However once an applicati

A technology like htmx seems to demand a “hypermedia” API. Whereas things like angular and react can consume a data API in many cases. However once an application becomes sufficiently complex people end up building data APIs just to suit their frontend framework. And in that case doing htmx and returning html seems nicer.

simonbarker87 3y ago
I've been building an app with HTMX over the past 6 months and this is the reason I am loving it. I don't even feel the backend/frontend interface, so rather than feeling like I am making the app twice (once in backend and again in the frontend to consume it) I am just making it once, there is no frontend, it's just all my app.
- joshmanders 3y ago
  Yep, same here. Now I think my actual API is better and less cumbersome because I'm not trying to fit my own UI needs into a general purpose JSON API meant to be consumed by 3rd party clients who want to do things on my app.
candiddevmike 3y ago
Seems like a ton of added complexity to avoid using JavaScript/a fat client
- infecto 3y ago
  Depends what you are trying to build. If you are building a complicated app that requires lots of states and you want it in the form of a SPA. Sure might be a bad fit. Lots of use cases could benefit from a hypermedia flow.
- Arch-TK 3y ago
  Doing htmx is just as simple as doing server side rendering. Yes you still have a javascript dependency but that's a lot simpler than a client side javascript framework for pulling data out of a data API and rendering it client side. I don't think anyone's complaint about server side rendering has ever been that it was too complex.
  - rtpg 3y ago
    The core thing is a lot of nice UX patterns are harder with server side rendering. Multi-page forms? Now you’re juggling around state. “Form has N rows”? Now that’s a thing. “Form has N heterogenous rows” is another thing. Then you get into things like how no server side rendering strategy has the equivalent to React “just write an inline helper function for this page”, so you need to create partials in files all over. And what if you’d like to statically verify that your templates have all the content in place? Proper typing? Who hasn’t had a page fall over because there was some missing context variable 3 layers deep. The thing with the API based flow and client side rendering (with React at least) when you have it set up nicely is “add a list view with pagination and search with a modal to create a resource if needed, and some inline editing” can be done by opening a single file and getting there with 2 dozen lines. Server side rendering strategies in practice tend to buckle a bit if you try to be modular enough, and in many cases you need to open one file per checklist on your project. Code locality issues are real IMO Disclaimer: I’ve done both, messing around with HTMX on a project and think it’s pretty cool. But it’s mainly because I don’t have all of the nice patterns from work projects that I’m tying this. If startup costs weren’t a thing I’d go with a client side system most days of the week.
    - halfcat 3y ago
      I wouldn’t say we’ve hit the center of the bullseye quite yet, still experimenting with the exact patterns of organizing and structuring a project using this approach. But so far we’ve landed on using the django-components library [1] to build something akin to Vue’s single file components. HTML, CSS, JavaScript, and Python “business logic”, all in one file. That component is then used in the Django templates, or in other component’s HTML, and it all seems to work very React-like in terms of an organized structure of composable components. Combined with HTMX the traditional SSR challenges you mention seem fairly straightforward to handle. > what if you’d like to statically verify that your templates have all the content in place? Proper typing? Can you say more about this? Would this be using TypeScript in React to verify types, or something more involved? I’m trying to understand this and what the equivalent might be in this “dynamic SSR” scenario. [1] https://github.com/EmilStenstrom/django-components https://github.com/EmilStenstrom/django-components
- folsom 3y ago
  I think the idea is that your hypermedia api and data api are not the same thing and the general shape of your data api should not be based on the needs of your front end.
- hipadev23 3y ago
  I’d argue javascript frameworks are a ton of added complexity. I send html, browser renders.
- halfcat 3y ago
  We have a team of Python devs who push data around and do analytics, reporting, etc They added real-time search results to our Django SSR site in 2 lines of HTMX. It’s the opposite of added complexity.
- gnaritas99 3y ago
  [dead]
- SrslyJosh 3y ago
  Not having to write your app a second time in javascript seems like less complexity to me. ¯\_(ツ)_/¯
- rchaud 3y ago
  I'd say this is a very useful library to have that provides a lot of React-like features without the overhead of a build step or frankly, needing to learn React on top of building the backend in some other language and framework. Compare the simplicity of 'hx-get' to the verbiage needed for a simple XHR request in vanilla JS, and the benefits become clear. IMO, it's a great option for rapid prototyping and for projects that can be done with whatever backend stack you already have.

simonbarker87 3y ago

I've been building an app with HTMX over the past 6 months and this is the reason I am loving it. I don't even feel the backend/frontend interface, so rather than feeling like I am making the app twice (once in backend and again in the frontend to consume it) I am just making it once, there is no frontend, it's just all my app.

joshmanders 3y ago
Yep, same here. Now I think my actual API is better and less cumbersome because I'm not trying to fit my own UI needs into a general purpose JSON API meant to be consumed by 3rd party clients who want to do things on my app.

candiddevmike 3y ago

Seems like a ton of added complexity to avoid using JavaScript/a fat client

infecto 3y ago
Depends what you are trying to build. If you are building a complicated app that requires lots of states and you want it in the form of a SPA. Sure might be a bad fit. Lots of use cases could benefit from a hypermedia flow.
Arch-TK 3y ago
Doing htmx is just as simple as doing server side rendering. Yes you still have a javascript dependency but that's a lot simpler than a client side javascript framework for pulling data out of a data API and rendering it client side. I don't think anyone's complaint about server side rendering has ever been that it was too complex.
- rtpg 3y ago
  The core thing is a lot of nice UX patterns are harder with server side rendering. Multi-page forms? Now you’re juggling around state. “Form has N rows”? Now that’s a thing. “Form has N heterogenous rows” is another thing. Then you get into things like how no server side rendering strategy has the equivalent to React “just write an inline helper function for this page”, so you need to create partials in files all over. And what if you’d like to statically verify that your templates have all the content in place? Proper typing? Who hasn’t had a page fall over because there was some missing context variable 3 layers deep. The thing with the API based flow and client side rendering (with React at least) when you have it set up nicely is “add a list view with pagination and search with a modal to create a resource if needed, and some inline editing” can be done by opening a single file and getting there with 2 dozen lines. Server side rendering strategies in practice tend to buckle a bit if you try to be modular enough, and in many cases you need to open one file per checklist on your project. Code locality issues are real IMO Disclaimer: I’ve done both, messing around with HTMX on a project and think it’s pretty cool. But it’s mainly because I don’t have all of the nice patterns from work projects that I’m tying this. If startup costs weren’t a thing I’d go with a client side system most days of the week.
  - halfcat 3y ago
    I wouldn’t say we’ve hit the center of the bullseye quite yet, still experimenting with the exact patterns of organizing and structuring a project using this approach. But so far we’ve landed on using the django-components library [1] to build something akin to Vue’s single file components. HTML, CSS, JavaScript, and Python “business logic”, all in one file. That component is then used in the Django templates, or in other component’s HTML, and it all seems to work very React-like in terms of an organized structure of composable components. Combined with HTMX the traditional SSR challenges you mention seem fairly straightforward to handle. > what if you’d like to statically verify that your templates have all the content in place? Proper typing? Can you say more about this? Would this be using TypeScript in React to verify types, or something more involved? I’m trying to understand this and what the equivalent might be in this “dynamic SSR” scenario. [1] https://github.com/EmilStenstrom/django-components https://github.com/EmilStenstrom/django-components
folsom 3y ago
I think the idea is that your hypermedia api and data api are not the same thing and the general shape of your data api should not be based on the needs of your front end.
hipadev23 3y ago
I’d argue javascript frameworks are a ton of added complexity. I send html, browser renders.
halfcat 3y ago
We have a team of Python devs who push data around and do analytics, reporting, etc They added real-time search results to our Django SSR site in 2 lines of HTMX. It’s the opposite of added complexity.
gnaritas99 3y ago
[dead]
SrslyJosh 3y ago
Not having to write your app a second time in javascript seems like less complexity to me. ¯\_(ツ)_/¯
rchaud 3y ago
I'd say this is a very useful library to have that provides a lot of React-like features without the overhead of a build step or frankly, needing to learn React on top of building the backend in some other language and framework. Compare the simplicity of 'hx-get' to the verbiage needed for a simple XHR request in vanilla JS, and the benefits become clear. IMO, it's a great option for rapid prototyping and for projects that can be done with whatever backend stack you already have.