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

201–210 of 598 posts

Re: Deno 1.0

#201

Post by ryanbrunner »

batmansmk wrote: post #144
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.

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.

Re: Deno 1.0

#202

Post by james-mcelwain »

anderspitman wrote: post #149

> In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependen…

I'm not sure this is referencing the js api, which will be based around promises like node. I believe this is referencing the rust implementation, which is built on top of tokio and rust's async/await.

Re: Deno 1.0

#204

Post by mrkurt »

steveklabnik wrote: post #106
ignoramous wrote: post #88

Earlier quoted context omitted.

> 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 Ser…

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

Deno implements the web worker API, which launches different isolates. You could implement something kind of like CF Workers in pure TypeScript, but probably not replicate your resource enforcement.

It's also a pretty good Rust v8 implementation. Before we (fly.io) abandoned our JS runtime we were rebuilding it with that.

Ironically, we also tried Chakra Core + Tokio. It sure would be nice to have a not-google JS engine.

Re: Deno 1.0

#205

Post by sdan »

kennymeyers wrote: post #130
sdan wrote: post #114

What exactly does Deno do? I still can't figure it out: is it a secure version of Node, if so, how?

It’s an alternative to node. If Node is Photoshop than Deno is Pixelmator. They both take in similar kinds of output and make similar things, but have a very different approach on how the tooling is built and used.

Good explanation, thanks!

Re: Deno 1.0

#206

Post by [deleted] »

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…

[deleted]

Re: Deno 1.0

#207

Post by pknopf »

nitsky wrote: post #145
nitsky wrote: post #137

Earlier quoted context omitted.

In practice modules will be available from sources that will have similar reliability to npm: github.com, unpkg.com, cdn.pika.dev, jspm.io, etc.

it's better because there will be more choice.

Node supports node_modules, not npm. Anything can build the node_modules.

Re: Deno 1.0

#208

Post by izelnakri »

I would really like a testing framework like AVA on deno, same amazing API of seperating parallel and serial tests and running them on multiple threads. Also I will need npm compatibility soon, once these are in, why would I ever write code in node.js?

Re: Deno 1.0

#209

Post by searchableguy »

mrkurt wrote: post #176
bgdam wrote: post #172

Earlier quoted context omitted.

Which again brings me back to something I'm still not understanding - How is Deno's package management better than NPM if it is extremely similar to NPM, but slightly less secure? I'm only asking because lots of people seem to be loving this new dependency management, so I'm pretty sure I'm missing something here.

I like it because it's simpler. I know what happens when I import from a URL. I'd have a hard time whiteboarding exactly what happens when I `npm install`.

What happens?

Re: Deno 1.0

#210

Post by tolmasky »

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 currently importing "https://whatever.com/blah@1.0.1", do I just poll to see if "1.0.2" exists? Maybe check for "2.0.0" too just in case? Is the expectation that I should be checking the blogs of all these packages myself for minor updates? Then, if you get past that, you have a huge N-line change where N is every file that references that package, and thus inlines the versioning information, instead of a simple and readable one-line diff that shows "- blah: 1.0.1, + blah: 1.0.2".
Post reply on HN