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

71–80 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#71

Post by bartlomieju »

mpoteat wrote: post #65
bartlomieju wrote: post #53

Earlier quoted context omitted.

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…

> Personally I appreciate being able to choose my linter, compiler, dialect etc.

I completely agree with that! But on the other hand with plethora of tools available it can be quite overwhelming to configure all the tools, especially for new users.

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

Work on compatibility layer with Node is ongoing [1]. With every release there's some new API being compatible, but far from over.

[1] https://deno.land/x/std@0.80.0/node

Re: Deno 1.6 supports compiling TypeScript to a single executable

#72

Post by bartlomieju »

nikisweeting wrote: post #63
bartlomieju wrote: post #60

Earlier quoted context omitted.

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

There's nothing preventing you from still using a central repository (or its mirrors). I highly recommend "Deno is a Browser for Code" by Kitson [1] which discusses this subject in more depth.

[1] https://kitsonkelly.com/posts/deno-is-a-browser-for-code/

Re: Deno 1.6 supports compiling TypeScript to a single executable

#73

Post by breatheoften »

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…

> My concern is only will users accept a local server running on their desktop.

This sounds pretty cool -- is there a way for the deno runtime to restrict the server process to only be able to generate the legal types of http traffic that a browser could generate if allowed to open a connection to a specific url (or set of urls)?

If so i'd feel more comfortable about running the embedded server -- ideally the security risk of running the server would be closer to the risk when running an embedded set of daemon browser tabs -- rather than the risk when exposing all the unfettered power of a unix process ...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#74

Post by pietrovismara »

naiveai wrote: post #50
SiVal wrote: post #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…

I find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?

Know the language and use automatic linting to exclude the bad parts without effort. Here you go, Javascript/Typescript is suddenly a decent language too.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#75

Post by mark_and_sweep »

nikisweeting wrote: post #63
bartlomieju wrote: post #60

Earlier quoted context omitted.

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

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

Re: Deno 1.6 supports compiling TypeScript to a single executable

#76

Post by nikisweeting »

bartlomieju wrote: post #72
nikisweeting wrote: post #63

Earlier quoted context omitted.

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

There's nothing preventing you from still using a central repository (or its mirrors). I highly recommend "Deno is a Browser for Code" by Kitson [1] which discusses this subject in more depth. [1] https://kitsonkelly.com/posts/deno-is-a-browser-for-code/

Hmm I don't find this article very convincing. From my perspective this is a security and sysadmin nightmare (for the reasons in my link above). Lockfiles actually provide repeatable builds almost all the time, the only times they fail are when depending on non-JS builds like node-gyp or other C++/etc dependencies where you can't lock on system build tooling versions because they're outside the scope of what npm can lock.

The real appeal of Deno for our org is the stdlib, which as a side effect means we can depend on fewer packages. The wholesale removal of the package manager seems like an unwanted pain that will only keep us away from switching and gaining the stdlib benefits.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#77

Post by SiVal »

naiveai wrote: post #50
SiVal wrote: post #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…

I find it interesting that your example for "benefit of hindsight" is TypeScript. TypeScript is a superset of JavaScript, so it's literally "just add good stuff to the bad and live with it". Am I misunderstanding something?

No, you're making a good point, but my meaning was that TypeScript is a language that is always (and has always been) written as an improved, benefit-of-hindsight, good-parts-only language. It does of course allow any old JS to be used, but that has always been for the purpose of allowing code already written in JavaScript to be called from code written in TypeScript. No TypeScript project, library, or tutorial is ever written like old JS, so TS's allowance of old code that was already written as JS is like a C compiler's escape to assembly, where inline assembly is valid code handled by the C compiler but isn't really C.

Traditional JS with new features added, or traditional Node with new features added is the opposite case, where the old standard is being extended, unlike the TS or C+asm case, where the new standard has a mechanism for calling back to the old if necessary. (Deno could still be what I'm talking about even if they added a Node-emulation-library to allow it to call modules written for Node, but I have no idea whether such a thing is planned.)

Re: Deno 1.6 supports compiling TypeScript to a single executable

#78

Post by nikisweeting »

mark_and_sweep wrote: post #75
nikisweeting wrote: post #63

Earlier quoted context omitted.

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

> 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

Re: Deno 1.6 supports compiling TypeScript to a single executable

#79

Post by breatheoften »

deno seems really amazing. This is essentially single file distribution of a secure runtime for application code -- that is a lot of platform-capability-bang for the distribution-reach-complexity buck! This has to already be the best server container format for typical application code in terms of the security possibilities doesn't it?

I'd almost like to see deno grow some kind of puppeteer based browser api as server-app platform --

http request -> deno server process runtime (with secure sandbox) and puppeteer-like handle to the client browser for state transfer -> client ui render ... it would be quite interesting to think of the client browser page tabs as a "child process launched by the server" rather than as as a stateless request from an http client -- as most server rest api architectures tend to push you towards ...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#80

Post by sim_card_map »

kibwen wrote: post #49
loosescrews wrote: post #14

Earlier quoted context omitted.

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.

I think the belief that Go does no dynamic linking whatsoever is outdated; I seem to recall that they recanted this approach on Mac and Windows since these platforms only offer a stable system interface via dynamically-linked libraries, and trying to re-implement all of it ended up being a lot of work only to end up with broken code after system updates. On Linux I think Go still tries to link mostly statically, but…

This is correct.
Post reply on HN