Today, we’re thrilled to announce Deno 2, which includes:
- Backwards compatibility with Node.js and npm, allowing you to run existing Node applications seamlessly
- Native support for package.json and node_modules
- Package management with new deno install, deno add, and deno remove commands
- A stabilized standard library
- Support for private npm registries
- Workspaces and monorepo support
- Long Term Support (LTS) releases
- JSR: a modern registry for sharing JavaScript libraries across runtimes
We are also continually improving many existing Deno features:
- deno fmt can now format HTML, CSS, and YAML
- deno lint now has Node specific rules and quick fixes
- deno test now supports running tests written using node:test
- deno task can now run package.json scripts
- deno doc’s HTML output has improved design and better search
- deno compile now supports code signing and icons on Windows
- deno serve can run HTTP servers across multiple cores, in parallel
- deno init can scaffold now scaffold libraries or servers
- deno jupyter now supports outputting images, graphs, and HTML
- deno bench supports critical sections for more precise measurements
- deno coverage can now output reports in HTML
Deno is a single binary for the TypeScript and JavaScript ecosystems. Deno is secure by default (installing npm libs do not automatically have full system perms/access).
The new standard library stabilizes a vetted collection of safe binaries instead of having to search for and install random libraries for basic or common use cases with [or without] own security assessments.
Deno compile compiles the TS/JS project into a single binary.
The backwards compatibility to npm and npm/js frameworks enables deno usage in existing projects and with existing libs with the benefits of deno and a path to incremental migration.
The announcement video is worth watching. The intro is great.
I’m not in (or into) the JS ecosystem. I’m glad I didn’t have to dive into that at work yet. But I’ve used deno and bun in the past to evade installing NodeJS.
Just now I used deno v2 to build a static website I contributed a fix to, and it worked. I’m very glad to see I don’t have to juggle different npm alternatives or be stuck without when I want to contribute but definitely do not want to install NodeJS.
The deno install was hilariously slow downloading and installing the JS libs into the node_modules folder. 150 MB of JS source code. For a simple static website generator.
Comparing it to the hugo.exe binary (go, single binary static website generator): That one is 80 MB. Not having to juggle many files makes it a lot faster and compact of course.
The deno.exe is 107 MB. Which is a chunky size; but man it provides a lot. When you contrast that to the node_modules folder… lol
The announcement also mentions and links to JSR for TypeScript module publishing platform, also with backwards compatibility and automatic stuff generating. Which also seems like a good effort.
I’ve been using a release candidate to play with the Lemmy-JS client (plus Fresh for the web framework) for a week and change now. But I’m not really a frontend guy, so I’m not the best to review it.
That said: I love that it’s TS by default, server-side unless you’re deliberate about it, and that every command I need is covered by the Deno executable.
Fresh is the best way to make websites, and Deno is the best way to write infrastructure scripts IMO. I really hope they don’t run out of money.
By Fresh you mean Fresh, the deno web framework? (So it’s deno too.)
Yep. It’s great. The awesomeness of JSX/TSX without having to deal with client side JavaScript frameworks and their awkward state management systems (does anyone actually like hooks?).
Been using deno 1.x for edge functions use cases at work and its been pretty solid. The standard library is excellent and it leans into web standards rather than node.js, while usually still supporting the node.js standard lib (I’m assuming through some polyfilling to the web standard but idk for sure)
It feels a lot more like working in python where you can probably get the job done with the standard library rather than needing to reach for packages for every task.
I’m looking forward to 2.x, it’ll feel a lot less like a WIP runtime.
I’m very excited to give this a go!
Looks ready for actual use now, rather than tinkering with. Package management was my biggest gripe (URLs are literally what it used before). I would like to see TS as the first class citizen however, with JS being deprecated essentially.
I would like to see TS as the first class citizen however, with JS being deprecated essentially.
What do you mean by that.
From what I read, Deno does primarily use and target TS. They label all that JS stuff as backwards-compatibility and ability for a migration path.
