5 ms·

I am using htmx. I still have a nagging feeling that this has mostly dragged the overton window back towards hypermedia (big fan of the book, recommended). It

by b33j0r 3y ago

I am using htmx. I still have a nagging feeling that this has mostly dragged the overton window back towards hypermedia (big fan of the book, recommended). It still feels wrong. I don’t know if I mean wrong as in “incorrect” or wrong as in “cheating/too easy.” It gracefully makes sites work like it’s 2025 or 1999, but I have to design my markup like it’s 1999. I can never decide if this is good or bad. My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. It’s like being 12 years old, and falling in love with a “bad girl” who doesn’t go to church—and never shows up to class—but makes you remember a lot of basic truths. Being less poetic. Installing python-multipart to do anything interactive with forms seems like a codesmell, but I don’t know what it is ;) EDIT: my final comment was not a diss on htmx obviously. But the idea of using browser-consumable response data after the success of computer-readable encodings for web apps (I guess I just mean hashmaps/dicts/json/object)

foul 3y ago
>My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. If you can query that client-side, you don't need an hypermedia client, you need an RPC client.
arethuza 3y ago
I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui
- k__ 3y ago
  Didn't GraphQL solve this issue already anyway?
  - fl0ki 3y ago
    How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.
  - b33j0r 3y ago
    Have you implemented it? The orm aspect is actually pretty weak. You end up implementing an RPC api anyway. And then you wonder how this was sold to you as declarative and idempotent. I exaggerate here because graphql does not solve the datalake problem. And it doesn’t do graphs (you can). The curb appeal looked super promising, but then it was just rpc with a bespoke ORM syntax.
- b33j0r 3y ago
  I mean, I’ve built both ways. The least productive thing I have seen from the debate involves two teams doing the same thing, but one team are python nerds making an API and the other are node nerds making an API. N’er the twain shall meet, right? I don’t mean to exaggerate, but your code will tend to mirror your organization structure. I have worked at companies where I thought our product was great because the API rocked. Then in my last 3 months I got to meet the frontend (definitely a jobsmell: not seeing the frontend every day.) Definitely misjudged the quality of our product, because apparently we wrote two different products (shrug) ;) Pretty strong argument for htmx, actually. But again, in a weird way where we fire the frontend and become actual full-stack engineers for everrrrything.
  - arethuza 3y ago
    https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
simonbarker87 3y ago
I started webdev in 2007, CodeIgniter, jQuery etc. Things were fun to build and fast to iterate. Deployment was a faff but you dealt with it. I was late to React (like 2020 late!) but have worked on three large (code base and requests) projects in React since then. Development was not fun, iteration was slow, but deployments were fast, yay for DevOps. I am now building an in house platform in HTMX and it’s wonderful. I get the fun and speed of the early days with the CI/CD we have now. The project I’ve built would already be a pain to deal with in React, instead it’s fast to load, has snappy interactions, has less code and is easy to extend. It feels like cheating, but only because React projects get so hard to work on.
- williamcotton 3y ago
  React isn’t the problem. Bad architecture is the problem, eg, making everything a reducer, no separation of concerns, etc. But yes, the generalized and popular React ecosystem is a mess.
  - andrekandre 3y ago
    > making everything a reducer just curiosity from someone whos not very experienced in react, but what are the problems with that?
    - selfmodruntime 3y ago
      Instead of living the basic react way and gathering state in one component and passing it down as a prop to a child, you feed it into a global "state store". The child component then requests the exact state they need from the state store. This also works reversed, instead of passing "setX" as a function to a child, you just rely on them to gather the state and pass it to the store. The thought behind this is that components live in pyramids, and state and props ideally only go down and rarely up by setters-> parents and their immediate children can easily share state and props. This gets more complicated the larger your family line gets. Many grandchildren down, you have since passed the respective props via prop drilling through a lot of components that perhaps don't care for them. It also gets complicated if you want to share state not in an immediate family line, but in a neighborhood. Overdoing it is almost like hoarding. You think "eh, maybe I need this later somewhere else) and suddenly, your entire application basically lives in the global store.
