Primate: The Last Great Web Framework That Owns the Stack
Primate Is the Last Great Web Framework
As the creator of Primate, I argue that modern web development suffers from excessive fragmentation where no single tool owns the full stack. Unlike meta-frameworks that lock you into one frontend or runtime, Primate provides a unified application model allowing you to mix React, Svelte, TypeScript, Go, and Python route by route. It runs seamlessly on Node, Deno, or Bun, ensuring the framework handles the seams while you retain complete freedom of choice.
A web framework should own the stack without owning your choices.
- gitpusher
The English language has no words (yet) to capture that special combination of nausea and embarrassment one feels when they commit in good faith to reading a long piece of prose... only to slowly realize the whole thing is AI generated. But I'm feeling it more and more often these days.
- 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?
- wredcoll
The idea of the web-router "owning" the database fills me with a visceral sense of loathing.
Data is always the important part of any real program.
- dkarl
> But web applications are not just pipelines of isolated tools. They are full of shared assumptions: request shapes, validation boundaries, session handling, rendering, routing, serialization, deployment targets.
Some of those things are specific to web applications. Others are not. It's fine for web-specific logic to be tied to all of the shared assumptions of a web framework, but application logic should not be. As the architecture evolves, the application logic may need to be run in other architectural contexts: as a message consumer, inside an orchestration framework, etc.
That's one of the most painful things about PHP. Entire businesses get built around business logic in PHP backends, and then when you need to execute that logic in a different architectural context, every line of it has to be rewritten, because it's too much work to extricate it from the context of serving web requests.
If you are designing your framework to contain application logic, then it should look ahead to the possibility of that logic being used in a different architectural context. It should facilitate and encourage writing application logic that is agnostic of the web context. Otherwise you're encouraging people to repeat the mistake of PHP all over again.
- fron
Why use light gray code highlighting on a light background? Most of the code blocks are unreadable due to this.