Deno AR, Versions, Review

By pjain      Published May 22, 2020, 10:35 p.m. in blog Programming   

Part of Series - Javascript Series

Deno AR, Versions, Timeline


Ryan Dahl restarted using Node in Jan'18 and Bert Bedler (a Node.js core contributor and co-founder of Strong Loop) started up Deno. - Currently non-JS part uses Go - but highly efficient not JS. May shift to Rust, C++. - In future deno could target Go, Rust, etc. as development languages on top.

Comparisons/Differences with Node.js, Retrospective on Design Mistakes

  • Node.js in 2009 had a focus on a non-blocking, event-driven development as JS was single threaded.
  • By 2012 Ryan (the original author of Node.js) left (to focus on Go) - feeling it had achieved his goals framework including

    • Support many protocols in general - HTTP, SSL, ..
    • Strong platform support at high perf - Windows (IOCP), Linux (epoll), Mac (kqueue)
    • A high perf, small core, with a stable API
    • Growing strong ecosystem of external modules/plugins - NPM
  • TS is beautiful language - TS compiler built into Deno runtime, better than Dart, like GO yet full backwards to JS. The state of art changed, so dynamic languages like JS are good for scientific apps but static checked languages like Go better for servers.

  • TS compiler builtin - encourage replacement of JS which is ALSO supported
  • TS has finally delivered a practical optionally typed language.
  • TS allows code to grow seamlessly from quick hacks to large, well structured machinery.
  • Deno hooks into the TS compiler to do module resolution and incremental caching of build artifacts.
  • Unmodified TS files should not recompile.
  • Normal JS should work too (but that's trivial since TS is a superset of JS)
  • It should use V8 Snapshots to for fast startup (not yet in the prototype as of mid'18)

  • Simpler language runtime to startup, environment flags

  • Deno Goal: Ship only a single executable deno.exe with minimal linkage - all necessary so/libs are within executable eg libgss, libc, libm, libstdc++, libpthread, linux-vdso, etc.
  • Bootstrap the runtime by compiling Node modules with Parcel into a bundle. (This is a massive simplification over what Node had to do.)
  • Leverage node.js ecosystem (?out of box?) - eg HTTP web server - just use that

  • Did not stick with Promises in Node - necessary abstraction for async/await

  • Deno goal is to always die immediately on unhandled promises. (Insanely this is not the case in Node.)
  • Better support for async/await from top-most level a la modern python, dart, etc.

  • Security - V8 strong security sandbox - Node could have had MORE security guarantees, eg a linter should NOT be able to access

  • Security SANDBOX - leverage V8 secure - deno does not allow scripts access to file system or network. Users can optin at time of execution by --allow-net, --allow-write.

  • Build systems are really important and complex. Node started with chrome's GYP but later left for GN build system. GYP has an awful funky experience - non-JSON python iteration of JSON. GYP build system is exposed to anyone who wants to bind to V8 engine. Now there is Node-GYP js wrapper on it - unnecessary complications.

  • C++ bindings required to bind to JS/V8. Instead should have had a more general Foreign Function Interface (FFI) for generality and no need to compile - more versatile.

  • protobuffer, which means that deno is fully capable of distributed deployment.

  • NPM/package.json - Node.js require import statement inspects package.json files for "main". Together they are the lifeblood of JS ecosystem - by Isaac NPM creator. Node further built NPM into its distribution - made it the standard. However problem is that a centralized, privately controlled repository for modules now is required globally. Also require in your code depends on package.json which is APPLICATION defined i.e. violates encapsulation. It leads to a lot of wiggling bits ie inter-dependencies of multiple modules can conflict, etc. Also this means LINKING to a package needs a LOT of assistance, on a particular "environment" has at least 4 parts as itemized below .. lots of wiggle room for failure!

    node.js code package.json NPM database Local node_modules/ folder require("somemodule") ---> { .. "dependencies": { "somemodule":"^0.1.0" somemodule /somemodule

  • package.json became this all purpose application manifest and complexity magnet/boilerplate noise. It now includes all sorts of unnecessary information like License? Repository? Description? In contrast if only relative files and URLs were used when importing, the path defines the version there would be no need to list dependencies. DENO does not attempt at compatibility with existing Node modules.

  • Imports are relative or absolute URLs ONLY.
  • Imports must provide an extension.
  • Remote URLs are fetched and cached indefinitely on the first load.
  • At build time, only if the --reload flag is provided will the resource be fetched again.
  • Vendoring can be done by specifying a non-default cache dir.

    import { test } from "" import { log } from "./util.ts"

  • vs Package modules - lots of confusion

  • node modules become super heavy and complex to parse - slows build
  • In practice just using $NODE_PATH wouldn't have precluded that scan again relative URLs/Environment settings flexibility.
  • Node modules deviates greatly from browser semantics - huge gulf in just getting code to "run anywhere".
    • file system gets massively cluttered with hundreds/'thousands once "build" done - ?PKJ - huge pain when trying to backup "extract real code".
  • also require has no extension - is it .js, .ts, .ejs ?? - too hardwired to "assume it is .js" only.

  • Browser Environment got split off from CLI/Server node.js

  • Deno goal is to be Browser compatible where functionality overlaps.


Why Not?


People, main contributors

  • Ryan Dahl
  • Bert Bedler
  • Kitson Kelly - TS focus

Deno Internals

  • Good (but mid 2018 older) discussion of deno internals - in Chinese, but you can google translate
  • How to evaluate ry (Ryan Dahl) 's new project Deno?

  • Node.js uses mainly C++ with libuv as its asynchronous I/O library

  • Deno uses Rust, together with Tokio.

Kernel Passing Architecture

  • Single point binding to V8 kernel (vs Node.js binds all over the place)
    • ALL system calls done by message passing (protobuf serialization)
    • ONLY two native IO functions - send recv
    • This makes system easier to design and testability/auditing for correctness

Go based structure wrapping V8

Performance Benchmarking

Deno Performance can be lower than highly tuned node.js programs even as of Q1'2020

  1. Since ts could have a bit of overhead, it advisable to compare deno(ts implied), with node-js tuned programs as could be higher performance.

  2. Cold start of deno programs can be slower than second "warm-start" reload as dependencies have to be fetched, and then kept in optimized fashion (eg for rapid link/load in binary locally).



There are no comments yet

Add new comment

Similar posts

Deno Resources

Deno QS

Time series Analytics and Charting

DNS, Domains, Multi-Tenancy, Django focus ------