> Secure by default. No file, network, or environment access, unless explicitly enabled.
> Supports TypeScript out of the box.
> Ships only a single executable file.
> Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt).
Taken all together instead of individually, Deno is clearly designed to produce more secure and maintainable codebases than NodeJS over longer periods of time and team turnover. All of these "by default" additions better ensure a common, high-standard baseline for any arbitrary Deno codebase over any period of time.
Individual developers often tend to focus on "how does this help me/improve my workflow right now?", instead of thinking like a CTO and focusing on "how does this technology make our IT systems more robust to long-term maintenance, developer turnover, and security threats?".
Secure by default means you shift security from the developer team into the framework. Say your original security-focused developer team attritions over time, and due to a software engineer shortage you're forced to hire less experienced or less security-oriented folks.
Even if you end up with a new team more oriented to "move-fast-and-break-things" than secure-by-design/correct-by-construction, your framework still provides a minimum security baseline they can't intentionally or accidentally violate.
That works in reverse too - say you're a new startup that can't afford to hire the best of the best yet. If you choose a secure-by-default framework like Deno, you're getting security and correctness from the framework for free, rather than having to pay a premium for developer talent capable of that.
Typescript instead of Babel means that all Deno codebases everywhere will use the same language, one that provides better correctness and security guarantees than most Babel options.
Built-in dependency-inspector simply makes that function more available and apparent to developers. Maybe useful for new entry-level folks, not so much for more experienced ones.
And I thought the value of a built-in code-formatter was demonstrated by Go with gofmt - all Go codebases everywhere are formatted the same way, making it easier for Go devs to get up to speed with a new codebase.
One of things that used to really annoy me about both Rails and Nodejs was how they were not secure-by-default and left certain security details/holes to be implemented/fixed on an ad-hoc basis on every new project by individial dev teams.
But the whole point of a framework is to provide common solutions to such common problems that all projects incur, so the dev team can focus on the custom and creative parts of the app, the value-added parts, the competitive edge. It's great to see Deno and others doing this.