4 ms·

I would say that it misses one of the main drawback of using Htmx: it does not force you to create a proper API. When you create a standard single page applica

by lelag 2y ago

I would say that it misses one of the main drawback of using Htmx: it does not force you to create a proper API. When you create a standard single page application, you generally start by building a JSON API on the server side, and a client application that can consumme that API. Htmx server code is different as it just returns HTML code to be inserted back in the page. So while, writing an app with Htmx is very easy for that very reason, you will likely not build a proper public API while you build your app and the day that you realise you need one, you have to write it from scratch. If you know you will need to provide a good public API, building it from the get go and a React/Angular app on top might still be worth it. (Just to be clear, I think Htmx is great still.)

MilStdJunkie 2y ago
HTMX is sort of like a spiritual grandchild of 1990s stuff like CFML, at least conceptually, anyway. That's pretty cool. And maybe instructive, to look at what brought down systems like that, way back in the day. I'm a flunkie from the caverns of the military industrial complex, but I'm also poking my head aboveground and going through some of my buddies' modern doc projects (along with the git history, issues, all the Swagger stuff [which I like!]). All in a (probably futile) attempt to be employable outside my industry. Anyway, I came away with this nagging sensation that the API is where the actual architecture work takes place. It's almost certainly a wrong impression - this is not my world - but I'm having a hard time seeing what keeps things on the rails aside from the API process. I'm getting a whiff of that from the OP article too. I am betting that better managed projects have a whole layer specialized for architecture, instead of shoving that work down for the API docs to figure out. Nothing as stupid as what we got in our business - "fifty different architectures in a hundred different places each of which costs millions of dollars" - but a place where it theoretically happens.
sebazzz 2y ago
> If you know you will need to provide a good public API, building it from the get go and a React/Angular app on top might still be worth it. That is a different point than you made earlier in your comment though. That you start building an API on the server side does not mean you’re creating a good, well-balanced, API suitable for public consumption (being consumption in other teams or even other companies).
vlucas 2y ago
This is actually a feature. A good API for public consumption is a specific thing to build with intentionality. If your tech stack forces you to build an API in order to put a basic webpage together and handle form data, that is the red flag.
recursivedoubts 2y ago
https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/

by lelag 2y ago

MilStdJunkie 2y ago

HTMX is sort of like a spiritual grandchild of 1990s stuff like CFML, at least conceptually, anyway. That's pretty cool. And maybe instructive, to look at what brought down systems like that, way back in the day. I'm a flunkie from the caverns of the military industrial complex, but I'm also poking my head aboveground and going through some of my buddies' modern doc projects (along with the git history, issues, all the Swagger stuff [which I like!]). All in a (probably futile) attempt to be employable outside my industry. Anyway, I came away with this nagging sensation that the API is where the actual architecture work takes place. It's almost certainly a wrong impression - this is not my world - but I'm having a hard time seeing what keeps things on the rails aside from the API process. I'm getting a whiff of that from the OP article too. I am betting that better managed projects have a whole layer specialized for architecture, instead of shoving that work down for the API docs to figure out. Nothing as stupid as what we got in our business - "fifty different architectures in a hundred different places each of which costs millions of dollars" - but a place where it theoretically happens.

sebazzz 2y ago

> If you know you will need to provide a good public API, building it from the get go and a React/Angular app on top might still be worth it. That is a different point than you made earlier in your comment though. That you start building an API on the server side does not mean you’re creating a good, well-balanced, API suitable for public consumption (being consumption in other teams or even other companies).

vlucas 2y ago

This is actually a feature. A good API for public consumption is a specific thing to build with intentionality. If your tech stack forces you to build an API in order to put a basic webpage together and handle form data, that is the red flag.

recursivedoubts 2y ago

https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/