Overview
Joor is an RPC framework built for services where the request path is hot enough that framework overhead shows up on profiles. Most JavaScript web frameworks resolve routes, parse schemas, and wire middleware dynamically on every request. Joor moves that work to build time.
Architecture
- AOT routing. Route tables are compiled ahead of time into a static dispatch structure — no per-request regex matching or dynamic tree walks. The router's job at runtime is a lookup, not a search.
- Typed clients, generated. Service definitions produce fully typed clients as a build artifact. A frontend calling
api.orders.create(...)gets parameter and response types checked against the exact server contract, with no manual sync. - OpenAPI as output, not input. The same service definitions emit an OpenAPI spec, so external consumers and API tooling stay accurate for free.
- Multi-runtime. The core avoids Node-specific APIs; adapters target Node, Bun, and edge runtimes from one codebase.
Key decisions
Compile the framework away. The guiding principle is that anything knowable at build time should cost nothing at runtime. Routing, validation wiring, and serialization layout are all resolved during compilation, which keeps the per-request path short and predictable under high concurrency.
Contracts as the single source of truth. Server handlers, typed clients, and OpenAPI docs all derive from one definition. There is no scenario where the docs say one thing and the client types say another.
Ergonomics are a performance feature. Fast frameworks that are miserable to use get abandoned, and the performance goes with them. Joor keeps a small, conventional API surface — defining a route reads like plain TypeScript, not like configuring a compiler.
Status
Actively developed. AOT router, typed client generation, and OpenAPI emission are working; current focus is streaming responses and richer middleware composition.