If you don't just grab the source code from Github repository, you run into a couple of problems when trying to run the project.
The path to the template fragments should be : src/main/resources/templates/TaskResource, e.g., src/main/resources/templates/TaskResource/taskItem.html
The taskmanager is very hard to use unless you update the styling in app.scss with the one found on GitHub.
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.
If you don't just grab the source code from Github repository, you run into a couple of problems when trying to run the project.
The path to the template fragments should be : src/main/resources/templates/TaskResource, e.g., src/main/resources/templates/TaskResource/taskItem.html
The taskmanager is very hard to use unless you update the styling in app.scss with the one found on GitHub.
Thanks. I’ll get the paths fixed. I’ve not included the css so it won’t blow up the post too much.
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