It clearly supports different runtimes than node with different capabilities and limitations.
It seems more of a runtime-agnostic web server.
I agree framing pikku has been a pretty hard challenge for me.
It supports different runtimes in the sense of deno / bun or custom nodeJS runtimes in the cloud, but ultimately relies purely on typescript / a JavaScript compatible backend.
It’s less of a webserver and more of a lightweight framework though, since it also supports CLIs or Frontend SDKs / isn’t tied to running an actual server.
Each function can be wired to whatever transport you want:
Pikku builds a full type contract between your backend and frontend. It doesn’t ship a runtime SDK just typed native fetch calls / websockets / queue clients so your frontend gets zero added bundle size and fully inferred request/response types out of the box.The framework is tree-shaken at the function level, so you can deploy only what’s needed (plus its dependencies) as a binary, Docker image, or serverless functions. Switch cloud providers or queue systems freely, no rewrites, just switch runtimes.
Auth, permissions, and middleware live directly at the function level, giving you a single consistent entrypoint across all transports.
It also supports Next.js-style "use server" patterns — you can call backend functions directly in SSR while keeping them accessible over HTTP for external use.
There’s even a CLI mode where you can run commands on a server and stream live output to a tiny local client — same code, same types.
I'm about to release the next version that allow supports workflows similar to those just released by Vercel or by Cloudflare Workflows.
Would love to hear your thoughts! There's even more on the roadmap :D