[graypegg]

I might be missing something here, but I'm struggling to understand why the concept of mixing up implementation details by request path is desirable.

Maybe for colocating a legacy application with a new application that's slowly strangling it [0], but for a new application, this seems antithethical to using a framework in the first place. I can't say for sure why you liked Laravel, but I like Laravel/Rails/et.al. because I don't have to make decisions about the parts of the application that aren't unique to what I'm building.

This just allows you to yak shave on a route-by-route basis?

[0] https://en.wikipedia.org/wiki/Strangler_fig_pattern

[terrablue]

Hey. There are many use cases that involve mixing frontends. On the Primate website itself, the RSS feed is a route previously served by the Handlebars module (because it needed some logic), now by the (a bit more minimal) pure HTML module.

The rest of the website used to be written in Svelte, but the bundle got unnecessarily big. Because it uses Primate, I could rewrite the frontend part using Marko, shaving off around 30% of the client bundle size. Those are not things you can even try out if you're using one of the lock-in meta-frameworks. So a good framing of the counter question would be, why commit when you don't have to?

However, even if you never end up mixing two or more frontends: you have access to all other features using the frontend of your choice.