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

State of the Web: Deno

byteofdev.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: State of the Web: Deno

#61

Post by wtfrmyinitials »

eyelidlessness wrote: post #6
galaxyLogic wrote: post #3

Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly? I find sync is often simpler to code for.

Because the ESM standard specifies that modules are loaded by URL and themselves might initialize async. Once anything is async the whole call stack into it is. See also various discussions of “colored functions” which have made the rounds again recently.

This is inaccurate, or at least misleading. Your code doesn’t begin executing until all of the modules are loaded so it doesn’t “make the call stack async” just because of the import system. Module loading that’s async from the point of view of user code is also supported, but it’s use is rare.

Re: State of the Web: Deno

#63

Post by Longwelwind »

dmitriid wrote: post #57
lucacasonato wrote: post #41

Earlier quoted context omitted.

And we have lock files to verify integrity. This is no different to module loading in Node. If you don’t trust your registry, you should not be loading code from it!

> And we have lock files to verify integrity. Where do you et these lockfiles files from? > This is no different to module loading in Node. This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936 > If you don’t trust your registry, you should not be loading code from it! So you immediately pinpointed the difference: with Node I can run my own registry and easily set up n…

> Where do you et these lockfiles files from?

At dev time, you generate a lock file of the hashes of your dependencies. You commit this file to your code repository.

When getting dependencies, the hash of the downloaded dependency is compared to the one in the lockfile.

Re: State of the Web: Deno

#64

Post by lucideer »

goldsteinq wrote: post #19
killingtime74 wrote: post #18

Earlier quoted context omitted.

As a non-js dev, is it better than Node?

It’s arguably worse than Node because Node doesn’t pretend to provide any security. With Deno you may be tempted to think that permission to run specific command actually means that program can’t run some other command (it can, and doing this doesn’t even require _clever_ hacks: Deno uses binary name instead of the full path in it’s permission system, so you only need to change $PATH for the child process).

The Deno docs say:

> make sure you carefully consider if you want to grant a program --allow-run access: it essentially invalidates the Deno security sandbox

Saying Deno shouldn't "pretend" (or attempt) to provide more security because a non-default flag invalidates the sandbox (as stated clearly in the docs for that flag) seems slight hyperbole.

It would admittedly be cool if we could use this flag securely (though I'm sure the implementation complexity would be significant, and more code surface area is never nice to audit).

Re: State of the Web: Deno

#65

Post by dmitriid »

Longwelwind wrote: post #63
dmitriid wrote: post #57

Earlier quoted context omitted.

> And we have lock files to verify integrity. Where do you et these lockfiles files from? > This is no different to module loading in Node. This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936 > If you don’t trust your registry, you should not be loading code from it! So you immediately pinpointed the difference: with Node I can run my own registry and easily set up n…

> Where do you et these lockfiles files from? At dev time, you generate a lock file of the hashes of your dependencies. You commit this file to your code repository. When getting dependencies, the hash of the downloaded dependency is compared to the one in the lockfile.

> At dev time, you generate a lock file of the hashes of your dependencies.

So. At dev time. You download random files from random urls via Deno.

Compared to: At dev time you download files from a trusted repository. https://news.ycombinator.com/item?id=29871936

Re: State of the Web: Deno

#66

Post by dmitriid »

vorticalbox wrote: post #60
dmitriid wrote: post #57

Earlier quoted context omitted.

> And we have lock files to verify integrity. Where do you et these lockfiles files from? > This is no different to module loading in Node. This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936 > If you don’t trust your registry, you should not be loading code from it! So you immediately pinpointed the difference: with Node I can run my own registry and easily set up n…

> Where do you et these lockfiles files from? I don't know about any lock files but the `version` it locked via the import url E.G import R from ' https://deno.land/x/rambda@v7.0.1 '

This brings us back to the fact that Deno loads random files from random URLs with no way to change it. https://news.ycombinator.com/item?id=29871936

Re: State of the Web: Deno

#67

Post by skinkestek »

goldsteinq wrote: post #50
skinkestek wrote: post #44

Earlier quoted context omitted.

Lots of weasel words here and you don't answer directly. It still seems to me that a Deno script running with necessary permissions will be a huge hurdle compared to running a Node script which by default has al permissions. Edit : Also I'm seriously fed up with tech community cr#pping at everything good because it isn't perfect. Today with Node any random package can download any DLL as long as it is novel enough to…

I did answer directly: this exploit requires run permission with any argument and write permission to any directory. It allows malicious script to escape sandbox and execute arbitrary code outside of it.

> this exploit requires run permission with any argument and write permission to any directory. It allows malicious script to escape sandbox and execute arbitrary code outside of it.

I suppose you wrote something wrong here and I'm interested in knowing what.

Because as it stands now I read it falls down to: "If you open the permission system up extremely wide you can get exploited."

Alternatively, after thinking for a couple of minutes I can read it as "if you simultaneously allow run permission with anything and write permission with anything".

In the last case it is slightly more problematic, but if one allows a script to execute anything that is itself a huge red flag.

... and on Node this red flag is always flying by default.

Re: State of the Web: Deno

#68

Post by oefrha »

skrebbel wrote: post #54
usea wrote: post #46

Earlier quoted context omitted.

Painting any criticism of deno as simply the work of haters is much more a tactic of stopping thought. Whether or not ideas and discussion are negative or positive is not relevant at all. When they're presented in some detail and in good faith, we should tackle them in turn. This encourages thought, discussion, and understanding among all.

GP's comment is in a thread that starts with "Deno’s permission system is broken, you shouldn’t rely on it". Not relying on Deno's permission system will, in practice, mean just allowing everything or using Node instead of Deno. I can't for the love of god understand why that's better than using a permission system that provides some more protection than just about any other currently-commonly-used backend dev platfo…

Root comment literally ended with

> If you want to isolate a program, you need to do it on the OS level.

Commenter further suggested bubblewrap and firecracker elsewhere in the thread.

“Just allow everything” is a straw man you pulled out of nowhere.

Re: State of the Web: Deno

#69

Post by rcxdude »

skrebbel wrote: post #54
usea wrote: post #46

Earlier quoted context omitted.

Painting any criticism of deno as simply the work of haters is much more a tactic of stopping thought. Whether or not ideas and discussion are negative or positive is not relevant at all. When they're presented in some detail and in good faith, we should tackle them in turn. This encourages thought, discussion, and understanding among all.

GP's comment is in a thread that starts with "Deno’s permission system is broken, you shouldn’t rely on it". Not relying on Deno's permission system will, in practice, mean just allowing everything or using Node instead of Deno. I can't for the love of god understand why that's better than using a permission system that provides some more protection than just about any other currently-commonly-used backend dev platfo…

Because illusory protection is worse than no protection. if it doesn't actually provide any protection against malicious code in practice then the only thing it can give you is a false sense of security.

Re: State of the Web: Deno

#70

Post by forty »

wruza wrote: post #43
forty wrote: post #24

Earlier quoted context omitted.

My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.

What's the real problem with 100 dependencies and size of a folder? I can name only non-cached install time, which is irrelevant for a regular developer. What is "shitty"? Do we have something better than that? Like one big web framework which is both maintainable, DCE-able and solved everything frontend ever needs? Why further modularization of this theoretical module would be shitty? Edit: Also, what are we compari…

I don't mind 100 dependencies maintained by a single large community/project. I hate 100 dependencies each maintained (or not maintained) by single amateur devs (not negative to be clear, I just mean they are not paid for this).
Post reply on HN