The creator of Primate has published an essay entitled "Primate Is the Last Great Web Framework", arguing that the JavaScript ecosystem gave up something when it chose composition over cohesion, and the argument deserves attention independent of the framework it's promoting.
Here’s the claim: a web application is not a pipeline of isolated tools, whatever people say. It's a bundle of shared assumptions about request shapes, validation boundaries, sessions, rendering, and deployment. The typical development approach asks developers to pick a server framework, a database client, a validation library, a frontend, and a build tool, then glue them together. Each piece may be excellent. Nobody is responsible for where they meet, and that's precisely where things fail.
Meta-frameworks were supposed to fix this, and the essay's sharpest observation is about how they did it: by binding the whole stack to a single frontend. Next is a coherent stack, but it's a React stack. Want Solid? That's not a view-layer swap, it's a migration to a different meta-framework with different routing conventions and different backend assumptions. So the ecosystem rebuilds the same backend, filesystem routing plus one blessed frontend, once per view library. Runtime fragmentation compounds it, since "supports Bun" often means nothing more than "Node code happens to run there."
This won’t sound novel to anyone who has spent a career in Spring, or Rails, or Django, or... whatever. Frameworks that own the stack are the default outside JavaScript, and the essay is candid about its PHP-framework roots.
What's interesting is the proposed synthesis: keep the ownership, drop the lock-in. Primate's pitch is one application model where the frontend varies route by route, React here, Svelte there, with backend routes in TypeScript by default and Go, Ruby, or Python available through WebAssembly backends, running unchanged on Node, Deno, or Bun.
None of this is a JavaScript disease, either. Java has spent decades failing to own the same seam: JSF tried to make the browser a rendering detail of the server (with "varying success" that many would rebrand as "failure"), GWT tried to compile the server's language into the client, and Vaadin still carries that torch. Every ecosystem has its own massive graveyard of attempts to erase the boundary between server and client by forcing one side to speak the other's language. JavaScript's lone structural advantage is that it never needed the trick, since both sides already spoke the same language. That's an accident of the browser, not a virtue of the language, and WebAssembly is in the process of handing that accident to everyone else.
This is why the essay matters beyond its own framework. Primate's design is genuinely strong: the route-by-route model is a good shape for the problem, and it's taking the whole question seriously rather than solving it for one frontend at a time. I've watched the thinking behind Primate develop for a while now, and I trust the instincts driving it; the design decisions have consistently been made for reasons rather than for fashion. What nobody has yet, including me, is production data, so how well it holds up under load and scale remains an open question.
But once any language can sit on both sides of the wire, the question stops being which language you build in and becomes who owns the seams, and that question has never had a good answer anywhere. Developers have always made the seam decision implicitly, and the decision shapes everything downstream: pick JSF and the application becomes a component tree, pick Next and it becomes a React app whether or not React was the point. A framework should own the stack without owning your choices.
The essay itself deserves study on its own merits: it makes a clear claim, explains itself plainly and relatively completely without becoming a tutorial, and it resonates well outside its own ecosystem. Project authors should learn from the form as much as the framework. Both are worth your attention.