recursivedoubts 3y ago
> doubling my endpoints yep, and that's a good thing: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/mvc/ https://htmx.org/essays/mvc/
- dougbarrett 3y ago
  Plus, if you’re writing the front end in react or something else, that’s essentially the “other endpoint”. You’re just moving that back closer to the source of the origin.

by b33j0r 3y ago

foul 3y ago

>My projects all depend on an API for automation. So by buying into this doctrine, and rejecting even content negotiation, I am at least doubling my endpoints. If you can query that client-side, you don't need an hypermedia client, you need an RPC client.

arethuza 3y ago

I have seen people arguing that you shouldn't be using the same API endpoints for front-ends and for integration. I can see arguments both ways though... https://max.engineer/server-informed-ui https://max.engineer/server-informed-ui

k__ 3y ago
Didn't GraphQL solve this issue already anyway?
- fl0ki 3y ago
  How? GraphQL is just another way to make query API with structured output, almost always JSON in practice. If you wanted server-side rendering, you still need another endpoint even if it happens to use GraphQL internally, just like you could made a rendered endpoint using another form of API internally.
- b33j0r 3y ago
  Have you implemented it? The orm aspect is actually pretty weak. You end up implementing an RPC api anyway. And then you wonder how this was sold to you as declarative and idempotent. I exaggerate here because graphql does not solve the datalake problem. And it doesn’t do graphs (you can). The curb appeal looked super promising, but then it was just rpc with a bespoke ORM syntax.
b33j0r 3y ago
I mean, I’ve built both ways. The least productive thing I have seen from the debate involves two teams doing the same thing, but one team are python nerds making an API and the other are node nerds making an API. N’er the twain shall meet, right? I don’t mean to exaggerate, but your code will tend to mirror your organization structure. I have worked at companies where I thought our product was great because the API rocked. Then in my last 3 months I got to meet the frontend (definitely a jobsmell: not seeing the frontend every day.) Definitely misjudged the quality of our product, because apparently we wrote two different products (shrug) ;) Pretty strong argument for htmx, actually. But again, in a weird way where we fire the frontend and become actual full-stack engineers for everrrrything.
- arethuza 3y ago
  https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

simonbarker87 3y ago

I started webdev in 2007, CodeIgniter, jQuery etc. Things were fun to build and fast to iterate. Deployment was a faff but you dealt with it. I was late to React (like 2020 late!) but have worked on three large (code base and requests) projects in React since then. Development was not fun, iteration was slow, but deployments were fast, yay for DevOps. I am now building an in house platform in HTMX and it’s wonderful. I get the fun and speed of the early days with the CI/CD we have now. The project I’ve built would already be a pain to deal with in React, instead it’s fast to load, has snappy interactions, has less code and is easy to extend. It feels like cheating, but only because React projects get so hard to work on.

williamcotton 3y ago
React isn’t the problem. Bad architecture is the problem, eg, making everything a reducer, no separation of concerns, etc. But yes, the generalized and popular React ecosystem is a mess.
- andrekandre 3y ago
  > making everything a reducer just curiosity from someone whos not very experienced in react, but what are the problems with that?
  - selfmodruntime 3y ago
    Instead of living the basic react way and gathering state in one component and passing it down as a prop to a child, you feed it into a global "state store". The child component then requests the exact state they need from the state store. This also works reversed, instead of passing "setX" as a function to a child, you just rely on them to gather the state and pass it to the store. The thought behind this is that components live in pyramids, and state and props ideally only go down and rarely up by setters-> parents and their immediate children can easily share state and props. This gets more complicated the larger your family line gets. Many grandchildren down, you have since passed the respective props via prop drilling through a lot of components that perhaps don't care for them. It also gets complicated if you want to share state not in an immediate family line, but in a neighborhood. Overdoing it is almost like hoarding. You think "eh, maybe I need this later somewhere else) and suddenly, your entire application basically lives in the global store.

recursivedoubts 3y ago

> doubling my endpoints yep, and that's a good thing: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/mvc/ https://htmx.org/essays/mvc/

dougbarrett 3y ago
Plus, if you’re writing the front end in react or something else, that’s essentially the “other endpoint”. You’re just moving that back closer to the source of the origin.