Deno 1.0 • Hacker News Board

Re: Deno 1.0

#241

Post by bgdam » Thu, May 14, 2020, 1:35 AM UTC

batmansmk wrote: post #179

bgdam wrote: post #153

Earlier quoted context omitted.

Except that now, the download deps in CI step can fail if one of hundreds of websites for my hundreds of dependencies goes down. If the main NPM repository goes down, I can switch to a mirror and all of my dependencies will be available again.

To be the rubber duck, if wiping the cache at each build is a risk to your CI, what could you do to keep your CI up? 1 - not wipe the cache folder at each build? It's easy and secure. Oh and your build will be faster. 2 - use a cached mirror of the deps you use? It's like 10min to put in place and is already used in companies that care about security and availability anyway. 3 - you have https://deno.land/x if you wa…

Yes, I think I'd probably settle for solution number 2.

I still don't understand how this is better than NPM, and how Deno solves the horrible dependency management of Node, but maybe if I actually build something with Deno I'll get some answers.

Re: Deno 1.0

#242

Post by nitsky » Thu, May 14, 2020, 1:37 AM UTC

_630w wrote: post #215

nitsky wrote: post #145

Earlier quoted context omitted.

it's better because there will be more choice.

I am always confused by deno folks. You can install from a git repository using yarn/npm. How is that not "decentralisation" And if you are importing single files from a remote url, I would question your sanity.

> install from a git repository using yarn/npm

yep, that's basically the same. deno has the benefit of using the es module system like it is implemented in browsers.

Re: Deno 1.0

#243

Post by nitsky » Thu, May 14, 2020, 1:39 AM UTC

stryan wrote: post #152

bananabreakfast wrote: post #131

Earlier quoted context omitted.

Ever used Go? Not that different.

Go supports "vendor" folders for storing dependencies locally after initial download. That combined with Go Modules means you can handle everything locally and (I believe) reproducible.

deno has the same support with $DENO_DIR and a lockfile.

Re: Deno 1.0

#244

Post by littlestymaar » Thu, May 14, 2020, 1:40 AM UTC

Bahamut wrote: post #238

littlestymaar wrote: post #186

Earlier quoted context omitted.

True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).

Dependency management is one of the biggest complaints I have seen around Go - I don't think this is accurate.

I don't like it either, but it still works well enough for many people.

Re: Deno 1.0

#245

Post by megavolcano » Thu, May 14, 2020, 1:40 AM UTC

pedalpete wrote: post #187

megavolcano wrote: post #103

Earlier quoted context omitted.

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

yeah, but we regularly clear out our cache and lock files, so this doesn't really solve the issue, unless you're commiting all of your packages

Why are you _regularly_ clearing lock files? If you're bypassing lock files you're going to have the exact same issue with npm or yarn or any other package manager that downloads from the internet.

Re: Deno 1.0

#246

Post by s17n » Thu, May 14, 2020, 1:42 AM UTC

thayne wrote: post #230

batmansmk wrote: post #117

Earlier quoted context omitted.

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.

That might work for some projects, but can quickly blow up the size of the repo. I don't think it it is an unsolvable problem. For example, other solutions could be using a mirror proxy to get packages, instead of directly from the source, or pre-populating the deno dir from an artifact store. It would be nice to have documentation on how to do those though.

A better solution is something like https://vfsforgit.org/

Re: Deno 1.0

#247

Post by steveklabnik » Thu, May 14, 2020, 1:44 AM UTC

VWWHFSfQ wrote: post #228

I guess I'm wondering why Deno is targeting V8 instead of Servo? Maybe I'm mistaken, but Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust. [0] https://servo.org/ [1] https://wiki.mozilla.org/Quantum/Stylo

You’ve made a category error; Servo is not a JavaScript engine.

Re: Deno 1.0

#248

Post by bgdam » Thu, May 14, 2020, 1:45 AM UTC

austincheney wrote: post #234

bgdam wrote: post #222

Earlier quoted context omitted.

> Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. Could you elaborate on this? Is it that Deno is against the whole 'small packages that do one thing well' principle and instead in favor of complete libaries? How exactly would it dissuade me from installing hundreds of dependencies?

The default design style for a Deno application is that the application becomes a single file. Just like packages coming off Steam. This requires that dependencies are packaged into the application before it is distributed to others. The idea there is to include only what you need deliberately and it manage it as a remotely written extension of your application.

Having a single executable file, makes distribution easier, but while I'm developing the app, I'll still have to manage all of it's dependencies right? How does Deno aid during development?

> The idea there is to include only what you need deliberately and it manage it as a remotely written extension of your application.

I have a node app, in which I deliberately only included the dependencies I need. The package.json lists exactly 8 dependencies. However, the node_modules folder already has 97 dependencies installed into it. The reason of course is that these are dependencies of dependencies of dependencies of dependencies.

Wouldn't Deno have this same issue? Are the dependencies also distributed in compiled form as a single file akin to windows DLLs?

Re: Deno 1.0

#249

Post by sintaxi » Thu, May 14, 2020, 1:45 AM UTC

perlpimp wrote: post #65

I remember node stayed 0.11 or some sub 0.* numbers for the longest time. barely progressing version numbers, anything changed? Just wondering.

IMHO those were the golden years of developing with node.

Re: Deno 1.0

#250

Post by mhink » Thu, May 14, 2020, 1:51 AM UTC

ryanbrunner wrote: post #201

batmansmk wrote: post #144

Earlier quoted context omitted.

I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway. You can even depend to your non-npm repo (github, urls...) from a npm-based package. If you want to "feel" as safe, you have import maps in deno, which works like package.json. Overall, I think Deno is more secure because it cuts the man in the middle (npm) and you can make a npm mirror with low effort, a simp…

One advantage of having a centralized repository is that the maintainers of that repository have the ability to remove genuinely malicious changes (even if it's at the expense of breaking builds). Eliminating the middle man isn't always a great thing when one of the people on the end is acting maliciously.

I'm just thinking out loud here, but it seems to me that you could just make sure you're importing all your dependencies from trusted package repos, right? And since the URL for a package is right there in the `import` statement, it seems like it'd be pretty easy to lint for untrusted imports.

I don't detest NPM in the way that some people do, but I have always worried about the implications of the fact that nearly the entire community relies on their registry. If they ever fell over completely, they would have hamstrung a huge amount of the JS community.