Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.6 supports compiling TypeScript to a single executable

github.com

Post reply on HN
Print view View original

91–100 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#91

Post by axaxs »

echelon wrote: post #9
mrkurt wrote: 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.

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.

Python has had packagers for many years...cxfreeze, pyinstaller, and others. I hear Nuitka works well. Just pointing out the fact, not disputing your statement. I also wish it was more of a first class citizen.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#92

Post by mark_and_sweep »

nikisweeting wrote: post #78
mark_and_sweep wrote: post #75

Earlier quoted context omitted.

> Using URLs means there are no rules enforced How is using a URL different from using a NPM package? In both cases you can specify a module, a version, and need to trust some remote server that it is sending you the correct files. > the code hosted at that URL can change out from under you without any warning The same can and has happened with NPM. See left-pad.

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad

> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages

How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code.

> Left pad was promptly fixed! That's an argument for a centralized package manager, not against.

This is not an argument for a central package manager, but an argument for a central package repository.

Deno is already a "central package manager". Similar to NPM in Node development, Deno is the default tool to download code in Deno development. Both with Node or Deno, you can download code in other ways, too. Nobody forces you to load code from URLs via import statements or NPM packages via npm install and commonjs require. (Also, when it comes to executing random code from the internet, Deno has a sandbox. Node doesn't.)

And yes, well maintained package repositories are great. Whether centrally or decentrally managed repos are better is up for debate, though.

In any case, if you want to use NPM packages in Deno, I'd recommend https://www.skypack.dev/. It's "NPM packages from a URL", so, as we have established earlier, it's just as much reliant on trust and potentially unstable as anything in life, but at least their left-pad is patched...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#94

Post by dvt »

sixbrx wrote: post #55
galaxyLogic wrote: post #40

Earlier quoted context omitted.

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 configur…

Do you have any trouble with the users being prompted by the Windows firewall to allow the server to listen on localhost? I like this way of doing things but I've had propmts like that for my own dev tools and I think that would put off my users.

Anecdotal, but I maintain a mildly popular Spotify player (https://github.com/dvx/lofi) which needs a similar flow for OAuth authentication. I've never had an issue created or complaint about the Windows Firewall popup.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#95

Post by rodrigoj42 »

kumarvvr wrote: post #90

I wonder if it's possible for TypeScript to be a .NET CLR supported language. It would be great to have a powerful scripting language for the .NET Ecosystem. I know C# can be used for scripting, but I want something like Python, an easy to use, dynamic language that has the performance of the .NET VM

YMMV but I think F# fills that gap nicely

Re: Deno 1.6 supports compiling TypeScript to a single executable

#96

Post by hetman »

loosescrews wrote: post #14
echelon wrote: 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.

Rust has supported statically linking to MSVC and musl for a while now but also added static glibc support on Linux very recently:

https://github.com/rust-lang/rust/pull/77386

Re: Deno 1.6 supports compiling TypeScript to a single executable

#97

Post by sciolistse »

yboris wrote: post #58
galaxyLogic wrote: post #40

Earlier quoted context omitted.

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 configur…

> It is more flexible than say Electron because GUI can be anything I want it to be. Feels like one of us is misunderstanding something. Electron lets you run any web technology - so when users open your app, they are greeted with whatever you can show on a webpage. You can also have Electron run in the background as a server if that's something you're into ;)

I believe the idea is if you wanted a client built with C# Winforms, wxWidgets, JS+HTML or anything else they could all run against the same backend server.. So it'd be more flexible than Electron in that you wouldn't need to use web technology at all, if you don't want to.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#98

Post by nikisweeting »

mark_and_sweep wrote: post #92
nikisweeting wrote: post #78

Earlier quoted context omitted.

The difference is that NPM as an org has a lot more to lose if they mess up everyones packages or serve incorrect versions than some random person's website. Left pad was promptly fixed! That's an argument for a centralized package manager, not against. If it were hosted on some private server we'd all still be screwed. https://www.npmjs.com/package/left-pad

> The difference is that NPM as an org has a lot more to lose if they mess up everyones packages How is that important? Most Deno packages are imported from GitHub (or deno.land). Neither NPM nor GitHub want to lose your code. > Left pad was promptly fixed! That's an argument for a centralized package manager, not against. This is not an argument for a central package manager , but an argument for a central package r…

I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#99

Post by christophilus »

bartlomieju wrote: post #32

Hey, Bartek from deno.land here. I'll be more than happy to answer your questions about Deno and its development.

Last I looked, there was no clear crypto story for Deno. Has that improved, or are there any concrete plans for it? Deno was really quite nice when I kicked the tires, but didn't seem quite ready for prime time web development with no crypto functions.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#100

Post by stevetodd »

echelon wrote: post #9
mrkurt wrote: 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.

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.

> It's also easier than shipping a runtime like a JVM.

jlink has shipped since JDK 9 and can package all dependencies and the JRE into a single file. Hello world clocks in at about 22 MB.

Post reply on HN