Live data from Hacker News

Deno 1.0

deno.land

91–100 of 598 posts

Re: Deno 1.0

#91
post #41

Earlier quoted context omitted.

> Lua is far superior I disagree with this assessment.

LuaJIT is nearly 3x faster than V8 JavaScript the last time I checked. Just anecodal DDG search [0]. Maybe V8 has gotten faster since the last time I checked. [0] https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...

I think a big part of the point is to build a js runtime for existing js code and libraries.

Probably it will not replace node soon, but it is a possible outcome.

Also didn't luajit had the problem that it would never move to more recent version of lua? I remember that some years ago there was some talking about this.

Re: Deno 1.0

#92
post #54

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.

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.

This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NPM world does not currently have.

Re: Deno 1.0

#93

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 :-)

Keep up the good work, JS weekly is a wonderful resource.

Re: Deno 1.0

#94
post #87
post #72

Earlier quoted context omitted.

Deno caches local copies and offer control on when to reload them. in term of vendoring you can simply download everything yourself and use local paths for imports.

How would this work with transitive dependencies? Sure I can control which parts I import myself, but how do I keep a vendored file from pulling in another URL a level deeper?

Unlike node, recommended deno practice is to check-in your dependencies to the VCS.

> Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime.

https://deno.land/manual/linking_to_external_code

Re: Deno 1.0

#95
post #83

This is super effing awesome. You know what would be extra amazing? Incorporating (at some point in the future) all of the very smart stuff that the unison people have been doing. That would be _tremendous_ for code re-use and guarantees about remote packages. What I wouldn't give for a JS vm that could do all that. . . . * https://www.unisonweb.org/docs/tour

I like that Deno prefers URLs as module specifiers. Need immutable/content-addressed dependency graphs? Publish and consume modules via IPFS.

Re: Deno 1.0

#96

if you require modules by URL, how does it make sure that the URL always contains the same library? I've read the docs and it says it caches on the initial execution and doesn't update unless it's forced to update, but what happens when you for example publish a deno module to github, and someone else downloads it and runs it, and turns out the URL contains completely different library at his execution point?

This is something that we'll further work out in future versions. For now you can use a lockfile: https://deno.land/manual/linking_to_external_code/integrity_...

This looks really promising.

However, it still seems risky to me in case a library is not available. Is there a central repository planned? Or are you expected to vendor everything and ship your project with dependencies included?

Re: Deno 1.0

#97
post #62
post #56

Earlier quoted context omitted.

Does it also terrify you when code running in a browser does it?

The code running in my browser isn't a multi-tenant production server, with access to the filesystem and DBs.

Except that with Deno, everything IO related is turned off by default and has to be granted access before it becomes a process. It's the first bullet point on the landing page.

Here is the page with more detail. https://deno.land/manual/getting_started/permissions

It can even restrict access down to a specific directory or host. This is cool.

Whereas any NPM module can map your subnet, lift your .ssh directory, and yoink environment variables, wily-nily.

It's happened before.

Re: Deno 1.0

#98

And the very first line of sample code is adding a dependency on someone else's code. Reminds me of https://npm.anvaka.com/#/view/2d/react-native Good luck, though. Everyone lives in a different (mental) tribe I suppose...

The very first line of sample code is linking to Deno standard modules, basically the standard library for Deno, aiming to be feature complete enough to bring down the side of dependencies

Re: Deno 1.0

#99
post #72
post #60

Earlier quoted context omitted.

Does Deno have some built in way to vendor / download the imports pre-execution? I don't want my production service to fail to launch because some random repo is offline.

Deno caches local copies and offer control on when to reload them. in term of vendoring you can simply download everything yourself and use local paths for imports.

> in term of vendoring you can simply download everything yourself and use local paths for imports.

So I basically have to do manually, what NPM/yarn do for me already?

Re: Deno 1.0

#100

And the very first line of sample code is adding a dependency on someone else's code. Reminds me of https://npm.anvaka.com/#/view/2d/react-native Good luck, though. Everyone lives in a different (mental) tribe I suppose...

So, I've never seen this before, but I'm 99.9% sure that's just part of the standard library being imported...
Post reply on HN