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

191–200 of 598 posts

Re: Deno 1.0

#191

Post by pedalpete »

xg15 wrote: post #81
mrkurt wrote: post #54

Earlier quoted context omitted.

It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. It's also exactly what the websites you visit do. ;)

> It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. I'm not sure how this works in detail here, but at least in NPM you got a chance to download packages, inspect them and fix the versions if so desired. Importantly, this gave you control over your transitive dependencies as well. This seems more like the curl | bash school of package management. Ed…

Thanks for sharing that link. Seems much more sane, but not without issues. I'm sure this will continue to be iterated upon.

Even with all NPMs flaws, I do feel this is a bit of throwing the baby out with the bath water. Time will tell.

Re: Deno 1.0

#192

Post by bgdam »

gunn wrote: post #107
_bxg1 wrote: post #84

So it's an alternative to Node? Sounds incredibly cool, honestly. This: > Supports TypeScript out of the box. Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).

You'll like https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript

Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.

Re: Deno 1.0

#193

Post by mrkurt »

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

What! Clearing lock files seems wild. How do you know you're getting the right code when you install dependencies?

Re: Deno 1.0

#194

Post by toastercat »

bgdam wrote: post #172
ricardobeat wrote: post #162

Earlier quoted context omitted.

You answered your own question. Nothing stops you from using a mirror with deno too.

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.

It's decentralized.

Re: Deno 1.0

#196

Post by james-mcelwain »

Roboprog wrote: post #116
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.

Sure do. I wonder if they have a checksum mechanism like browsers do? You can add an “integrity” attribute to script tags in the browser. https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

One advantage of urls is that you can link to a specific git sha, tag, or branch for a dependency, e.g. on github.

Re: Deno 1.0

#197

Post by gutino »

cphoover wrote: post #173

I think Deno is a mistake at this point... Yes we thank Ryan Dahl for his huge contributions to integrating libuv and v8 outside of a browser to create node.js but a lot of work has been created by a huge ecosystem of developers after this. I think this de-facto fork of node.js will only serve to create fragmentation, and confuse product owners about which platform to use.

If We were all follow your rationale, We will be all programing in COBOL still. Accept the pain of experiment and growing up.

Re: Deno 1.0

#198

Post by ArtWomb »

petercooper wrote: post #33

If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing https://denoweekly.com/ .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land :-)

I suppose .land is the new .dev now ;)

Am curious how Parallelism could be handled in the runtime? Besides exposing WebWorkers, would shared memory be a possibility? V8 looks like its heading toward a portable WebAssembly SIMD accelerator.

>>> Promises all the way down

Async / await is a great pattern for render loops by resolving to continuous window.requestAnimationFrame calls. Here is a nifty example computing a Buddhabrot and updating new data quite smoothly:

http://www.albertlobo.com/fractals/async-await-requestanimat...

Re: Deno 1.0

#199

Post by city41 »

spankalee wrote: post #28
threatofrain wrote: post #9

> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow. > Early on in the project we had hoped that "V8 Snapshots" would provide significant improvements here. Snapshots have certainly helped but it's still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the exist…

Deno really shouldn't run TypeScript files directly. Not only is TypeScript too slow for this, it receives far too many breaking changes. How will Deno decide when to upgrade its TypeScript compiler version? Will Deno have to have breaking changes every three months or so? Also, Deno appears to allow import TypeScript files with .ts extensions while tsc doesn't. This alone means the same code won't run in Deno and co…

I’m a huge TS fan and I agree. Deno is just running tsc for me it seems. So far I don’t see much advantage. It also potentially ties Deno to current trends. TS is pretty dang popular, but what if something else comes along and scoops it?

Re: Deno 1.0

#200

Post by eloff »

mrkurt wrote: post #174
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…

Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.

Security is literally the main selling point of this thing. Otherwise just use node.
Post reply on HN