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

111–120 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#111

Post by josephg »

I really like this.

I've been thinking a lot over the last few years about Docker. Arguably docker is just another abstraction for "statically linked executable". But we've had static executables for years; and they work well, and the ABI for the linux kernel is very stable. So increasingly I'm not convinced docker is worth it, compared to just building and deploying bundled executables. And executables can be run anywhere, they don't need a separate testing environment, they can be debugged easily[1], and so on.

[1] Well, if you like systemd or have a reasonable replacement.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#112

Post by Sephr »

tracker1 wrote: post #104
miohtama wrote: post #83

Earlier quoted context omitted.

WebAssembly fixes this.

webassembly doesn't support file locking for sqlite databases that would allow for other processes to interact with the same database your application uses. It's actually one of my biggest gripes. You can use it in-memory and save the output or use a different database approach, and lose the features of sqlite. Of course, a different kind of database, similar to say leveldb could work in single-process mode.

WebAssembly supports threads and shared memory, which should make it possible to implement software-based locks in the meantime. I definitely see the issue that you're bringing up, especially wrt external interoperability.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#113

Post by galaxyLogic »

sciolistse wrote: post #97
yboris wrote: post #58

Earlier quoted context omitted.

> It is more flexible than say Electron because GUI can be anything I want it to be. Feels like one of us is misunderstanding something. Electron lets you run any web technology - so when users open your app, they are greeted with whatever you can show on a webpage. You can also have Electron run in the background as a server if that's something you're into ;)

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 you don't have to use a different language for the backend. It helps.

BTW. "Electrino" in the linked-to article seems interesting too.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#114

Post by galaxyLogic »

j1elo wrote: post #46
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…

> My concern is only will users accept a local server running on their desktop I would say that users don't mind. They want a working application, that does what it promises, and is dependable. Things like having an underlying server is just an implementation detail, nobody really cares (talking about the big public here, not the more technical users of HN who might have a say about the technology choices, but are ov…

Right. One additional complication might be that some web-tech in the browser may require https, which would bring its own complications with security certificates.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#115

Post by tracker1 »

christophilus wrote: post #99
bartlomieju wrote: post #32

Hey, Bartek from deno.land here. I'll be more than happy to answer your questions about Deno and its development.

Last I looked, there was no clear crypto story for Deno. Has that improved, or are there any concrete plans for it? Deno was really quite nice when I kicked the tires, but didn't seem quite ready for prime time web development with no crypto functions.

Not yet[1] likely to see WebCrypto first and/or something similar to Node's crypto library. You could probably get away with wasm build of a C/C++ or Rust library if you don't mind getting dirty.

1. https://github.com/denoland/deno/issues/1891

edit:

partial webcrypto/wasm option already available

https://deno.land/x/god_crypto@v1.4.1

Re: Deno 1.6 supports compiling TypeScript to a single executable

#116

Post by galaxyLogic »

jjnoakes wrote: post #70
Couto wrote: 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.

That's a good trick. Thanks for the tip.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#117

Post by galaxyLogic »

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.

I can see that could be an issue. I guess one solution is to make sure users understand that that is going to happen.

These days everybody is used to their smartphone asking things like "Do you want to allow App-X to use your microphone" etc.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#118

Post by andyfleming »

rodrigoj42 wrote: post #95
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

YMMV but I think F# fills that gap nicely

F# is interesting but still pretty different from TypeScript.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#120

Post by galaxyLogic »

bartlomieju wrote: post #45
nikisweeting wrote: post #42

Earlier quoted context omitted.

Last time I tried deno there was some friction with depending on npm packages that didn't natively support deno without vendoring, is that easier nowadays? Can we seamlessly import anything from npm inside deno-run code and use the deno stdlib side-by-side with node_modules code? We love the Deno direction and would even willing to donate $ to grow its development, but for us it's pretty much non-starter to switch to…

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…

That is interesting. Does it mean I will be able to run my Node.js program on Deno? That would be really huge in terms of letting users migrate from Node.js to Deno.
Post reply on HN