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

221–230 of 598 posts

Re: Deno 1.0

#221

Post by austincheney »

tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

You have to stop thinking in terms of NPM where it takes 1000000000 packages to do anything. A Deno application is designed to be distributed as a single file. You can override the default behavior to have NPM like stupidity, but if that is really your goal why bother moving to Deno in the first place?

Re: Deno 1.0

#222

Post by bgdam »

austincheney wrote: post #183
bgdam wrote: post #139

Earlier quoted context omitted.

Which then raises the question - how is it better than NPM? If there are going to be centralized repositories (like NPM), and if I have to download my dependencies into a $DENO_DIR (like NPM), and if I am then loading these dependencies from local files (like NPM), how is it any different to NPM? Except for being less secure by default? This is starting to look like a case of being different just so you can say you'r…

NPM is a dependency management failure which is why you are ending up with hundreds of dependencies in the first place. It sounds like you want to reproduce that insanity in Deno. 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. In my opinion this is Deno’s biggest selling point.

> 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?

Re: Deno 1.0

#223

Post by VWWHFSfQ »

aazaa wrote: post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > 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. The…

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

Re: Deno 1.0

#224

Post by mrkurt »

tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

The Deno solution is either:

* A deps.ts that handles all external dependencies and re-exports them

* Import maps

Neither of these really give you a way to do the equivalent of "npm update". But I almost never want to update all my packages at once.

Re: Deno 1.0

#225

Post by BubRoss »

ricardobeat wrote: post #156
bgdam wrote: post #151

Earlier quoted context omitted.

See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…

Maybe this will develop into a standard of multi-process servers (real micro services you could say), where the permissions are only given to a slice of the application.

Reinventing QNX will always be cutting edge.

Re: Deno 1.0

#226

Post by c-cube »

tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

Maybe a convention will arise, that you do all the imports in one file (basically like a `package.json` file) and import that from the rest of your code? It seems hackish to me but could work.

Re: Deno 1.0

#227

Post by tolmasky »

mrkurt wrote: post #224
tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

The Deno solution is either: * A deps.ts that handles all external dependencies and re-exports them * Import maps Neither of these really give you a way to do the equivalent of "npm update". But I almost never want to update all my packages at once.

You don’t like checking for security updates?

Re: Deno 1.0

#230

Post by thayne »

batmansmk wrote: post #117
bgdam wrote: post #111

The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I…

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.

Post reply on HN