Deno 1.6 supports compiling TypeScript to a single executable • Hacker News Board

Re: Deno 1.6 supports compiling TypeScript to a single executable

#211

Post by ludwigvan » Thu, Dec 10, 2020, 11:00 AM UTC

Mulpze15 wrote: post #167

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…

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?

See https://bugs.webkit.org/show_bug.cgi?id=171934

I hope they'll fix it soon.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#212

Post by ludwigvan » Thu, Dec 10, 2020, 11:02 AM UTC

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.

Interesting. Are you sure the firewall prompt comes when the server is listening on 127.0.0.1 as opposed to 0.0.0.0?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#213

Post by z3t4 » Thu, Dec 10, 2020, 11:04 AM UTC

mark_and_sweep wrote: post #208

z3t4 wrote: post #195

Earlier quoted context omitted.

Node.js module system (kinda like CommonJS) is what made Node.js popular. ES modules while taking away features like scoped module support and dynamic import, it's very complicated and allows bad practices like include files. Promises are very complicated compared to first class functions. What makes JS/Node hard to grasp is that it's async. Async is an (often unnecessary) optimization, with tradeoffs. Loading module…

> Not everyone wants to use TypeScript. You don't have to use TS. Deno runs plain JS, too. > [TypeScript] will probably become obsolete once optional type annotations gets added to JavaScript. What makes you think that type annotations will be added to JS? I think it's far more likely that browsers and other runtimes will natively support TS as a separate language rather than JS evolving to become TS. > An opinionate…

> What makes you think that type annotations will be added to JS? I think it's far more likely that browsers and other runtimes will natively support TS as a separate language rather than JS evolving to become TS.

It has already been tried with Dart. Dart was made because JS lacked a type system, preventing further optimisations. Support for Dart was added in Chrome.

Another popular JS transpiler is CoffeeScript, most of it's syntax is now in JavaScript.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#214

Post by silverwind » Thu, Dec 10, 2020, 11:24 AM UTC

tarruda wrote: post #206

sandGorgon wrote: post #202

Whoa! Potentially this can make React Native hit the same performance as Flutter+Dart. as the Dart team claimed - https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf > Dart is one of very few languages (and perhaps the only “mainstream” language) that is well suited to being compiled both AOT and JIT. Supporting both kinds of compilation provides significant advantages to Dart and (especially) Flutter.

What this deno feature does is not AOT, but simply packaging the JS as an embedded resource in the executable. JS is still parsed and compiled at runtime.

I guess optimizations like storing the v8 compiler cache format in the binary should be possible.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#215

Post by simias » Thu, Dec 10, 2020, 11:28 AM UTC

pjmlp wrote: post #190

gouggoug wrote: post #184

Earlier quoted context omitted.

I imagine dynamic linking solved a problem for a long time that no longer is: binary size. With internet speeds of today and immense storage sizes, the main attractiveness of dynamic linking vanished.

Not everyone is blessed with such connections, without data caps.

Even then, in general code size is not a significant part of an application's size, various assets are. I'm working on a 10k lines rust application with 74 direct and indirect dependencies and the resulting static binary is less than 3MB in size (less than 1MB xz-compressed). That would've been a significant amount of storage in the 90s but it's almost negligible nowadays.

And given that shared libraries need to be installed and updated separately and they have to ship the entire code of the library (whereas a static binary can be link-time-optimized to get rid of unused code) it might not always be a win in terms of total bandwidth.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#216

Post by nikisweeting » Thu, Dec 10, 2020, 11:28 AM UTC

mark_and_sweep wrote: post #185

nikisweeting wrote: post #109

Earlier quoted context omitted.

Ah cool, that helps a ton. The existence of this feature as the linchpin for compatibility with npm is not clear from the rest of the Deno docs though. Perhaps it could be linked to from this page: https://deno.land/manual@v1.6.0/examples/import_export . Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? "imports": { "moment": "/node_modules/moment/src/moment.js", "l…

> Also, it seems as though ./node_modules/ being the default could be assumed automatically though, no? No, there is no magic node_modules directory in any other JS environment, other than Node. Deno aims to be compatible with web standards. Import and import maps are web standards, require and node_modules aren't. > Deno would be a drop-in replacement and we could move our whole codebase over to it overnight The rea…

Node is the standard web environment, even frontend code is built 90% of the time using Webpack or another bundler running in a node environment and pulling from node_modules.

I don't think you can blame the incumbent tool with complete market dominance for "poor compatibility"...

I really like the direction of the Node compatibility layer though https://deno.land/std@0.80.0/node, I suspect it will be enough to make Deno a drop in replacement soon. Now it just needs support for normal `import` statements from node_modules instead of just `require()`.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#217

Post by nikisweeting » Thu, Dec 10, 2020, 11:30 AM UTC

14u2c wrote: post #158

nikisweeting wrote: post #76

Earlier quoted context omitted.

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…

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_modules? The upshot of that choice is that I'm unlikely to switch to Deno until that's changed (and I suspect that's the case for many other companies as well).

I love the direction the node compatibility layer is going in though https://deno.land/std@0.80.0/node, now I just wish it supported normal import statements from node_modules (not just require()). I'm quite excited about Deno overall, just waiting for it to get to drop-in point.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#218

Post by feanaro » Thu, Dec 10, 2020, 11:36 AM UTC

galaxyLogic wrote: post #113

sciolistse wrote: post #97

Earlier quoted context omitted.

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.

Right. Also each Electron app "comes with a copy of two large software frameworks, Node.js and Chromium" ( https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w... ) Whereas if you build starting from Node.js (or Deno I assume) you can skip the Chromium part. Instead of packaging Chromium with your app you assume that users have a browser and can use that to talk to your app. The benefit of using Node.js is yo…

The additional benefit of this approach is that you can then build your application such that it works with all standards-compatible browsers, such as Firefox.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#219

Post by simias » Thu, Dec 10, 2020, 11:36 AM UTC

pjmlp wrote: post #33

Hokusai wrote: post #21

Earlier quoted context omitted.

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

Same here, the static linking hype feels real strange, given that was the only option we used to have back in the day, and having access to dynamic linking on 16 bit platforms felt like liberating.

I don't really see the hype, I think it's just the intersection of a few factors:

- Languages like Rust which have an ecosystem that evolves very quickly (and uses complex symbol mangling schemes that would break all the time) wouldn't fare very well with dynamic linking in the first place. What good is dynamic linking if you need a different version of your .so file for every binary?

- Dynamic linking is not quite as useful today a it was in the past. Code size is not usually very significant, either on cold storage or in RAM. Actually for RAM it's cache usage that matters most, and static linking can usually be more efficient here through LTO.

- Over the past ~2 decades a new generation of developer arrived and many of them (in my experience) barely use "low level" compile-to-machine-code languages. They often specialize in scripting languages or languages that require a framework. Some of these developers are now learning Go or Rust and for them the idea of shipping a single ELF binary that packages the entire app might be seen as a novelty or maybe even as an innovation.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#220

Post by feanaro » Thu, Dec 10, 2020, 11:42 AM UTC

cjonas wrote: post #155

jjnoakes wrote: post #70

Earlier quoted context omitted.

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

Wouldn't proper CORS be enough? I guess you would have to avoid putting any sensitive data in GET requests

No, because CORS can only restrict which origins (scheme, domain, port combinations) are able to access the site's data. But you're not even connecting from a web origin but from localhost and you're trying to defend from all access except by your frontends. For this, you need a shared secret between the server and the frontend.

A further limitation of CORS is that certain requests are allowed even if they are not from an allowed origin.

To conclude, you definitely need a secret.