We built a big app on htmx. Then we needed islands.
Why we picked htmx Before I get into what broke, it is worth saying why we picked htmx in the first place, because I still think the choice was right. Our app is a domain-driven monolith. Submissio...

Source: DEV Community
Why we picked htmx Before I get into what broke, it is worth saying why we picked htmx in the first place, because I still think the choice was right. Our app is a domain-driven monolith. Submissions, policies, parties, parameters. Each aggregate has routes that render representations of itself, and when the user acts on a thing, the server decides what the thing should look like next. The client does not need to know the state machine of a submission. The server just tells it. That is HATEOAS, and it is not a gimmick: it is the natural fit for a DDD app where the server is the source of truth. Moving that state machine into a client store would have meant duplicating a model we already had and paying a "keep the client model in sync with the server model" tax on every feature, forever. htmx also gave us end-to-end type safety for free. Our server renders typed JSX against our domain models, and the browser consumes whatever comes back. There is no API contract, no OpenAPI generator, n