Routing
Routes and controllers, one tree
React pages with loaders and actions beside NestJS controllers with modules, guards, and dependency injection. One process, one build, one deployment.
Ness.js 7
One filesystem.Both sides of the request.
React routes render the interface. NestJS controllers serve the API. They live in the same tree, build together, and deploy as one directory — without becoming one bundle.
npx @nessframework/cli@latest new my-appa Ness.js project
app/├── routes/│ ├── page.tsxrenders│ ├── page.server.tsloader, action│ └── blog/[slug]/page.tsxbrowser└── server/├── app.module.tsserver└── api.controller.tsGET /api/health
browserserver
Measured against Next.js on the same application
- 1.9–2.2×
- Throughput on server-rendered routes
- 2.7×
- Faster production builds
- 44%
- Less client JavaScript
- 51%
- Smaller install
Both self-hosted on Node, both rendering every request. Ness is behind on cold start — 541 ms against 192 ms — and ships a larger deployment bundle. The harness is in the repository: see how the numbers are produced.
What you get
Caching
Caching that survives a second instance
Filesystem, SQLite, and Redis adapters with tag and path invalidation, an optional in-process tier, and eviction broadcast between instances.
Deployment
Ships as one directory
ness bundle node traces the production dependency graph and writes a self-contained folder. It runs on a bare Node image with no install step.
Runtime
Web APIs, not wrappers
Loaders and actions receive a Request and return a Response. Middleware, cookies, headers, and redirects are the platform’s, not a framework dialect.
Start with a working application.
Every starter is scaffolded, built, served, bundled, and served again from the bundle on every commit.
Create an application