deno

Without SRI or similar this is very frightening. edit: they're thinking about it: https://github.com/denoland/deno/issues/200 Security shouldn't be an afterthought.

PR for this is here: https://github.com/denoland/deno/issues/975 It's expected that this should land in next month.

This is my first time seeing it but so much of it looks great. I don’t think I’m a fan with how it handles dependencies, though. It feels like they’ve just reinvented GOPATH. “Deno caches remote imports in a special directory specified by the $DENO_DIR environmental variable. It default to $HOME/.deno if $DENO_DIR is not specified. ... 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://github.com/denoland/deno/blob/master/Docs.md The suggestion to import and reexport dependencies in a central `package.ts` file sounds absurd to me. Clearly, I’m not a user and am just now reading this for the first time. Has there been discussion about this in the community? Are there p

Meanwhile, Deno (alternative server-side JS built from scratch by the creator of Node) keeps chugging along: https://github.com/denoland/deno It will be interesting to see which happens first: developers migrate to Deno or Node finalizes its ES module implementation. I think both groups are doing excellent work, but the Node team seems to be at a disadvantage having to continue support for some decisions made early on in Node: https://www.youtube.com/watch?v=M3BM9TB-8yA&vl=en

Gibhub project page: https://github.com/denoland/deno

Dominic is a prolific contributor and compassionate leader in the JS and P2P communities - and it was a disheartening thread to read. The suggestions that he (working for free!) should have done more seemed unfair. We should look to fix these: - If we're going to rely on hundreds of packages per project, we need fine grained security like Android or iOS. deno seems to be doing node right - https://github.com/denoland/deno/issues/171 - Lock down versions for now. Use 1.2.1 instead of ~1.2.1 or ^1.2.1. - If npm must remain at the center of node's module system, they might have to add auditing and approval tools. 'npm install' can warn about unaudited modules. The problem with that is that it will make npm (a business) even more central to the node ecosystem - which may not be a good thing.

the double GC problem is too worrying to invest more into it. https://github.com/denoland/deno/pull/276#issuecomment-39932...

There used to be one. https://news.ycombinator.com/item?id=17183241 https://github.com/denoland/deno/pull/276 Wasn’t able to find the motivation yet.

Oh? Is that why he's still at it to this very day? https://github.com/denoland/deno

Ryan Dahl has only spoken about implementation details and poor decisions made at the start that are too far along to correct now. He says Go is better than Node, not Javascript. If Javascript-as-a-server was a mistake then Ryan would not be working on Deno [0]. I just hope that the use of Py2 and having to stick with it doesn't bite them in the ass past 2020 [1]. With the caveat of my argument assuming "Typescript is a superset of Javascript." [0] https://github.com/denoland/deno [1] https://github.com/denoland/deno/issues/464#issuecomment-411...

https://github.com/denoland/deno/commit/86354a29a40fb97e334f... https://github.com/denoland/deno/pull/276

I am looking forward to see some production ready versions of RY latest project Deno "A secure TypeScript runtime on V8" https://github.com/denoland/deno