Solid breakdown. The fragment-based mental model really clarifies what HTMX is actualyy doing under the hood. I've been on projects where frontend state management became this tangled mess of reducers and effects, and seeing how server-rendered fragments sidestep that entirely is refreshing. The validation flow is especially clean, just return 422 with an error fragment and let HTMX handle placement.
I don't disagree that HTMX is perhaps a bit better here but isn't this just "JSP++" / Wicket / JSF / etc.? For years we've gone back and forth between server side rendering and totally separate SaaS type environments. With the complete separation I can hire a back end and a front end developer and, if I want it on the back end, I can have too many microservices or a monolith - it's up to me. Any time you pull in server side rendering you now have your rendering host and your API host as one. Either way, the rendering side certainly isn't a static website hosted on something like S3.
I do, however, appreciate the article as it gives me something to experiment with. I'm knee deep in React code and it doesn't feel right either so perhaps I'm too focused on the "separation of church and state" in my thinking. I will say that I'm not sure how HTMX is going to take care of my native mobile apps but that's a different thread.
Yeah. I hear you. It’s all tradeoffs. And tbh, the real decisions about the right approach are taken based on NFRs. Team setting, skills, scaling, overall architecture. It’s good to have the whole bouquet but picking the right flower will continue to be hard.
Solid breakdown. The fragment-based mental model really clarifies what HTMX is actualyy doing under the hood. I've been on projects where frontend state management became this tangled mess of reducers and effects, and seeing how server-rendered fragments sidestep that entirely is refreshing. The validation flow is especially clean, just return 422 with an error fragment and let HTMX handle placement.
I don't disagree that HTMX is perhaps a bit better here but isn't this just "JSP++" / Wicket / JSF / etc.? For years we've gone back and forth between server side rendering and totally separate SaaS type environments. With the complete separation I can hire a back end and a front end developer and, if I want it on the back end, I can have too many microservices or a monolith - it's up to me. Any time you pull in server side rendering you now have your rendering host and your API host as one. Either way, the rendering side certainly isn't a static website hosted on something like S3.
I do, however, appreciate the article as it gives me something to experiment with. I'm knee deep in React code and it doesn't feel right either so perhaps I'm too focused on the "separation of church and state" in my thinking. I will say that I'm not sure how HTMX is going to take care of my native mobile apps but that's a different thread.
Yeah. I hear you. It’s all tradeoffs. And tbh, the real decisions about the right approach are taken based on NFRs. Team setting, skills, scaling, overall architecture. It’s good to have the whole bouquet but picking the right flower will continue to be hard.
found solution: https://quarkus.io/blog/qute-templates-from-db/ ..losing validation...
You might also wanna look at https://iamroq.com/docs/getting-started/ or https://www.the-main-thread.com/p/quarkus-roq-github-pages-static-site-tutorial
should be awesome, loading html from database.. like old cms