3 ms·

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 wi

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.

jamil7 5y ago
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?
- wperron 5y ago
  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.
  - jamil7 5y ago
    > 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.
- deleted 5y ago
  [deleted]
skywal_l 5y ago
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`.
- kbenson 5y ago
  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.
  - skywal_l 5y ago
    /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!
    - kbenson 5y ago
      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.

jamil7 5y ago

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?

wperron 5y ago
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.
- jamil7 5y ago
  > 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.
deleted 5y ago
[deleted]

skywal_l 5y ago

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`.

kbenson 5y ago
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.
- skywal_l 5y ago
  /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!
  - kbenson 5y ago
    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.