Interesting claim here about engineering org dysfunction:<p>> 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.<p>> Short-term this means that all changes incur extra cost due to context switching and collaboration overhead between FE / BE dev<p>> 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.<p>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.<p>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.<p>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.<p>(Just to be clear, I think Htmx is great still.)
I'm not a web dev so my knowledge is limited here.<p>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?<p>Is it just BE templates?