Live data from Hacker News

Deno 1.6 supports compiling TypeScript to a single executable

github.com

31–40 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#31
post #13
post #2

This is such a good feature. Go has been great for shipping single purpose binaries (like the CLI for https://fly.io ), but I really enjoy writing TypeScript more than Go.

Definitely, I do wonder how it compares in binary size. Especially the 'baseline' size of a hello world.

Currently binary size is a bit larger than the `deno` cli.

We are currently working on reducing size for these `deno compile` binaries though. From preliminary testing we think we can reduce size by around 60% - maybe even more.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#33
post #21
post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

> A lot of languages are doing single static binary deploys now As a developer for more than 30 years, I find that statement quite interesting. When I was a kid I was very happy to find a way to compile Basic to an executable like I was doing in Pascal and C++. For me is the standard way of thinking about applications. Is it a common experience to actually have to ship many files for one application? I thought that i…

Same here, the static linking hype feels real strange, given that was the only option we used to have back in the day, and having access to dynamic linking on 16 bit platforms felt like liberating.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#34
post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

Do they? As far as I know, Go is the only mainstream language that supports static binaries with normal non-trivial programs. Rust for example depends on dynamically linked libc if you use the standard library. While you technically can statically link libc, it is unsafe with glibc.

We currently do dynamically link to glibc. But we could in theory support musl, which would remove our dependance on the glibc dynamic link.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#35
post #13
post #2

This is such a good feature. Go has been great for shipping single purpose binaries (like the CLI for https://fly.io ), but I really enjoy writing TypeScript more than Go.

Definitely, I do wonder how it compares in binary size. Especially the 'baseline' size of a hello world.

Currently it's 30-45Mb depending on the OS. We're working on providing a "lite" version of the runtime, that doesn't include tools like formatter or linter. Preliminary works show that we should be able to trim executables down to about 20Mb.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#36
Node is almost perfectly matched to the "Oops, well, too late now" design ethos of JavaScript itself. Nobody was stupid. We humans just can't really predict what will work out and what won't in the future, and this was one of those frustrating cases like carving in stone, where every mistake you make is permanent.

But a combination of various factors made the web an enormously impactful medium. It's too important to take the approach of "well, let's just add some good stuff to the bad and live with it" where we don't have to. We have to in the browser, but we don't have to on the server. I want to see the "benefit of hindsight, rebuild it better" design of TypeScript matched with a server-side equivalent, which looks like Deno.

I hope Deno succeeds.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#38
post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

Yeah, its especially horrible in python for webdev. How are you supposed to deploy django/flask projects when NOT using docker or some PassS? I haven't figured out anything better than a git pull script to update things. I can't imagine there is nothing better in 2020.

Prior to docker some common patterns were to rsync the files up to each server, or compress the files to .tar or .zip on a build server, rsync it to the servers and then uncompress into your desired directory.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#39
post #9

Earlier quoted context omitted.

A lot of languages are doing single static binary deploys now. Rust, Nim, Go. It's a really nice pattern. Static binaries are so much easier that the gross PHP / Ruby / Python pattern that has to ship directories full of files that (usually) have to be put in the correct place. It's also easier than shipping a runtime like a JVM. With a single binary, containers get even slimmer.

Do they? As far as I know, Go is the only mainstream language that supports static binaries with normal non-trivial programs. Rust for example depends on dynamically linked libc if you use the standard library. While you technically can statically link libc, it is unsafe with glibc.

That's why you statically link musl C

Re: Deno 1.6 supports compiling TypeScript to a single executable

#40
post #29

I've been using vercel/pkg with great success, in order to achieve a similar target and package a whole application into a standalone executable: https://github.com/vercel/pkg This can be useful for people wanting to do this with Node. It's nice to have a single file that can be started right away without any external dependency. And also, it prevents from having to distribute the full sources. Kudos to the Deno devs…

I'm using vercel/pkg as well. I have a Node.js server which generates HTML and opens a browser on Windows which then asks the server for that html at 127.0.0.1.

So browser will be my GUI and Node.js packaged with vercel/pkg my back-end. It is more flexible than say Electron because GUI can be anything I want it to be.

My concern is only will users accept a local server running on their desktop. I've tried to configure the executable so that the server accepts connections only from the same host as where the http-requests are coming from.

I assume the same situation would exist with Denon, if you build a product with it and want to use the browser as your front-end. Are users OK with a server running on their PC?

Post reply on HN