Skip to main content

Deno, the new runtime for JavaScript and TypeScript. From the same creator of NodeJS!

· 5 min read
Bruno Carneiro
Bruno Carneiro
Fundador da @TautornTech

Deno

Today I'm going to talk about the new exciting thing that's emerging, Deno!! console.log("Welcome to Deno 🦕");​

Well, before we start, the title might seem a bit strange. But throughout the article I'll explain and share my opinion on the matter.

Deno is the new secure runtime for Javascript and TypeScript​

Whatafuck is that?!

Deno is a runtime for JavaScript and TypeScript that uses the V8 engine and was built using the Rust programming language.

In other words, a little tool to run the stuff we write :P

Deno is from the same creator of NodeJS, Ryan Dahl. The project aims to fix all the design problems that exist in NodeJS, described in the famous talk given by Ryan. "10 Things I Regret About Node.JS" - Ryan Dahl

The 10 problems are basically these:

  • Promises

    • He added promises to NodeJS in June 2009, but removed them in February 2010;
    • Promises are an abstraction for async/await;
    • It's possible that the unification of promise usage may have accelerated the standardization of async/await.

  • Security

    • Programs written with NodeJS have access to all system calls, can write to disk, access network data, read files — all without prior authorization.

  • Build system

    • If you're writing a module linked to a C library, you'd use GYP to compile and link that C library to Node;
    • Other tools used GYP, now only Node is using it;
    • A Python adaptation of JSON. Node has unnecessarily complex nodes surrounding it.

  • package.json

    • Including NPM in Node makes NPM a distribution standard;
    • Centralized, privately controlled repository for modules;
    • Includes unnecessary information;
    • Unnecessary abstraction of the concept of modules as a directory of files. This doesn't exist on the Web.

  • node_modules

    • The module resolution algorithm is highly complex;
    • It's not a browser-compatible format.

  • Require without extension

    • Unnecessarily implicit;
    • That's not how the browser works;
    • The module loader needs to "guess" what to do.

  • index.js

    • Unnecessarily complicated loading system;
    • Especially unnecessary after it became mandatory to support through package.json.

Now let me talk about the new Brastemp Deno.​

Main Features​

  • Secure by default. No file, network, or environment access by default (unless explicitly enabled). Example:
$ deno run --allow-read=/etc https://deno.land/std/examples/cat.ts /etc/passwd
  • TypeScript support by default. This creates safer code.
  • A single executable:
$ deno run --allow-net fetch.ts
  • Has a dependency inspector deno info and a code formatter deno fmt;
  • Has built-in modules by default (no "npm"). Everything lives in Deno Land Yay!;
  • Scripts can be bundled into a single JS file;
  • Top level await support (no need to declare async/await);
  • Browser compatibility (can access window instead of global).

Philosophy​

  • The goal of Deno is to create productive and secure scripts for environments with modern programming;

  • Deno will always be distributed as a single executable;

  • Deno receives the URL of programs so they can be executed. This way it doesn't need to be run with "15 megabytes of zipped files";

  • It uses browser-compatible protocol by default to load its modules: URLs;

  • Among other things, Deno is a great replacement for scripting utilities that were often written with bash or python.

Key Points​

  • A single executable deno run goPowerRangers.ts;
  • Browser compatibility — the subset of programs that are completely written in JS and don't use the global Deno namespace (or feature-test for it) can also be run in a modern browser without changes;
  • Provides a built-in toolkit for unit testing, code formatting and linting to improve the developer experience.

Didn't lose concepts used in V8, can efficiently serve an HTTP server.

Comparisons with NodeJS​

UHHH Deno

  • Deno does not use NPM (goodbye node_modules!);

  • Its modules reference URLs or file paths;

  • All async actions in Deno return a promise. Therefore, Deno offers different APIs than Node;

  • Deno requires explicit permissions to access files, network, and environments;

  • Deno always "dies" on unhandled errors.

Deno uses ES Modules and does not support "require". Third-party packages are imported via URLs.

Example:

import * as log from "https://deno.land/std/log/mod.ts";

Other key behaviors:​

Remote code is fetched and cached on first execution, and is never updated until the code is run with the --reload flag.

Modules/files loaded from remote URLs are intended to be immutable and stored in cache.

Conclusion​

Will Deno kill NodeJS? I don't think so — Deno is still very new and Node is already a stable and established tool within the community and the market. I believe we'll soon have one more option to consider when creating a new application.

Deno looks like an incredible tool, bringing features that make total sense, such as permissioning and increased code security, among others.

The community is quite excited about Deno (me too! hahaha).

Should I already use Deno in production? I wouldn't recommend it. Even though v1.0 has been released, Deno is very new — it's been in development since 2018 and there aren't many production cases. Unlike NodeJS, which has had a decade and millions of projects.

Either way, let's wait and see what the next chapters of this tool bring.

That's it for today :P.

I'll write more about it and also post videos on my channel, where I present other technologies too, follow me there: Tautorn Tech.

References​