Some of that logic (logged in, or exposing stuff based on RBAC) are usually pretty easy in templates of any flavor. And that's usually where I have to revisit

Some of that logic (logged in, or exposing stuff based on RBAC) are usually pretty easy in templates of any flavor. And that's usually where I have to revisit for changes, so maintenance shouldn't be bad. Sometimes I do common things like stored markdown->html by injecting filters into the template context. So {{ comment | markdown }}. For completely different presentations, you can have separate templates returned by the same endpoint. But it sounds like that actually should just be a separate endpoint altogether. You could use template inheritance for code reuse, but you can also walk into over complicating that if those start diverging over time. Handling screen variety is best done with CSS (and JS when you have to do something hacky). The HTML shouldn't need to change for that. Even back to JSPs or early PHP, I learned the hard way to avoid sticking business logic in my "templates" or sticking HTML in my code. Either will work, but maintaining it sucks. And if it is a successful project and you need to change the design in year 3, it'll easily result in a nearly complete rewrite. I know the cool thing to do now is even just expose the data via REST or GraphQL and do a SPA, but I don't do frontend work enough to get over that learning curve.