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

121–130 of 598 posts

Re: Deno 1.0

#121

Post by mrkurt »

dceddia wrote: post #113
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'm wondering about the practicality of importing from URLs. I didn't see it addressed, but an import like this will be awfully hard to remember. import { serve } from "https://deno.land/std@0.50.0/http/server.ts"; Anyone know if there are alternatives or a plan for this aside from "use an IDE to remember it for you"?

The convention is to make a `deps.ts` and re-export what you need. Like this: https://deno.land/x/collections/deps.ts

I don't find versioned URLs much more difficult to work with than package@ though.

Re: Deno 1.0

#122

Post by merpnderp »

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…

You’d deploy builds that include all the dependencies. This isn’t Node where you have to download all deps on your production server, they are built into your deployed files.

Re: Deno 1.0

#123

Post by mrkurt »

soperj wrote: post #120

>JavaScript is the most widely used dynamic language Wouldn't that actually be python?

There are way more browsers in use than Python runtimes. ;)

Re: Deno 1.0

#124

Post by fermienrico »

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.

I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified.

The default in Deno is questionable choice. Just don't fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.

Re: Deno 1.0

#125

Post by spankalee »

mrkurt wrote: post #63
spankalee wrote: post #28

Earlier quoted context omitted.

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…

It's just compiling TypeScript into JS when you import it, and uses tsc to do it. It can load JS just fine as well if you want to use Babel or similar.

I realize that it loads JS.

The issue is that the TypeScript it loads today, it might not load in the future.

Re: Deno 1.0

#126

Post by pknopf »

- "Rust has its own promise-like abstraction, called Futures. Through the "op" abstraction, Deno makes it easy to bind Rust future-based APIs into JavaScript promises."

That's exciting! I wonder if that binding is public for end users to use, or if it's an internal design

Re: Deno 1.0

#127

Post by bgdam »

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.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

Re: Deno 1.0

#128

Post by mrkurt »

sterlind wrote: post #119
0beah wrote: post #97

Earlier quoted context omitted.

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

That still doesn't prevent imported modules from yoinking anything you did grant access to, though. For instance, if my service connects to a DB then `uuid` can slurp the contents. It'd be nice to have some capability model where modules can only access things through handles passed to them, but probably infeasible for a project like this.

You can actually run things as Workers in Deno and get some sandboxing abilities: https://github.com/denoland/deno/blob/master/docs/runtime/wo...

Re: Deno 1.0

#129

Post by desert_boi »

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

Zero processing is a little generous, for things like like ES Module support (and interop), ts-node can be a struggle to get going.

Re: Deno 1.0

#130

Post by kennymeyers »

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.
Post reply on HN