Comparison
JustScale vs NestJS
Two full TypeScript backend frameworks, two very different bets.
JustScale and NestJS are both full TypeScript backend frameworks with dependency injection and controllers, but they sit on opposite sides of a technology shift. NestJS is mature and has a huge ecosystem, but its model is built on the legacy experimental decorators and runtime reflect-metadata that predate today’s standards, and it remains CommonJS-oriented. JustScale is ESM-native with no decorators and no runtime metadata reflection.
JustScale also bundles far more than routing into its core: one controller model spanning HTTP, WebSocket, SSE, gRPC, CLI, and events; a domain layer with an ID-free model and compile-time type-states; built-in authentication and declarative, queryable model-level permissions; automatic OpenAPI generation; OpenTelemetry; a multi-instance testing harness; hot reload in development; and durable processes with distributed-safe locks and channels. Choose NestJS for the largest ecosystem and the deepest hiring pool; choose JustScale for a modern, ESM-native framework where all of that is built in rather than assembled.
JustScale vs NestJS at a glance
| Aspect | JustScale | NestJS |
|---|---|---|
| Programming model | Function-based DI (defineService); no decorators, no runtime metadata reflection | Legacy experimental decorators + reflect-metadata (emitDecoratorMetadata) |
| Module system | ESM-native ("type": "module") throughout | CommonJS-oriented; ESM support remains awkward |
| Transport | HTTP, WebSocket, SSE, gRPC, CLI, and events from one controller model | HTTP plus a separate microservices/transport layer |
| Domain modeling | ID-free domain; entities are their own references; mutations require Locked<T> | Unopinionated; typically string IDs + an ORM of your choice |
| Type safety | Type-states: data shape gates what code can do, checked by the compiler | Standard TypeScript types; runtime validation via pipes/DTOs |
| Auth & access control | Built-in authentication + declarative, queryable model-level permissions | Assembled from Passport, guards, and libraries |
| API docs & testing | OpenAPI from your controllers; multi-instance test harness; hot reload | @nestjs/swagger; Jest + utilities; restart on change |
| Distributed primitives | Locks, channels, and cluster coordination are first-class | Provided by the ecosystem (Redis, microservices transport) |
| Durable workflows | Built in: plain async code compiled into durable processes with signals, race, and delay | Not built in; add a queue (BullMQ) or external engine |
| Ecosystem & maturity | Young; smaller surface, fewer integrations | Very mature; huge module ecosystem and community |
Choose JustScale when
- You want a modern, ESM-native framework without legacy decorators or runtime metadata reflection.
- You want one integrated framework — multi-transport controllers, a domain layer, auth, permissions, OpenAPI, observability, and testing — instead of assembling libraries.
- You have long-running, stateful workflows (orders, onboarding, sagas) that must survive restarts.
- You want domain code that never touches string IDs and is safe by construction across instances.
Choose NestJS when
- You need the largest ecosystem and the deepest pool of developers who already know the framework.
- You prefer a decorator/module style, or you have existing Nest code and integrations.
- Your workloads are mostly request/response and you already have a queue for background work.
Switching from NestJS
- NestJS providers map to JustScale services: an @Injectable() class becomes a defineService({ inject, factory }) definition.
- NestJS controllers map to JustScale controllers, but routes are defined with route-builder factories (Get/Post/...) instead of method decorators.
- Background jobs and queues that you ran on BullMQ usually become durable processes, removing the separate worker/queue infrastructure.
- Guards and interceptors map to JustScale guards and middleware.
Frequently asked questions
Is NestJS outdated?
NestJS is actively maintained and widely used, but its core depends on the legacy experimental decorators and runtime reflect-metadata that predate the current decorator standard, and it remains CommonJS-oriented. JustScale takes a modern, ESM-native, decorator-free approach.
Is JustScale a replacement for NestJS?
It can be, for new projects that want a modern ESM-native framework with durable workflows, a pure domain model, auth, permissions, and OpenAPI built in. NestJS remains the safer pick when ecosystem size and team familiarity dominate.
Does JustScale use decorators like NestJS?
No. JustScale uses function-based dependency injection and route-builder factories, avoiding decorators and reflect-metadata entirely.
Can JustScale handle background jobs without BullMQ?
Yes. Durable processes replace most queue-based background work; they suspend on signals or timeouts and resume after restarts.