Deno 1.0 • Hacker News Board

Re: Deno 1.0

#81

Post by xg15 » Wed, May 13, 2020, 11:49 PM UTC

mrkurt wrote: post #54

pedalpete wrote: post #44

Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules? I'm sure I'm missing something obvious in that example, but that capability terrifies me.

It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. It's also exactly what the websites you visit do. ;)

> It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it.

I'm not sure how this works in detail here, but at least in NPM you got a chance to download packages, inspect them and fix the versions if so desired. Importantly, this gave you control over your transitive dependencies as well.

This seems more like the curl | bash school of package management.

Edit: This is explained in more detail at https://deno.land/manual/linking_to_external_code and indeed seems a lot more sane.

> It's also exactly what the websites you visit do. ;)

Well yes, and it causes huge problems there already - see the whole mess we have with trackers and page bloat.

Re: Deno 1.0

#82

Post by XCSme » Wed, May 13, 2020, 11:50 PM UTC

Saaster wrote: post #62

frank2 wrote: post #56

Earlier quoted context omitted.

Does it also terrify you when code running in a browser does it?

The code running in my browser isn't a multi-tenant production server, with access to the filesystem and DBs.

I think that's the main selling point of deno, sandboxing.

Re: Deno 1.0

#83

Post by weeksie » Wed, May 13, 2020, 11:51 PM UTC

This is super effing awesome.

You know what would be extra amazing? Incorporating (at some point in the future) all of the very smart stuff that the unison people have been doing. That would be _tremendous_ for code re-use and guarantees about remote packages. What I wouldn't give for a JS vm that could do all that. . . .

* https://www.unisonweb.org/docs/tour

Re: Deno 1.0

#84

Post by _bxg1 » Wed, May 13, 2020, 11:51 PM UTC

So it's an alternative to Node? Sounds incredibly cool, honestly. This:

> Supports TypeScript out of the box.

Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).

Re: Deno 1.0

#85

Post by squid_demon » Wed, May 13, 2020, 11:52 PM UTC

And the very first line of sample code is adding a dependency on someone else's code.

Reminds me of https://npm.anvaka.com/#/view/2d/react-native

Good luck, though. Everyone lives in a different (mental) tribe I suppose...

Re: Deno 1.0

#86

Post by hombre_fatal » Wed, May 13, 2020, 11:52 PM UTC

rosywoozlechan wrote: post #61

VWWHFSfQ wrote: post #50

Earlier quoted context omitted.

LuaJIT is nearly 3x faster than V8 JavaScript the last time I checked. Just anecodal DDG search [0]. Maybe V8 has gotten faster since the last time I checked. [0] https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...

Lua also has a smaller footprint I think.

It has a worse standard library than Javascript. And its static typing solutions don't compare to Typescript.

Re: Deno 1.0

#87

Post by xg15 » Wed, May 13, 2020, 11:52 PM UTC

afiori wrote: post #72

Saaster wrote: post #60

Earlier quoted context omitted.

Does Deno have some built in way to vendor / download the imports pre-execution? I don't want my production service to fail to launch because some random repo is offline.

Deno caches local copies and offer control on when to reload them. in term of vendoring you can simply download everything yourself and use local paths for imports.

How would this work with transitive dependencies? Sure I can control which parts I import myself, but how do I keep a vendored file from pulling in another URL a level deeper?

Re: Deno 1.0

#88

Post by ignoramous » Wed, May 13, 2020, 11:53 PM UTC

gen220 wrote: post #32

For context: Deno's lead is Ryan Dahl, the creator of Node. In the past, Dahl's expressed regrets over choices he made early on in Node's development, and on the direction Node has gone since he left the project many years ago. He bravely presented on this topic at jsconf eu, 2018: https://www.youtube.com/watch?v=M3BM9TB-8yA , it's a fantastic talk. The last 10 minutes are a pitch for what a "better Node" would look…

> The last 10 minutes are a pitch for what a "better Node" would look like, if he were to start from scratch in 2018.

Is it fair to say (a managed) deno is what Cloudflare Workers is? If not, what would be key differences between them?

Re: Deno 1.0

#89

Post by uryga » Wed, May 13, 2020, 11:53 PM UTC

cryptica wrote: post #59

>> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow. >> We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust. Funny, I was just talking about something like this in…

> I don't understand why Microsoft doesn't have their own native TypeScript runtime engine by now

what would they do with it? ship it in Edge? great, now some small fraction of users can run TS natively. but most can't, so everyone would still transpile to JS anyway...

it could work if Google did it, but i don't think MS has enough market share to have an influence here

Re: Deno 1.0

#90

Post by ignoramous » Wed, May 13, 2020, 11:56 PM UTC

firloop wrote: post #10

For the uninitiated, worth noting that one of the names on this post, Ryan Dahl, was the original node.js developer.

Also for the uninitiated, fly.io is migrating to deno for their Serverless functions: https://news.ycombinator.com/item?id=22621926