Live data from Hacker News

Deno 1.6 supports compiling TypeScript to a single executable

github.com

261–270 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#261

Earlier quoted context omitted.

Sorry, jQuery was a bad example - I remember jQuery not working in Node at all, but that was roughly 10 years ago. Things have improved. The fact remains that the most popular JS env is the browser. It has APIs such as window which are not compatible with Node and Node has APIs which are not compatible with the browser like __dirname or require. That's why tools such as browserify and webpack exist to bridge the gap.…

> Node compat is not. :'( That's a shame, it would make such a good node replacement with a great stdlib and Typescript support. I hope they reconsider in the future.

If Deno was only "Add TypeScript support", "Add security capabilities", and "Add URL imports", etc. it would simply be a new version (or multiple new versions) of Node.

These (and other) disruptive breaking changes are about fixing mistakes that cannot be fixed (or at least, are hard to fix) in Node.

Maybe, in a few years, you'll say something like "Oh, I wish legacy Node would be more Deno compatible" because Deno will be the de-facto server-side JS scripting runtime. Equally, it's possible that Deno will fail, but that many good ideas will be incorporated into Node as breaking changes.

Node and Deno as well as their environments can grow further together or further apart. I think it's too early to tell which future is more likely.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#262
post #158

Earlier quoted context omitted.

You are still not thinking of it as a browser. Consider a use case where Deno is the client, not the server. One example is a replacement for piping random curls into bash: deno run --allow-write=~/.myapp https://myapp.io/install.ts It works quite well as secure scripting runtime.

I mean that's a neat feature and all, but my primary use for Javascript/Typescript is to write frontend and backend code using the tens of millions of lines of useful library code available in the existing JS/npm ecosystem. It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_…

> It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement

The 1.0 announcement post the team mentioned:

> For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno.

and:

> Over time, we expect Deno to be able to run more and more Node programs out-of-the-box.

I don't think they've ever claimed to be an immediate drop-in replacement.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#263
post #158

Earlier quoted context omitted.

You are still not thinking of it as a browser. Consider a use case where Deno is the client, not the server. One example is a replacement for piping random curls into bash: deno run --allow-write=~/.myapp https://myapp.io/install.ts It works quite well as secure scripting runtime.

I mean that's a neat feature and all, but my primary use for Javascript/Typescript is to write frontend and backend code using the tens of millions of lines of useful library code available in the existing JS/npm ecosystem. It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_…

Here's a quick example of how to use import maps to get Node-like imports for ES modules distributed on NPM like lodash-es: https://gist.github.com/MarkTiedemann/4ac5837195f52d24bb1dec...

Re: Deno 1.6 supports compiling TypeScript to a single executable

#264
post #162

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

We’ve been following a similar process for our internal tools and have found it to be a good solution. Manually including native libraries is probably the only lousy part. Out of curiosity, what are you using to achieve the windows service installation? We’ve been using nssm, which has worked okay, but I’m curious if there’s a better way of doing it.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#265
post #43

Earlier quoted context omitted.

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.

What is a good secure way to pass a random token to the browser? If the token is part of the URL, which is in the command-line, then it appears other users can see the token. What I do for DomTerm (https://domterm.org) is create a small only-user-readable html file which sets the secret token, and then does a 'location.replace(newkey)' where newkey to an http url to localhost and includes the secret token. I spawn the browser file a file: url, so teh browser can only read the file if it is running as the same user. Better suggestions?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#266

Earlier quoted context omitted.

I think what Deno is great because it lets me be decentralized. We did so much with open source only to throw it all away with npm and go back to a centralized corporate entity :(

package.json supports urls, git urls (and branch + commit ids), even local file paths. If you wanted that, what's stopping you?

[deleted]

Re: Deno 1.6 supports compiling TypeScript to a single executable

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

Yeah, its especially horrible in python for webdev. How are you supposed to deploy django/flask projects when NOT using docker or some PassS? 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.

Pip freeze?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#268

Earlier quoted context omitted.

Is it possible to compile with statically linked musl with the pre-built Rust toolchain on a standard glibc based distribution?

Yes, but there are claims it is slower https://www.reddit.com/r/rust/comments/a6pna3/comment/ebzpzl...

musl is generally not optimized for performance.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#269

Earlier quoted context omitted.

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

A library in any other language is saved local and built with your project.

My understanding is these are loaded from URLs if they are not in the cache. If a domain changes hands, you could be served anything.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#270

Earlier quoted context omitted.

YMMV but I think F# fills that gap nicely

F# is interesting but still pretty different from TypeScript.

creator of TS was a maintainer of F# at microsoft when he created it. I see lots of parallels in the type systems.
Post reply on HN