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

91–100 of 116 posts

Re: State of the Web: Deno

#91

Post by synergy20 »

_jplc wrote: post #86
synergy20 wrote: post #81

Earlier quoted context omitted.

nice to have ts+linter+formatter together, it took me one or two hours to set up with my own vim(using vite/volar), so it saves me some time. what I really like a new Node.js(e.g. deno) is actually its module system, I don't like the `npm i` in node.js pulls hundreds of modules, a standard library that contains most commonly needed modules is the key. If deno does not do that, I probably will never try that(as I can…

In Deno's case, there are two things: Deno API, which comes bundled with Deno and is present globally, always, without importing: https://doc.deno.land/deno/stable . Includes basic stuff like stdin, stdout, stderr, file management... etc and standard Web APIs like Fetch API, web assembly interoperability, localStorage, FormData, TextEncoder/TextDecoder, etc. Deno std lib, an official library that presents what you co…

So what's Deno's stdlib principle:

    1. you got pretty much 80% of what you will need from the std libraries for a mid-size 'normal' application(similar to glibc, libstdcpp, go stdlib, python's stdlib)
    2. you got a small stdlib than usual(rust's stdlib), the rest you use cargo and good luck with that
    3. you grab whatever you need(node.js, you have no idea about the 500 modules npm just installed)
I prefer No.1 here.

Re: State of the Web: Deno

#92

Post by CodesInChaos »

synergy20 wrote: post #91
_jplc wrote: post #86

Earlier quoted context omitted.

In Deno's case, there are two things: Deno API, which comes bundled with Deno and is present globally, always, without importing: https://doc.deno.land/deno/stable . Includes basic stuff like stdin, stdout, stderr, file management... etc and standard Web APIs like Fetch API, web assembly interoperability, localStorage, FormData, TextEncoder/TextDecoder, etc. Deno std lib, an official library that presents what you co…

So what's Deno's stdlib principle: 1. you got pretty much 80% of what you will need from the std libraries for a mid-size 'normal' application(similar to glibc, libstdcpp, go stdlib, python's stdlib) 2. you got a small stdlib than usual(rust's stdlib), the rest you use cargo and good luck with that 3. you grab whatever you need(node.js, you have no idea about the 500 modules npm just installed) I prefer No.1 here.

Isn't the scope of the standard library of C and C++ close to the scope of the Rust standard library (an thus much smaller than python's)?

Re: State of the Web: Deno

#93

Post by dmitriid »

Longwelwind wrote: post #73
dmitriid wrote: post #65

Earlier quoted context omitted.

> 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

NPM is not a trusted repository, I think. There are no checks done to the content of the packages uploaded by users. It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities. If you use a lockfile, downloading a package from NPM or directly using a random URL is conceptually the same, since they are both untrusted sources. Having a lockfile will ensure that if you download…

> NPM is not a trusted repository

It's not. But it's rather trivial to run your own registry, and many (most?) companies do exactly that.

> It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities.

That's why, again, many companies run their own registries, and don't download random files from the internet.

> Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.

And to generate that lockfile... you need to first download a random file from the internet. Got you.

Re: State of the Web: Deno

#94

Post by synergy20 »

CodesInChaos wrote: post #92
synergy20 wrote: post #91

Earlier quoted context omitted.

So what's Deno's stdlib principle: 1. you got pretty much 80% of what you will need from the std libraries for a mid-size 'normal' application(similar to glibc, libstdcpp, go stdlib, python's stdlib) 2. you got a small stdlib than usual(rust's stdlib), the rest you use cargo and good luck with that 3. you grab whatever you need(node.js, you have no idea about the 500 modules npm just installed) I prefer No.1 here.

Isn't the scope of the standard library of C and C++ close to the scope of the Rust standard library (an thus much smaller than python's)?

nope, I was told rust prefers to a light stdlib approach.

Re: State of the Web: Deno

#95

Post by dmitriid »

vorticalbox wrote: post #74
dmitriid wrote: post #66

Earlier quoted context omitted.

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

