Just throwing it out there for visibility, ncc will compile a TS entrypoint down to a single file as well, without having to use Deno https://www.npmjs.com/package/@vercel/ncc Edit: I completely missed that this Deno release packaged the runtime as well, disregard this as an alternative! Guess I’ll eat the downvotes I deserve :P
> without having to use Deno But you need to use ncc? What's the relevant difference?
Deno 1.6 supports compiling TypeScript to a single executable
11–20 of 284 posts
Re: Deno 1.6 supports compiling TypeScript to a single executable
#12This 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.
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.
Not really. I agree on the other benefits of binaries but our containers usually only have the final layer change (the source code). This means that all the lower layers, python base image, requirements, etc are cached. So we can ship 100 times and add maybe 100mb of new container overhead. Binaries will ship 100% every time.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#13This 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.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#14This 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.
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.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#15This 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.
Size was not really a goal for the first pass of the feature.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#16Does this offer a speed increase vs running the the code directly using $ deno test.js ( not sure what the exact command is )
Re: Deno 1.6 supports compiling TypeScript to a single executable
#17This 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.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#18Does this offer a speed increase vs running the the code directly using $ deno test.js ( not sure what the exact command is )
Re: Deno 1.6 supports compiling TypeScript to a single executable
#19This 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.
But I honestly don't mind up until about 100MB.
Re: Deno 1.6 supports compiling TypeScript to a single executable
#20This 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.
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.
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.