Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.0

deno.land

Post reply on HN
Print view View original

101–110 of 598 posts

Re: Deno 1.0

#101

Post by mrkurt »

eyelidlessness wrote: post #92
mrkurt wrote: post #54

Earlier quoted context omitted.

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. This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NP…

That is a fair point. I don't think most people who use npms really pay much attention, though, and you're still just an npm update away from getting something unexpected (because really, who puts explicit versions in package.json?).

Deno does have lockfiles: https://deno.land/manual/linking_to_external_code/integrity_...

I prefer imports from URLs. And I loathe npm. I get why people would disagree though.

Re: Deno 1.0

#102

Post by TypeCaste »

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 just hate having to debug mangled transpiled code and dealing with sourcemaps. I want to be able to run and debug my own code, not some alternative mangled version of it.

Look into ts-node. It lets me run and debug the TypeScript itself before transpiling it.

Re: Deno 1.0

#103

Post by megavolcano »

eyelidlessness wrote: post #92
mrkurt wrote: post #54

Earlier quoted context omitted.

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. This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NP…

Deno has lock files and caches files locally on first import.

Re: Deno 1.0

#104

Post by 0xCMP »

eyelidlessness wrote: post #92
mrkurt wrote: post #54

Earlier quoted context omitted.

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. This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NP…

For Deno the only issue is the first time when you do not have it cached. Deno compiles in all dependencies when building so the only point of failure is the machine you’re building on.

I don’t know the state of the art anymore, but I’m sure they have ways to make it easy to vendor deps in the repo.

Re: Deno 1.0

#105

Post by mrkurt »

_bxg1 wrote: post #84

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

Yes it's great! My deno projects are really simple directories, `deno run server.ts` is nice and tidy.

Re: Deno 1.0

#106

Post by steveklabnik »

ignoramous wrote: post #88
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?

PM on part of Cloudflare Workers and someone who was in physical attendance for this talk here.

They're not really directly comparable other than "A JavaScript runtime built on top of V8."

Workers doesn't support TS directly, though you can compile TS to JS and run it, of course. (My team maintains a worker and this is what we do, and it works well)

Deno has its own APIs, as does Workers. Worker's main API is the Service Worker API, Deno's is not.

Workers is focused on V8 isolates as a means of achieving multi-tenency. I don’t believe Deno does anything specific here.

Deno is mostly implemented in Rust, the Workers runtime is written in C++.

Deno is open source, Workers is not.

Workers is being used at scale in production, Deno just launched its 1.0.

I am very excited to see what happens with Deno. :) Fun history: I had been dreaming about doing "Chakra Core + Tokio" a few years back, but didn't find the time. I'm skeptical of the dependency approach Deno is taking, we'll see what happens!

Re: Deno 1.0

#107

Post by gunn »

_bxg1 wrote: post #84

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

You'll like https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript

Re: Deno 1.0

#108

Post by mrkurt »

xg15 wrote: post #81
mrkurt wrote: post #54

Earlier quoted context omitted.

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

The tldr is Deno also gives you a chance to download + inspect packages, and then lock dependencies. The mechanism for import is different, but the tooling is good.

Re: Deno 1.0

#109

Post by tvbusy »

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.

deno requires that you give the process explicitly which permissions it has. I think it's much better than praying that a package has not gone rough like with node. If you don't trust the remote script, run it without any permission and capture the output. Using multiple process with explicit permissions are much safer.

Re: Deno 1.0

#110

Post by mrkurt »

hombre_fatal wrote: post #78
yawn wrote: post #71

Earlier quoted context omitted.

From the article: "Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission."

That just means you have to run with the -http -fs, etc. flags. But you are using those when writing any nontrivial Deno app like a webserver anyways. "web browsers already do this ;)" isn't a good comparison.

"But I have to turn all that stuff on" is also not a good comparison.

Actually, no Deno webserver I've written gets fs access. Some only get --allow-net.

Post reply on HN