Danet is a NestJS-shaped framework for Deno that sits on Hono

The pitch: NestJS's architecture, without Node

Danet is described as a framework heavily inspired by a NodeJS framework called Nest, and the README sets expectations carefully. The aim is to provide the same efficiency, but in Deno. And then the line that matters for anyone reading: of course, Nest is way more mature, think of it as a hero that we look up to.

That is a project describing itself accurately, which is rarer than it should be. The README goes further and says it borrows a lot from Nest, including documentation and sentences on the page itself, and asks readers to check Nest out because they deserve a lot of credit. Without Nest, the authors say, they would not be developing Danet.

So the shape of the thing is not in doubt: decorators, dependency injection, modules, an out-of-the-box application architecture. The README describes the same benefits Nest is known for, creating highly testable, scalable, loosely coupled and easily maintainable applications, and says the architecture is the same as the hero and was originally heavily inspired by Angular, which is where Nest itself came from.

The runtime target is Deno, which the README calls a relatively new engine, and the goal is to bring the same level of pro-efficiency and professionalism into Deno's world. The framework is for building efficient, scalable Deno server-side applications and is entirely built with TypeScript.

Under the hood, Danet makes use of Hono. That is the practical detail that decides how it behaves, because Hono is a lightweight routing framework that runs on Deno, Node and the edge, and Danet's own abstractions sit on top of it. The README says it abstracts a lot of things so you can focus on your core business and architecture, which is the classic framework promise and is the thing the dependency injection and decorator machinery exists to deliver.

The primary language of the repository is recorded as HTML, which reflects the size of the documentation site rather than the source, since the framework itself is TypeScript. The topics list typescript, deno, dependency-injection, ioc, framework, websocket and websocket-server, and the repository description calls it the most mature backend framework for Deno and mentions creating HTTP and WebSocket servers as well as KVQueue workers.

JSR-only distribution since 2.4.0, and what that changed

The Warning section at the top of the README is short and specific. From version 2.4.0, Danet is only available via JSR at @danet/core, and the README adds that it is a step closer to runtime agnosticism.

The rationale is visible in the rest of the README. Nest is distributed on npm, which ties it to Node. Moving the package to JSR, which is Deno's own registry and is also usable from other runtimes, is what makes the runtime-agnostic claim possible. It is a distribution decision with an architectural consequence rather than a packaging detail.

There is a JSR badge for @danet/core in the header, and the release history shows versions being cut regularly: 2.11.4 with the note about fixing injectable scanning on Deno 2.9, 2.11.3 updating cron usage to work with Deno 2.9, and 2.11.0 adding gRPC. The gRPC addition in a minor version is a notable signal of how actively the framework is changing.

The two Deno 2.9 fixes are worth noting for a different reason. Fixing injectable scanning means the dependency injection container had to adapt to how Deno 2.9 changed module scanning, and updating cron usage means the scheduling primitive moved underneath. Both are the kind of change that makes a framework feel fragile for its users, because the behaviour a project depends on can change with the runtime rather than with the framework.

The repository layout has grown alongside. There is src/ for the source, tool/ for tooling, spec/ and openspec/ for specifications, example/ with a run.ts, an events.ts and a schedule.ts, a validation.ts at the root, a mod.ts, and a deno.json. There are also a .claude/ directory and a CLAUDE.md file, a .vscode/ directory, a .prettierignore and a .graphifyignore, plus a coverage.lcov file and a graphify-out/ directory, which suggests the coverage report and a generated graph are committed rather than produced only in CI.

What the repository layout reveals about how the project works

The top-level entries describe a project that has grown past a single library, and several of them are unusual enough to be worth naming.

There is src/ for the framework source, mod.ts at the root as the module entry point, and deno.json for the runtime and task configuration. The tool/ directory holds the tooling, and the .vscode/ and .claude/ directories plus a CLAUDE.md file at the root indicate that the project is set up for editor tooling and for AI-assisted contributions.

Then there are two directories that do not belong to a normal framework repository. spec/ and openspec/ suggest that the project keeps its specifications as documents rather than only as code, with openspec/ being a separate specification workflow layered on top of spec/. For a framework whose public API is the product, that is a reasonable investment: a specification is what tells a contributor what the intended behaviour is before they write it.

The graphify-out/ directory and the .graphifyignore file suggest that some form of code or dependency graph is generated from the tree and committed, and the coverage.lcov file at the root means the coverage report is checked in as well. Neither is unusual for a project that has been running coverage and analysis in CI for a while and treats the artefacts as part of the repository.

The example/ directory contains three files, run.ts, events.ts and schedule.ts, which map onto the three things a generated project does: start the application, handle events and lifecycle hooks, and schedule work. The presence of schedule.ts is a direct consequence of the cron compatibility work in the release history.

