Why not? You can have server side routing that returns the page and then react then takes over and hydrates a small part within the page or the complete page. A similar approach is used for the islands architecture, and you can even combine different frontend frameworks for maximum flexibility, e.g. developer preference. You can decide to load your frontend libraries lazily or as shared scripts so they are cached and only take up some bandwidth on initial load (a couple of kB minified and zipped).
replyIn principle I agree that putting React or Vue in for a little interactivity is a bad approach, if the same can be achieved with Htmx, which it usually can.
replyHowever for some really complex mini apps, that's another story. But for the rest of those CRUD pages, you can go simple server side rendered.
"Complex mini app" is one hell of a concept.
replyIt can be. Think something like a file viewer or a text editor, or a music players. You can probably make do with vanilla javascript, but there’s some threshold where using react to take care of the state<=>ui relationship is worth it.
replyA text editor or music player is hardly "mini".
replyAgain, the issue with htmx is that it pretends like it is not a framework, when in fact, it is just a second attempt at angular 1.0, with even more naive assumptions about web apps.
> A text editor or music player is hardly "mini".
replyIf it's a sub-function of a bigger ensemble that mostly dies something else then it's fine to call them “mini apps”.
For instance a bank app may contain a text editor for the internal messaging feature of the app, that would count as a min-app in that context.
Having adopted Angular 1 back when it was new, I can promise you it's completely different than Htmx.
replyWhat is the main difference?
replyAstro then.
reply