If you are concerned about security in one of your imported dependencies (or in user code) you can run that code in a sandboxed worker (See: https://deno.land/[email protected]/runtime/workers#specifying-...). Beyond this it is still very useful to limit your runtime for software to only access specific directories, network addresses, etc. So the sandbox/security is definitely not useless.

Running TypeScript directly is a great part, but there’s a bigger, little-discussed aspect: Deno has a built-in, prescribed, standardized,

- Testing framework

- Linter

- Bundler

- Formatter

It’s like having Cargo or Go’s CLI for JavaScript/TypeScript. It eliminates so much fiddling and breakage, gets everyone in the ecosystem on the same page, etc. Even for a solo project it’s been a dream to use, compared with the hodgepodge of a Node project.

At least for me one of my favorite things is how integrated it is, after having used Rust for a while, having the compiler, linter, lightweight testing and formatting all in one bundle is an amazing time saver and a major boon for me. No more fiddling with ever growing configurations for ESLint, or having to install Jest/Ava/uvu/tap for testing and their ESLint rules and then Prettier which may also require ESLint... I realize not everyone cares enough to configure it, but the approach of Deno (and Rust, and Go, and so on) is such a weight of my shoulders when starting a project. Just open Neovim, create a TypeScript file, write some tests, all without having to do any kind of configuration or installation of packages.

For me, one of the largest benefits is the Web API compatibility.

As a frontend dev by day, trying to write services/scripts in Node is constantly frustrating. Simple things like base64 encoding or making http requests have me heading off to the documentation and trying to remember "the Node way".

The other large part for me is the lack of npm. The npm ecosystem is one of my largest sources of daily frustration. I look forward to ESM everywhere.