terrablue

The primary innovation is flexibility, simplicity and official support for a wide array of modules. Give it a shot, I don't think you'd regret it.

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.

Just a quick mention that there is next to no coupling. If you don't use `primate/store`, none of the ORM code gets pulled in. You could be using any other database client.

The same applies to sessions, i18n, or any frontend. They're all either path'd imports or distinct packages.

Hey, thanks for the feedback, sorry for that. Should be fixed now.

Primate gets close to that -- there is a webc handler with props support: https://primatejs.com/modules/web-components

The webc handler does lack a few things like hydration, and this can be added if users show interest in it.

Hey. Regarding 1, compatibility is handled by a separate library, Primate's only dependency, rcompat: https://github.com/rcompat/rcompat ; it's a unified compat layer around Node, Deno and Bun.

As for 2, what would you consider a React-like example? The examples on the frontend are meant to illustrate commonalities between different frontends.

First metaframework to support the big three, and a unified I18N API for frontends