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

61–70 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#61

Post by Kaido »

nikisweeting wrote: post #47
bartlomieju wrote: post #45

Earlier quoted context omitted.

That really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For packages that use native Node APIs there's a Node compatibility layer being developed as part of the standard library: https://deno.land/std@0.80.0/node . It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting…

Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.

My understanding is that Deno modules get cached after being used so that you can use it offline.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#62

Post by [deleted] »

nikisweeting wrote: post #47
bartlomieju wrote: post #45

Earlier quoted context omitted.

That really depends on concrete package; a lot of npm packages works perfectly fine in Deno, especially if they're available via CDNs like Skypack. For packages that use native Node APIs there's a Node compatibility layer being developed as part of the standard library: https://deno.land/std@0.80.0/node . It's still lacking a lot of modules and doesn't provide seamless experience, but with every release it's getting…

Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.

[deleted]

Re: Deno 1.6 supports compiling TypeScript to a single executable

#63

Post by nikisweeting »

bartlomieju wrote: post #60
nikisweeting wrote: post #47

Earlier quoted context omitted.

Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.

> We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great. You can achieve the same thing with Deno! By default Deno downloads all dependencies into a central cache directory, but by providing DENO_DIR env variable with…

Local caching alone loses all the benefits of using a package manager though.

I want to have a central repository of all the package versions with enforced monotonically increasing version numbers and a public, explicit chain of trust. Otherwise it's basically curl | sh with all its associated problems https://docs.monadical.com/s/against-curl-sh

Using URLs means there are no rules enforced, the code hosted at that URL can change out from under you without any warning. A new developer checking out our repo could fetch totally different packages than everyone else on the team and not have any warning about it being different, or any recourse if they wanted to fetch a previous version.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#65

Post by mpoteat »

bartlomieju wrote: post #53
flowerlad wrote: post #44

Earlier quoted context omitted.

OK, so what is Deno? How is it different from Node? Why did you make Deno given that Node exists? Looks like Deno can run .ts files without first compiling to .js. What are the other benefits?

Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno…

Personally I appreciate being able to choose my linter, compiler, dialect etc. I also tend to prefer distributed solutions. Deno running the entire environment is a negative for me, at least for now. To me, it just shows an approach of ignoring what already exists and reinventing the wheel.

I've tried to get Deno to work before in production, but it had so many compatibility issues last I tried it would take weeks or months to refactor things so it would work.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#66

Post by mark_and_sweep »

bsmith0 wrote: post #54
mark_and_sweep wrote: post #16

Earlier quoted context omitted.

Not really, I think. Startup of a "hello world" seems to be 5ms faster on my Windows machine: https://gist.github.com/MarkTiedemann/c2f4013c3a60bb28df5005...

What's up with the page faults in the timing details?

Not much. Similar to the context switches column, a couple of thousand page faults are quite normal for a quickly executed Windows program. For comparison, listing all running processes, you'll hit ~1-10k page faults (see timeit benchmark results at the top of the readme: https://github.com/MarkTiedemann/fastlist).

Re: Deno 1.6 supports compiling TypeScript to a single executable

#67

Post by nikisweeting »

jimmyspice wrote: post #57
nikisweeting wrote: post #47

Earlier quoted context omitted.

Thanks, that's useful info, we'll probably wait until there's >90% compatibility with the node APIs then. We're never going to put URLs into our imports because we want to be able to run things offline without depending on 3rd party servers to stay up & consistent over time, but if we can depend on local ./node_modules libs once compatibility is improved then that's great.

why not use artrifactory or similar proxy so you always have a local mirror?

That seems like a mediocre patch for a problem that wouldn't exist in the first place if you used a centralized package manager.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#69

Post by mpoteat »

Hokusai wrote: post #21
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.

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

The issue I see with this approach is that library code is duplicated among applications. In the limit, this is how you get every Electron app bundled with Chromium.

It's a little more complicated, but modern Node development is a huge step forward to the old days of sadly attempting to get the LINPACK header configuration correct in your C project.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#70

Post by jjnoakes »

Couto wrote: post #43
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…

This reminds me of the server that Zoom used to have. Accepting connections only from 127.0.0.1, alone, isn't enough, since any request from the browser would match that IP, even if the request was being made through a XSS attack. I'm sure someone with more knowledge in security would better chime in.

What I do is generate a random token, pass it to the browser I spawn, and only accept requests that include the token.
Post reply on HN