And validation.ts sits at the repository root rather than inside src/, which suggests it is a shared module that both the framework and the examples import, most likely holding the validation logic the dependency injection and the request pipeline rely on.

The CI badge points at a workflow named run-tests.yml, and there is a codecov badge, so the test suite runs on every push with coverage reported. The .prettierignore file at the root is the counterpart to the formatting configuration that the project uses, and its presence at the root rather than in a config directory is a small sign of a project that has had to exclude specific paths from formatting.

The CLI, and what a generated project looks like

Installation is two commands, one of which installs a global CLI from JSR:

deno install --global -A -n danet jsr:@danet/cli
danet new <my-project>

The -A flag grants the CLI all permissions, which for a scaffolding tool that runs deno commands is the usual pattern in the Deno ecosystem but is worth noticing on a machine where you do not want a globally installed tool with unrestricted access. The -n flag gives the binary the name danet, and the jsr:@danet/cli specifier is what tells Deno to fetch it from JSR rather than from a URL.

The second command creates a project from a template, and the example/ directory in the repository shows what a project looks like once created. There are three files: run.ts, which is presumably the entry point, events.ts, which suggests the event and lifecycle layer, and schedule.ts, which suggests the scheduling or cron side. That matches the release history, since cron usage is something the project has had to adapt for Deno 2.9.

The README points the documentation in three directions: use our CLI links to the separate Danet-CLI repository, the documentation site at danet.land, and the blog at savory.github.io. The CLI living in its own repository is a reasonable separation, since a scaffolding tool has a different release cycle from the framework it scaffolds.

Contributing is handled in the usual way, with a CONTRIBUTING.md, a CODE_OF_CONDUCT.md and a link to the project's Discord. The README's own pitch for contributors is that contributions make the open-source community such an amazing place to learn, inspire and create, and the repository description notes a hacktoberfest topic tag, which explains the contribution volume.

On the licence there is a small inconsistency worth flagging. The licence field on the repository is a custom one that GitHub cannot classify, while the README text says the project is licensed under the MIT License and points at a LICENSE file in the repository root. Reading the LICENSE file is the way to settle it.

Where Danet is the wrong choice

Three limits, and the first is that the README says so itself.

The first is maturity. Nest is way more mature, and the project treats it as a hero to look up to. That has concrete consequences for anyone choosing between them. Nest has years of production use, a large ecosystem of packages built around its decorators and module system, and a documentation base that Danet openly borrows from. When you are choosing a framework for a service that has to stay running, that gap is the thing to weigh, and it is not a small one.

The second is the coupling to Deno's release cycle. Two of the three most recent releases are fixes for Deno 2.9 changes, one to dependency injection scanning and one to cron usage. A framework that has to patch itself when the runtime changes its module scanning or its scheduling primitive is a framework whose users inherit the runtime's churn. Deno moves faster than Node, which is one of its attractions and also the reason a Nest-shaped framework on top of it needs regular compatibility work.

The third is the narrowness of what Hono gives you underneath. The framework's own abstractions are the point, but they sit on a routing and middleware layer that is deliberately small. The features the README advertises, HTTP and WebSocket servers, gRPC and KVQueue workers, cover the common cases. What you will not find here is the ecosystem that Nest accumulated: guards and interceptors with deep third-party support, a CLI with generators for every module type, microservices patterns with transport layers, and testing utilities that other packages build on.

The alternative approach is to use Hono directly with a small amount of your own structure. Hono is a fine framework in its own right, and the dependency injection that Danet adds is the main thing you would lose, along with the module and decorator conventions that make a large Nest-style codebase navigable. The difference in approach is that Danet gives you a large codebase discipline for free, at the cost of a framework that has to be kept in step with a fast-moving runtime, while Hono gives you a small, stable, fast library that leaves the architecture to you.

For a small service with a handful of routes, Hono alone is less machinery and fewer version constraints. For a codebase with many people and a need for enforced module boundaries, the Danet structure is worth the dependency, and the maturity gap is the price of taking it early.

Editorial conclusion

Adopt Danet if you are building a Deno service and want the NestJS application structure, dependency injection and decorator-based modules without running Node, because the framework gives you that structure with Hono as the HTTP engine underneath. Do not adopt it if you want the NestJS feature set, because the README itself says Nest is way more mature and calls it a hero, and do not expect a package you can install from npm, because since version 2.4.0 it is only available through JSR. Verify first that the JSR package name and the CLI you install are the ones your project pins, that the Deno version you run is compatible with the release you choose, since recent versions track Deno 2.9 changes to dependency injection scanning and cron usage, and that the licence file matches what your organisation expects, since the repository records a custom licence while the README text says MIT.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Savory/Danet on GitHub