Live data from Hacker News

Deno 1.6 supports compiling TypeScript to a single executable

github.com

231–240 of 284 posts

Re: Deno 1.6 supports compiling TypeScript to a single executable

#231
post #151
post #145

Earlier quoted context omitted.

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

Why anyone would look at the litany of mistakes that is npm and Node, then look at Deno and all of the same developers learning nothing except how to implement its "hurr durr URL loading code is cool" approach to security and think "this a good idea" is beyond me. I appreciate Deno because I can ask job interview candidates what their thoughts are about it, and when candidates for senior positions don't point out any…

Based of this I don't think anyone genuinely senior (or not) would want to work for you with your insane biases.

So win-win, Your happy, they are happy.

Re: Deno 1.6 supports compiling TypeScript to a single executable

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

ES Modules have dynamic imports ( https://github.com/tc39/proposal-dynamic-import ). The proposal is at stage 4 and is available from Typescript 2.4. We're on version 4 now so I'd expect Deno to have it. I'm not sure what you mean by "bad practices like include files" so I can't comment on that. I've found most Javascript developers prefer the await syntax with promises to using callbacks. It gives the code the appea…

Really like async await. The only case ive found for callbacks is for the top level function call in a script. Calling ".then()" is useful since top level await is still not a thing, and may never be.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#233
post #48

Earlier quoted context omitted.

I'm pretty sure multicore was a thing in 2009, though.

It was, and since 2009 the recommendation has been to run an instance of nodejs per CPU core. The justification is that if you're already scaling your app between servers, you shouldn't need a separate mechanism to scale across multiple cores in a single server. I'm not sure when the cluster API was added, but its been in nodejs's core for a long time. (Not that you need to use it, but still.) https://nodejs.org/api/…

yeah `pm2` has even made this painless since (many years ago)

Re: Deno 1.6 supports compiling TypeScript to a single executable

#234

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…

I would probably just vendor them into my own directory structure and import them as a local module. You lose automatic updating, but I'm not sure I want that anyhow. A script that goes looking for new versions of 3rd party modules would be fairly trivial I think.

>You lose automatic updating, but I'm not sure I want that anyhow.

I'm getting on this boat after mongoose changed its type definitions and ruined a whole morning of work for me.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#235
post #232

Earlier quoted context omitted.

ES Modules have dynamic imports ( https://github.com/tc39/proposal-dynamic-import ). The proposal is at stage 4 and is available from Typescript 2.4. We're on version 4 now so I'd expect Deno to have it. I'm not sure what you mean by "bad practices like include files" so I can't comment on that. I've found most Javascript developers prefer the await syntax with promises to using callbacks. It gives the code the appea…

Really like async await. The only case ive found for callbacks is for the top level function call in a script. Calling ".then()" is useful since top level await is still not a thing, and may never be.

Top level await is at stage 3: https://github.com/tc39/proposal-top-level-await

Its in Typescript 3.8, Node 14.8 and probably in your Babel setup. I probably wont get to use Node 14 in prod for a while but I get by with a `main` function that has everything in that gets called at the bottom.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#236
post #145
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…

What I like about not integrating the build-step as Deno does: You allow competition and the market comes up with great ideas like Vercel did with pkg. Building TS projects is quite demanding and I doubt if one party monopolizes this important step and thinks it does the best job it will degenerate an ecosystem. Even the TS team says the build system is not the core of their work, they just have one for convenience b…

If it's good that we have these options, what Deno provides is just another option for us to choose from. I don't see how this is a shut-down for the ecosystem.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#237

Earlier quoted context omitted.

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.

I may misunderstand the thread, but it looks to me like they don't want to fix it, even though it is the spec, and other browsers do follow it.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#238

Earlier quoted context omitted.

Last time I checked jQuery was used on 9 out of 10 websites using JS with 8 out of 10 websites being powered by PHP. How dare Node not be compatible with the market dominating jQuery! Silly server-runtime not having a browser window object! > Now it just needs support for normal `import` statements from node_modules Deno will never ever do that (other than by using standardized import maps) since that's not normal (n…

I don't understand, jQuery works fine in node-built environments. Obviously any DOM mutation stuff stuff needs to happen in the frontend when it runs in the browser, but you can absolutely import jquery and use parts of it during server-side compiling or rendering steps in node. import $ from "jquery" > Deno will never ever do that Why would Deno take such an antagonistic approach to supporting the most common setup…

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.

In Deno the gap is much closer. Obviously, the Deno namespace is not available in the browser (but there's a shim for most APIs, e.g. Deno.writeFile and readFile are implemented with a virtual FS) and some web APIs are not available in Deno (yet), but the compat story is much better.

This is no surprise since web compat is a core goal of Deno. Node compat is not.

> Wouldn't it be trivial to just fall back to checking node_modules for named packages?

No, the resolution algo is not trivial (nor performant). Also, it's not necessary: There is already a standard for how to import code in JS; it's import statements. Import statements do not allow named packages, e.g. import $ from "jquery" does not work in the browser. Except, again, import maps.

Re: Deno 1.6 supports compiling TypeScript to a single executable

#239
post #55

Earlier quoted context omitted.

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?

I'm not actually sure in which cases the prompt happens these days - I meant that to be part of what I was asking but didn't word it very well. Hopefully listening on 127.* doesn't trigger it!

Re: Deno 1.6 supports compiling TypeScript to a single executable

#240

Earlier quoted context omitted.

I don't understand, jQuery works fine in node-built environments. Obviously any DOM mutation stuff stuff needs to happen in the frontend when it runs in the browser, but you can absolutely import jquery and use parts of it during server-side compiling or rendering steps in node. import $ from "jquery" > Deno will never ever do that Why would Deno take such an antagonistic approach to supporting the most common setup…

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.

Post reply on HN