4 ms·

I want to like - I feel like the frameworks are all too much ceremony now. You need to buy into a bunch of different build tools, a cli or two, and are left wo

I want to like - I feel like the frameworks are all too much ceremony now. You need to buy into a bunch of different build tools, a cli or two, and are left wondering "where is my app again?" I've tried htmx, though, and like the simplicity, but am not 100% sold. In the olden days, ASP.NET Web forms Ajax had "Update Panels", which were similar to this. You'd wrap a section of markup in an "Update Panel" and that made it refresh just that bit of the page while keeping the rest. The problem is your "api" then ended up being a bunch of pages that output html, and passing state was a huge problem. This seems better, but still similar concept. At the end of the day, I want my backend API to be restful json(or grpc, graphql) any client can consume. I want the client to be written with as few dependencies as possible. Maybe I'm misunderstanding though. Put another way: suppose I have an existing backend REST API where input/output is json. Can I use htmx without any changes to the api or server-side code to translate json to markup?

recursivedoubts 4y ago
Hypermedia APIs and JSON (Data) APIs are different. I have a few essays up on these differences here: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ Generally, I would recommend splitting your data and hypermedia APIs up, so you can take advantage of the features of hypermedia (the uniform interface) and still provide a good data API to clients that want it. Also, this is pedantic, but a graphql JSON API is almost certainly not REST-ful, in the original sense of that term: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ More essays and other silliness here: https://htmx.org/essays/ https://htmx.org/essays/
- bminor13 4y ago
  Question about this part of the hypermedia vs data APIs essay: "This new end point is driven entirely by hypermedia needs, not data model needs. This end point can go away if the hypermedia needs of the application change" Presumably these hypermedia endpoints are all equally accessible - couldn't the removal of one break another application if the latter app decided to depend on a particular hypermedia snippet from the first? If there are multiple teams in an org that own HTMX endpoints, aren't the set of endpoints effectively a sort of interface boundary? Or is there a good way of declaring certain endpoints "private" and ensuring they're only fetched from particular applications? (Maybe separate domains for every app?)
  - recursivedoubts 4y ago
    in the sense I'm using, an application is a single functional app: you wouldn't have two applications using a shared URL because that would break the uniform interface you might have two separate apps that maintain their own hypermedia APIs and that, on the server side, then share a data API between each other the idea is to take advantage of the uniform interface of a hypermedia APIs: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ but there is an assumption there that the server side gives a client a sensible representation of state
- TrickardRixx 4y ago
  I'm aware that I'm abusing the tool, but I wrote a htmx extension that overrides the mimetype and JSON encodes all the parameters. The JSON is decoded into a data bag on the back end. Basically I can do "fuck it over HTTP"[0] with needing close to zero JS. HTMX has been a god-send to me. [0]: https://twobithistory.org/2020/06/28/rest.html https://twobithistory.org/2020/06/28/rest.html I misremembered the name, it is actually "fuck it, overload http"
  - andy800 4y ago
    I did something similar, for a dashboard type of web app that involves a lot of graphs. JS graph APIs pretty much all expect data as JSON-formatted JS variables, not HTML. So I use HTMX to make the server requests, using triggers defined in HTMX, replacing a lot of JS code. It's really only with the JSON-based responses that I'm going rogue. HTMX is so elegant, I feel dirty going against the grain.
- shireboy 4y ago
  Thanks for the reply. I will have to give those essays some thought and revisit. I think some of it may boil down to the type of app, customer, etc. At first blush I’m hesitant to want two apis plus a client at least for my typical (admitedly smaller forms-on-data) type projects. But I do plan to revisit and see. The client template extension may be the gateway drug for me here. I certainly didn’t mean to imply REST = GraphQL = grpc. “Data api” vs “hypermedia api” is a distinction that makes sense to me.
decross 4y ago
the creator has already answered you, but I will add that there is an htmx extension called client-side-templates here: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/

recursivedoubts 4y ago

Hypermedia APIs and JSON (Data) APIs are different. I have a few essays up on these differences here: https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ Generally, I would recommend splitting your data and hypermedia APIs up, so you can take advantage of the features of hypermedia (the uniform interface) and still provide a good data API to clients that want it. Also, this is pedantic, but a graphql JSON API is almost certainly not REST-ful, in the original sense of that term: https://htmx.org/essays/how-did-rest-come-to-mean-the-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi... https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ More essays and other silliness here: https://htmx.org/essays/ https://htmx.org/essays/

bminor13 4y ago
Question about this part of the hypermedia vs data APIs essay: "This new end point is driven entirely by hypermedia needs, not data model needs. This end point can go away if the hypermedia needs of the application change" Presumably these hypermedia endpoints are all equally accessible - couldn't the removal of one break another application if the latter app decided to depend on a particular hypermedia snippet from the first? If there are multiple teams in an org that own HTMX endpoints, aren't the set of endpoints effectively a sort of interface boundary? Or is there a good way of declaring certain endpoints "private" and ensuring they're only fetched from particular applications? (Maybe separate domains for every app?)
- recursivedoubts 4y ago
  in the sense I'm using, an application is a single functional app: you wouldn't have two applications using a shared URL because that would break the uniform interface you might have two separate apps that maintain their own hypermedia APIs and that, on the server side, then share a data API between each other the idea is to take advantage of the uniform interface of a hypermedia APIs: https://htmx.org/essays/hateoas/ https://htmx.org/essays/hateoas/ but there is an assumption there that the server side gives a client a sensible representation of state
TrickardRixx 4y ago
I'm aware that I'm abusing the tool, but I wrote a htmx extension that overrides the mimetype and JSON encodes all the parameters. The JSON is decoded into a data bag on the back end. Basically I can do "fuck it over HTTP"[0] with needing close to zero JS. HTMX has been a god-send to me. [0]: https://twobithistory.org/2020/06/28/rest.html https://twobithistory.org/2020/06/28/rest.html I misremembered the name, it is actually "fuck it, overload http"
- andy800 4y ago
  I did something similar, for a dashboard type of web app that involves a lot of graphs. JS graph APIs pretty much all expect data as JSON-formatted JS variables, not HTML. So I use HTMX to make the server requests, using triggers defined in HTMX, replacing a lot of JS code. It's really only with the JSON-based responses that I'm going rogue. HTMX is so elegant, I feel dirty going against the grain.
shireboy 4y ago
Thanks for the reply. I will have to give those essays some thought and revisit. I think some of it may boil down to the type of app, customer, etc. At first blush I’m hesitant to want two apis plus a client at least for my typical (admitedly smaller forms-on-data) type projects. But I do plan to revisit and see. The client template extension may be the gateway drug for me here. I certainly didn’t mean to imply REST = GraphQL = grpc. “Data api” vs “hypermedia api” is a distinction that makes sense to me.

decross 4y ago

the creator has already answered you, but I will add that there is an htmx extension called client-side-templates here: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/