131–140 of 598 posts
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…
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...
This is pretty much like all the bash one-liners piping and executing a curl/wget download. I understand there are sandbox restrictions, but are the restrictions on a per dependency level, or on a program level?
If they are on a program level, they are essentially useless, since the first thing I'm going to do is break out of the sandbox to let my program do whatever it needs to do (read fs/network etc.). If it is on a per dependency level, then am I really expected to manage sandbox permissions for all of my projects dependencies?
What exactly does Deno do? I still can't figure it out: is it a secure version of Node, if so, how?
> 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…
My love of the C++, Java, C#, ad nauseum, lineage of Enterprisey OOP languages turned to hate about 15 years ago, though, so take my assessment with a grain of salt.
“C with classes” seemed like a good idea, we were told back in the 80s in school, since garbage collection is impractical. Er, yeah. Worse is better...
Hi, I'm the co-founder of https://deno.services . We would like to make Deno first language in history comes with its own infrastructure.
Is there much point asking for signups when the only info there is is one sentence and a screenshot?
As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal.
If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 second delay while it "compiles" my "TypeScript". (Again I don't write TypeScript so I don't need this feature). I should note, subsequent runs will be faster, but as I'm developing I don't want delays between my runs.
Since it's not even native TypeScript, it's just embedded the tsc which builds and caches the compiled code, why not let TypeScript developers add their bundling pipeline in the same way as they've always done.
Anyway, I'm very interested in the fact it's built in Rust and seems to be faster than node after compilation in many aspects. Congratulations to the Deno guys and thanks for all the effort.
[edit] Correcting myself. I was wrong. As @jon889 informed me, you can actually run a `.js` file and it will skip compilation. Again I remain that the TypeScript compiler should not have been included, but the fact I don't have to use it completely mitigates my main concern.
Earlier quoted context omitted.
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.
> ...
> 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 browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal. The above example will fail unless the --allow-net command-line flag is provided.
The Deno feature that seems to draw the most fire is dependency management. Some skeptics may be latching onto the first point without deeply considering the second.
Deno is just doing the same thing a browser does. Like a browser, there's nothing that JavaScript running on sandboxed Deno can do that a browser can't - in principle. So the security concerns seem a little over the top.
The one caveat is that once you open the sandbox on Deno, it appears you open it for all modules. But then again, that's what NPM users do all the time - by default.
As far as criticisms around module orchestration, ES modules take care of that as well. The dependency graph forms from local information without any extra file calling the shots.
This seems like an experiment worth trying at least.
Earlier quoted context omitted.
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.
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.
This is starting to look like a case of being different just so you can say you're different.
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.
> 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?
You can use lock-files, bundles, and many other features that makes dependencies management easier.