71–80 of 598 posts
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.
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.
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.
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.
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.
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.
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.
For context: Deno's lead is Ryan Dahl, the creator of Node. In the past, Dahl's expressed regrets over choices he made early on in Node's development, and on the direction Node has gone since he left the project many years ago. He bravely presented on this topic at jsconf eu, 2018: https://www.youtube.com/watch?v=M3BM9TB-8yA , it's a fantastic talk. The last 10 minutes are a pitch for what a "better Node" would look…
And now, he'll make a whole different set of good and bad choices to potentially regret later.
> 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…
Earlier quoted context omitted.
The code running in my browser isn't a multi-tenant production server, with access to the filesystem and DBs.
From the article: "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."
"web browsers already do this ;)" isn't a good comparison.
> 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…