Interesting claim here about engineering org dysfunction:
> FE code has gotten so complex that many orgs now have specialized positions - FE and BE. In practice this means that it's very hard for any one developer to get a fullstack change out.
> Short-term this means that all changes incur extra cost due to context switching and collaboration overhead between FE / BE dev
> Long-term this means a general architectural bias against doing things fullstack. Both sides will go to great lengths to not have to do things fullstack which often leads to suboptimal architectures throughout. This is how we got heavyweight client state management (Redux), interesting RPC protocols (GraphQL), and the push towards JS-only stacks (NextJS, Nuxt, SvelteKit, etc) - all methods to try and lower the pain of FE <> BE communication.
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.
> 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).
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.
I'm not a web dev so my knowledge is limited here.
What is the canonical way to do "components" with this htmx workflow though? How do you create an abstraction for a button, or a card, etc...
Do you just copy/paste the html all the time?
The same you always have? With HTML/CSS. Copy and paste sounds a bit derogatory, but it's pretty much what you're doing. You can also "templatize" things depending on your backend (card partial/template, etc).
What I like about my tech stack (go, tailwind, htmx, alpinejs) is the fact I can work entirely in HTML and Go. It keeps the work very focused and simple.
I render HTML from Go. I style it with Tailwind. If I remove styles from HTML then Tailwind culls the unused styles (I don't need to manage CSS). I use HTMX for some dynamic behavior (active search, lazy loading content/modals/slide overs/product details/etc). I use Alpine for client side state (drop downs, slide overs, toggles, etc).
> FE code has gotten so complex that many orgs now have specialized positions - FE and BE. In practice this means that it's very hard for any one developer to get a fullstack change out.
> Short-term this means that all changes incur extra cost due to context switching and collaboration overhead between FE / BE dev
> Long-term this means a general architectural bias against doing things fullstack. Both sides will go to great lengths to not have to do things fullstack which often leads to suboptimal architectures throughout. This is how we got heavyweight client state management (Redux), interesting RPC protocols (GraphQL), and the push towards JS-only stacks (NextJS, Nuxt, SvelteKit, etc) - all methods to try and lower the pain of FE <> BE communication.