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

271–280 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#271

Post by aabbcc1241 »

ausjke wrote: post #152
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…

in this case why not just use go-binary as the backend? go is natively designed to be single executable and you don't need any package tools, and it does everything node.js can do on your OS while using your browser as a GUI frontend.

Except you'll have to develop with another ecosystem of packages and cannot do generic programming "natively".

Re: Deno 1.6 supports compiling TypeScript to a single executable

#272

Post by aabbcc1241 »

echelon wrote: post #9
mrkurt wrote: post #2

This is such a good feature. Go has been great for shipping single purpose binaries (like the CLI for https://fly.io ), but I really enjoy writing TypeScript more than Go.

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.

The single binary still have to embed the runtime somehow. So the container size would be similar?

Except the single bundle trimmed off unused part from the standard runtime

Re: Deno 1.6 supports compiling TypeScript to a single executable

#273

Post by Riverheart »

kumarvvr wrote: post #90

I wonder if it's possible for TypeScript to be a .NET CLR supported language. It would be great to have a powerful scripting language for the .NET Ecosystem. I know C# can be used for scripting, but I want something like Python, an easy to use, dynamic language that has the performance of the .NET VM

It exists and is called Powershell

Re: Deno 1.6 supports compiling TypeScript to a single executable

#274

Post by yashap »

205g0 wrote: post #140
yashap wrote: post #133

Earlier quoted context omitted.

Even server side, not everyone uses Docker. If you’re deploying to EC2, in house hardware, whatever, a single executable is simpler. And even if you’re building a Docker image, building the image itself is still a bit simpler - just pop the executable in there, and have the Docker entry point execute it, that’s it. Then obviously for CLI tools, this is SUPER nice.

Yes and no, these are amenities but they are really small and IDK if they justify hiding/abstracting way an import build step. > Even server side, not everyone uses Docker. IDK, tried to find alternatives the last years but for a bit more sophisticated app you can't ignore images and container orchestrators like k8s. And latter is still easier than anything I've seen and has by far the biggest ecosystem. If I want to…

I like K8s too, especially for a service oriented architecture, but there’s tonnes of other deployment targets out there. I’d bet the overall percentage of server side software running on K8s is in the single digits, thought that’s a pure wild ass guess. Hours ago I just finished debugging an outage where requests to one K8s service, through K8s ingress, slowed down 10x after an insignificant deploy, and then we cycled the pods (without changing the code) and it sped up again. No idea why - K8s is complex, and many ppl choose not to take on that complexity. TONNES of people like being able to deploy a single executable to their servers, it’s part of Go’s popularity, part of the popularity of fat jars in Java land (and those still need a JVM!), etc.

As for CLIs, the Deno executable overhead is about 47 MBs. Not nothing, but also ... that’s like a few extra seconds of download time for the tool, and insignificant disk space when people have hundreds of GBs on their laptops. If I’m writing some sort of command line tool, the tool being 50 MBs bigger probably does nothing to hurt adoption. But it having zero external dependencies WILL help adoption, vs. npx and screwing around with proper node versions and whatnot.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#275

Post by egeozcan »

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 did the same but used a server coded in go[0], I don't think it's a security problem as long as you take the standard security measures that apply to any web server. Mine is something that just scratches my itch so I explicitly enabled cors (if a malicious website can guess the endpoint, it's possible to get my stupid dev logs as JSON during the times this logger is running).

[0]: https://github.com/egeozcan/json-tail

Re: Deno 1.6 supports compiling TypeScript to a single executable

#276

Post by miohtama »

zubairq wrote: post #103
miohtama wrote: post #83

Earlier quoted context omitted.

WebAssembly fixes this.

Not really as the WASM version of Sqlite is memory only and cannot write to disk. Please feel free to correct me if this has changed though

WASI fixes this https://wasi.dev/

Re: Deno 1.6 supports compiling TypeScript to a single executable

#277

Post by nikisweeting »

mark_and_sweep wrote: post #263
nikisweeting wrote: post #217

Earlier quoted context omitted.

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

I know I sound like a broken record at this point, but wouldn't it be helpful if Deno just built something like this in automatically to make those import maps given a lockfile:

https://www.npmjs.com/package/@import-maps/generate/v/0.1.0

This way you'd get both the benefits of web standards compliance with the generated explicit import maps, and backward compatibility and ease-of-migration for npm/yarn users.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#278

Post by nikisweeting »

wperron wrote: post #247
nikisweeting wrote: post #98

Earlier quoted context omitted.

I am not proposing that Deno remove URL support, I think it's great that they allow importing from URL as an option. I just wish they also supported importing from local npm packages installed in node_modules without needing to specify a URL/full path. This would allow full inter-compatibility with the existing packaging ecosystem and allow people to continue using whatever packaging method they prefer.

_If_ the node library uses explicit file imports, and ESM instead of CJS, it _is_ already possible to just do `npm install` and import from "./node_modules" -- again the problem is that Node's import resolution algorithm is horribly complex and not very explicit, but it's possible to be explicit using Node, and that would make it compatible in Deno

Considering you can generate the import maps from a given npm/yarn lockfile (https://www.npmjs.com/package/@import-maps/generate/v/0.1.0) wouldn't it be possible for Deno to provide a command to do this and get the benefits of both backward npm/yarn compatibility and forward web compatibility with import-maps?

Re: Deno 1.6 supports compiling TypeScript to a single executable

#279

Post by laurencerowe »

jay_kyburz wrote: post #269
Soremwar wrote: post #164

Earlier quoted context omitted.

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.

Presumably you’d use deno bundle for a production build so you’re not directly using the source files.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#280

Post by anchpop »

int_19h wrote: post #193
SiVal wrote: post #77

Earlier quoted context omitted.

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

Unfortunately, that's not a very accurate analogy. TS also inherits all of JS runtime semantics unchanged, and there's just as much if not more wrongness there.

I wish for a version of TS where I could have === automatically rewritten to use _.isEqual, that way [1,2,3] === [1,2,3] would return true.
Post reply on HN