sure but is that not how a browser works? for example to add bootstrap to a site you import like this https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstr... " integrity="sha384-ka7Sk0Gln4gmtz2MlQnikT1wXgYsOg+OMhuP+IlRH9sENBO0LRn5q+8nbTov4+1p" crossorigin="anonymous"> which is exactly the same as deno's "loads random files from random URLs"

> sure but is that not how a browser works?

Deno is not a browser.

> for example to add bootstrap to a site you import like this

I know how to import a file in a browser. However, Deno is not a browser. The whole subthread is about managing dependencies, which Deno fails at, and its proponents come up with the most ridiculous things to justify it.

Re: State of the Web: Deno

#96

Post by a99c43f2d565504 »

Node.js fully supports ECMAScript modules as they are currently specified and provides interoperability between them and its original module format, CommonJS. Authors can tell Node.js to treat JavaScript code as ECMAScript modules via the .mjs file extension, the package.json "type" field, or the --input-type flag.

Re: State of the Web: Deno

#97

Post by eyelidlessness »

wtfrmyinitials wrote: post #61
eyelidlessness wrote: post #6

Earlier quoted context omitted.

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.

> This is inaccurate, or at least misleading.

No it’s not.

> Your code doesn’t begin executing until all of the modules are loaded.

This is inaccurate, or at least misleading.

This, or some aspect of it, is both possible and relatively common:

  import foo from 'foo';

  await foo.bar();

  await Promise.all([
    import('other'),
    import('stuff'),
  ]);

  // Admittedly this is less common but also valid!
  import yet from 'more-stuff';
The asynchrony of ESM was controversial before it even became a standard. But it’s necessary because it allows network I/O. And most of the above patterns being relatively common is one of the major use cases for bundling, because it also introduces an indefinite waterfall.

In terms of rarity, dynamic import calls are already quite common for “lazy”/“suspense” or their equivalents in quite a lot of real world code, and likely to become moreso with React Server Components and other similar solutions deferring to server rendering.

Yes, an import statement is [semantically] blocking. But even so it’s important to know that it’s performing async I/O.

Re: State of the Web: Deno

#98

Post by eyelidlessness »

wruza wrote: post #45
eyelidlessness wrote: post #6

Earlier quoted context omitted.

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.

Why doesn't nodejs just make modules async? // main.js const fs = require("fs") const foo = await require_async("foo") await foo.sleep(1000) // other.js require("./main.js") // RequireError: main.js returned an unsettled promise, use require_async() Wouldn't that be better of both worlds?

Node did make modules async (just ESM modules). They can’t/won’t make CJS async because their synchronous semantics are a guarantee they determined not to break well before ESM. If you want async modules, ESM is the solution for that.

Re: State of the Web: Deno

#99

Post by andrewmcwatters »

Soremwar wrote: post #90
andrewmcwatters wrote: post #87

Now instead of npm packages abusing SemVer unless you use non-default --save-exact behavior as an attack vector, we can import modules from URLs without subresource integrity unless you use non-default lock file behavior! Great! We learned nothing!

Hence why developers always recommend to use immutable sources when importing modules

The web isn't immutable.

Re: State of the Web: Deno

#100

Post by eyelidlessness »

nexuist wrote: post #37
eyelidlessness wrote: post #5

> V8 is a sandboxed language False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime. > that makes it impossible False, breaking out of the sandbox is trivial in environments which allow native addons.

I am very interested in this. Are there existing exploits for deno? Using a stock out of the box configuration, can you execute some code that breaks its permission model? Has deno undergone some kind of security audit to verify its claims irt security? EDIT: I see some referenced issues in comments down below involving the --allow-read/write flag. I'm not interested in that. I'm interested in if anyone can prove tha…

I think you’d need to either grant permissions (eg allow-ffi) or find a privilege escalation bug in V8 or Deno’s Rust bindings. The latter is less likely for sure. But being realistic, most people using Deno are granting some privileges, because most use cases at minimum do some I/O.

I’m academically interested if there are other such exploits, too. But I’d expect if they’re found they’ll be patched before they’re disclosed (or they’ll be exploited in the wild).

Post reply on HN