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

161–170 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#161

Post by jhatemyjob »

oorza wrote: post #151
205g0 wrote: post #145

Earlier quoted context omitted.

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

Why anyone would look at the litany of mistakes that is npm and Node, then look at Deno and all of the same developers learning nothing except how to implement its "hurr durr URL loading code is cool" approach to security and think "this a good idea" is beyond me. I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any…

At least when you pipe to bash it feels gross and wrong. I can't believe they made it a fucking feature

Re: Deno 1.6 supports compiling TypeScript to a single executable

#162

Post by lemax »

We use vercel/pkg to distribute our product as a standalone executable that runs in on-prem windows environments. Our product is actually comprised of multiple NodeJS servers that are spawned as child processes in one master Node procees, and that module gets built using pkg. We also have a windows installer that configures a windows service to run the executable/keep it up. It’s proven to be a really simple way to distribute our app to the enterprise that’s been working for a few years. It doesn’t really protect source code, but provides a decent enough level of obsfuscation for our needs.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#163

Post by _pmf_ »

205g0 wrote: post #145
j1elo wrote: 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…

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

> What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg.

Maybe some people need to get things done and don't have the resources for endless tooling masturbation?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#164

Post by Soremwar »

jay_kyburz wrote: post #89
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.

Using URLs is like having an iframe to somebody else's website on your website.

Whot? How is that even comparable? It's third party code after all, the same happens when you use a library in any other language

Re: Deno 1.6 supports compiling TypeScript to a single executable

#165

Post by remexre »

loosescrews wrote: post #107
pjmlp wrote: post #26

Earlier quoted context omitted.

Ada, FreePascal, C and C++ do perfectly fine. Not everyone is using Linux with glibc linking issues.

Using C and C++ without libc excludes the use of nearly all common libraries.

libc's other than glibc don't have issues with being statically linked.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#166

Post by Soremwar »

svnpenn wrote: post #149
dguaraglia wrote: post #142

Earlier quoted context omitted.

Sure, and you can do something similar with C and obtain a ~10kb executable, or even less if you put some effort. Or write that in Java and need a complex setup including the JRE and a bunch of packages to support it. The point is that this makes deploying a Deno application simpler. Binary size is kind of the wrong metric to worry about.

My point is, what is even the point of using Deno? If its for static typing... well Go has that. So what is the benefit?

What's even the point of using Go? If it's for static typing Rust has that

So what's the benefit?

Same can be said about any language really, it's personal preference

Re: Deno 1.6 supports compiling TypeScript to a single executable

#167

Post by Mulpze15 »

galaxyLogic wrote: post #40
j1elo wrote: 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 configur…

I am trying to do this too. But I would like to make it work on MacOS as well. The problem there is Safari does not let you connect to localhost over http. So if Safari is the preferred browser of the user, you need to convince them to change, which is hard.

Or is there à better way there?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#168

Post by txdv »

svnpenn wrote: post #136

Yeah, and the executable is 47 MB. You can do the same thing with Go: package main import "os" func main() { for _, s := range os.Args[1:] { o, _ := os.Open(s) os.Stdout.ReadFrom(o) } } and the executable is 1 MB.

Why is Go's binary so big?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#169

Post by throw_m239339 »

svnpenn wrote: post #149
dguaraglia wrote: post #142

Earlier quoted context omitted.

Sure, and you can do something similar with C and obtain a ~10kb executable, or even less if you put some effort. Or write that in Java and need a complex setup including the JRE and a bunch of packages to support it. The point is that this makes deploying a Deno application simpler. Binary size is kind of the wrong metric to worry about.

My point is, what is even the point of using Deno? If its for static typing... well Go has that. So what is the benefit?

> So what is the benefit?

A better type system(covariance, dependent types) than Go's and generics, a richer ecosystem, deploying the same codebase on the server and in the client...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#170

Post by ameliaquining »

205g0 wrote: post #144
ameliaquining wrote: post #138

Earlier quoted context omitted.

If the 47 MB executable has no dependencies other than the kernel, then in many scenarios it'd be a lot easier to deploy than if you had to separately install a language runtime. Of course, Node.js can also do this with pkg, and also I don't know whether executables produced this way really are dependency-free (although depending only on widely-available shared libraries would be almost as good).

> then in many scenarios it'd be a lot easier to deploy It's not. Most advanced deployments nowadays use container orchestration where deploying is as easy. For simple deployments (eg SSGs) there're enough products on the market. Integrating the build step hides it at the same time (good for beginners) but creates many other problems in the long run if we just talk about repackaging the run-time.

I think you're underestimating the diversity of environments out there. Not everyone's using cutting-edge deployment tech; lots of folks are just SSHing or RDPing into a physical or virtual server, copying stuff there, and running it. Certainly, that's how things were done at my last job. And it can get worse; some of these environments are locked down in some way or another, by security policies that limit what you can do. In those environments, having the executable be fully self-contained is really helpful.

(For the record, I am a proponent of things like containerization and serverless, and generally try to bring them into use wherever I can. This doesn't require me to ignore the reality that lots of places don't use them, and that this will remain true for a long time to come.)

Post reply on HN