Hacker News Reader

Comment by greghuels | Hacker News Reader

It doesn't have to be server software. I created a cli tool with Deno so that it could run as a standalone binary. It runs a lot faster than if it were built with node and any user without node installed could still run it.

View on HN

It's standalone in a sense you end up with a single executable, but deno is embedded with your code. A `hello world` example is more than 50MB stripped.

The command to do that is called `compile` but its a bit of misnomer, it does not compile a free standing executable with your code but basically creates an executable wrapper around `./deno yourcode.ts`.

That's not really different than how most scripting languages provide compile or application delivery features (whether built in or through a module). You're right that it isn't actually "compiling" as most people would expect that to mean in a programming context, but given that packaging into a single executable is generally what they're actually looking for, that's usually an acceptable distinction.

What I wonder is how big hello world is for a statically linked packaged dene application, and if it's easy to produce those (assuming 50MB is for linked binary). That's probably more useful in a lot of cases if it's not wildly larger.

    /tmp$ mkdir test
    /tmp$ cd test
    /tmp/test$ curl -sOL https://github.com/denoland/deno/releases/download/v1.13.1/deno-x86_64-unknown-linux-gnu.zip
    /tmp/test$ unzip deno-x86_64-unknown-linux-gnu.zip
    Archive:  deno-x86_64-unknown-linux-gnu.zip
      inflating: deno
    /tmp/test$ cat > test.ts
    console.log('Hello, World!');
    /tmp/test$ ./deno compile test.ts
    Check file:///tmp/test/test.ts
    Bundle file:///tmp/test/test.ts
    Compile file:///tmp/test/test.ts
    Emit test
    /tmp/test$ ls -lh
    total 198M
    -rwxr-xr-x 1 user user 83M août  16 23:52 deno
    -rw-rw-r-- 1 user user 32M août  23 19:12 deno-x86_64-unknown-linux-gnu.zip
    -rwxrwxrwx 1 user user 83M août  23 19:13 test
    -rw-rw-r-- 1 user user  30 août  23 19:13 test.ts
    /tmp/test$ ./test
    Hello, World!

So, it's still linked against glibc and libgcc from what I can see almost all the following are from glibc):

    $ ldd deno
        linux-vdso.so.1 (0x00007fff3fbeb000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007efd30939000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007efd30721000)
        librt.so.1 => /lib64/librt.so.1 (0x00007efd30519000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007efd302f9000)
        libm.so.6 => /lib64/libm.so.6 (0x00007efd2ff77000)
        libc.so.6 => /lib64/libc.so.6 (0x00007efd2fbb2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007efd34593000)

But honestly, that's pretty minimal. Just over 80 MB for the base to not have much in the way of dependencies seems pretty good. And given that library extensions are supposed to mostly be done in Rust (if that hasn't changed), those are statically linked by default as well, so that will hopefully cut down on accidentally introducing dependencies from the system it's built on also.

I haven't worked with JS for a while so I'm not really up to speed on modern Deno and Node but can't you also package a node cli tool as a binary? Also how can Deno run a lot faster? I would imagine it at least suffering from a startup time hit due to the TS compiler. Maybe someone can explain?

Transpiling TS to JS on startup does incur a cold start penalty, you can minimize it by using the `--no-check` option to transpile with SWC instead of TSC but it's still there. On subsequent runs though, it'll start up instantly because the JS is cached locally after transpiling (you can even trigger this step yourself with `deno cache`)

Beyond that, you still have the v8 engine running the JS, so yeah in most cases performance will be pretty much what you can expect from Node _except_ with regards to anything that reaches out of the sandbox (like filesystem or network access). These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages, and Promise-based APIs all the way down. For the builtin HTTP server for example you can expect higher throughput from Deno. Tail latencies also tend to be better with Deno.

You're not immediately going to get "blazing fast, native speeds" but you can get some nice optimizations.

> These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages

Very cool, thanks for the detailed answer.

Reply on news.ycombinator.com