node.jsts-nodedeno

deno vs ts-node : what's the difference

I'm working on a relative large typescript project, I'm using ts-node to run node testing and examples. As far as I understand, ts-node will compile ts files to js files and execute.

Recently I heard about deno, which is a typescript runtime. I tried a few examples in typescript, which works using ts-node. I ran the example with deno, there were many compile messages printed in the console, then execute the code. And later I found there's cache files in /username/.deno. I don't feel the deno execution is faster than ts-node

It seems both deno and ts-node will compile and run using cache. What's the difference between them?

Solution

  • TL;DR

    Deno is more like Node than like ts-node, i.e. it is a JS runtime based on V8. Unlike Node, Deno contains the TypeScript compiler. Deno is not part of the Node/npm ecosystem.

    ts-node on the other hand is a Node.js module that uses the TypeScript compiler to transpile TypeScript code and run it in Node. ts-node is part of the Node/npm ecosystem.

    Deno is fast. See below.

    Deno and ts-node similarities

    Deno and ts-node differences

    ts-node

    Deno

    Maturity

    ts-node

    ts-node relies on the Node.js runtime so it is fair to include it here:

    Deno

    Deno is itself a runtime so it doesn't use anything else:

    Popularity

    GitHub:

    Stack Overflow:

    Libraries

    ts-node

    You can use all Node libraries available on npm

    (currently there are 955,263 packages on npm, not all of them for Node but still a lot)

    The Node libraries that are available on npm even if they were originally written in TypeScript are usually published in a form transpiled to JavaScript with additional type definitions in *.d.ts files (included in the npm package or installed separately from the @types namespace).

    Deno

    There are 1256 third-party modules on https://deno.land/x/ and 56 libraries and tools on https://github.com/denolib/awesome-deno#modules (I didn't check if all are the same)

    The Deno libraries are just TypeScript files.

    Installation difference

    ts-node

    Deno

    Your code differences

    ts-node

    Deno

    Examples

    Here is an example of publishing a minimal library written in TypeScript and using it.

    Creating and using a TypeScript library with Node and ts-node

    This is what I am doing right now with an example project on:

    https://github.com/rsp/node-ts-hello

    Creating library:

    1. find a name that is free on npm (no longer enough, see below)
    2. create repo on GitHub
    3. create package.json with npm init
    4. install TypeScript compiler with npm install typescript
    5. decide if you're keeping package-lock.json in the repo (there are pros and cons)
    6. create a src dir where you will keep TypeScript files
    7. add hello.ts to src
    8. add tsconfig.json file and make sure to:
    1. add "main": "dist/hello.js" in package.json (note the "js" suffix)
    2. add "types": "dist/hello.d.ts" in package.json (note the "ts" suffix)
    3. add "build": "tsc" to package.json (watch out for redundant files, see below)
    4. login with npm login (you shouldn't be logged in all the time - see: Now Pushing Malware: NPM package dev logins slurped by hacked tool popular with coders)
    5. compile the project with npm run build
    6. publish the package with npm publish
    1. logout from npm with npm logout
    2. see your ~/.npmrc and make sure you have nothing like this left:

    Using the library in other project using ts-node

    1. create a new directory
    2. create a package.json file with npm init
    1. install our library with npm install node-ts-hello
    2. optionally install ts-node with npm install typescript ts-node
    1. add hi.ts file that imports our library with:
    1. run it with npx ts-node hi.ts (if ts-node was installed locally) or ts-node hi.ts (if ts-node was installed globally)

    Potential problems: I simplified the above a little bit, my actual process of creating that library is described here.

    Creating and using a TypeScript library with Deno

    This is what I am doing right now with an example project on:

    https://github.com/rsp/deno-hello

    Creating library:

    1. create repo on GitHub
    2. put hello.ts in the repo

    Using library:

    1. Create a file hi.ts with the contents:
    1. Run your program with deno run hi.ts

    The first run will print:

    $ deno run hi.ts 
Compiling file:///Users/rsp/talks/deno/hello-deno-test/hi.ts
Downloading https://raw.githubusercontent.com/rsp/deno-hello/master/hello.ts
Compiling https://raw.githubusercontent.com/rsp/deno-hello/master/hello.ts
Hello, TS!

    The second run:

    $ deno run hi.ts 
Hello, TS!

    If you change hi.ts it will be recompiled but the dependencies will not get downloaded again:

    $ deno run hi.ts 
Compiling file:///Users/rsp/talks/deno/hello-deno-test/hi.ts
Hello, TS!

    (Note that touch hi.ts will not be enough, you need to make the actual changes because Deno checks the file checksum, not the timestamp.)

    Speed

    ts-node

    The speed of starting the ts-node version of our hi.ts from the examples above:

    $ time npx ts-node hi.ts 
Hello, TS!

real    0m0.904s
user    0m1.300s
sys     0m0.083s

    This is after the dependencies are already installed and after running several times to make sure that all of the caching works. Almost one second.

    Deno

    The speed of starting the Deno version of our hi.ts from the examples above:

    $ time deno run hi.ts 
Hello, TS!

real    0m0.028s
user    0m0.010s
sys     0m0.015s

    This is also after the dependencies are already installed and after running several times to make sure that all of the caching works.

    More than 32x speed improvement.

    Summary

    Deno should be compared more with Node than with ts-node because Deno is an entirely new runtime while ts-node is a module for Node so your program run with ts-node really use the Node runtime.

    It is a very young project but has already got a lot of traction. It doesn't have as much documentation or libraries as Node but it means that it may be the best time to get involved because when it gets more popular, and I think it will for many reasons that are beyond the scope of this answer, people who already have experience with it will be needed on the market, like it was with Node.

    The program startup speed is already very impressive and I expect more improvements there.

    The development speed of using single files with no need for configuration like package.json or node_modules together with a possibility to import dependencies directly from URLs (like on the frontend) will make it possible to work in a different way both for the end user code and for the libraries. We'll see how it all works in practice but it already looks promising.