That being said, I suggest checking out this video (recorded this April) for updated information about Deno, since things have changed quite a bit since the initial announcement: https://youtu.be/z6JRlx5NC9E
(Edit: fixed link, posted the wrong one. Why would YouTube think I want to share ads...)
No package signing, no flags per module, no syscall whitelisting, etc.
We have also discussed about possibilities of implementing an in-memory file system. (Maybe we will also bring sessionStorage to Deno)
Flags per module is slightly trickier, while whitelisting of certain feature is trivial to implement.
Package signing is indeed a topic that Deno contributors need to discuss further and possibly finding a solution.
I actually suggested a more granular, per-module approach to this during the Node Forward and IO.js debacle years ago: https://github.com/node-forward/discussions/issues/14
At the time it was deemed to difficult to implement in Node.js after the fact, which makes sense of course. But I'm disappointed that Deno didn't go for a more bolder, more secure approach. The current system seems pretty pointless.
Actually I saw yt presentation and it didn't convinced me to switch from nodejs. The differences to nodejs are so little, specially when you're using typescript already. The only significant change is "es modules" with ability to resolve modules from url (plus the sandbox).
Still big kudos to Ryan for nodejs.
Single executable Allows imports from url File system & network Sandboxing is controlled with flags Dies on uncaught errors
how can JS programmers deal with this?
Cattle not pets!
Expect to see this in "n things I regret about deno"
You are right, we will try to get rid of it for some faster serialization mechanisms (after some huge internal refactor lands). See the talk I posted, Ryan mentioned about it near the end.
I'm really excited about this project, especially the first-class TypeScript. Could easily see it replacing node for me!
Deno is a runtime that aims to isolate the code from the system amongst other issues.
SES uses a proof over the JS grammar with induction, Deno does isolation by not giving any OS level access to your code.
Neither are particularly complete and are mostly orthogonal. Both are looking for people to help with them :]
So, does it support a specific ECMAscript version? Or am I restricted to the Typescript JS definition? This is confusing..
Performance should improve over time, there's no fundamental reason from what I understand that it shouldn't be as fast or faster than node.
node has had 10 years of work and performance effort from so many people and organisations.
Ryan and some of us consider the project quite experimental, and the initial focus was not aiming for writing super powerful servers (though it should not be too bad). A pleasant scripting environment with more attention to features that Node have not tried out is more or less the goal.
(Fun fact: Ryan has been into machine learning and data visualization for some time. So Deno was created under the hope to somehow compete with Python in certain aspects)
Overhead from Flatbuffers is a major reason of the slowdown and we are seeking to get rid of it.
Personally I isolate with OS level containers as I think it's a lot more robust and tested but I definitely see the merit in Deno exploring this - even if it doesn't really work yet it's interesting.
I’ve been looking into the isolated-vm module recently and it looks pretty nice. Fly.io built their run-untrusted-code service on top of it.
For example, some node internals like networking require the invoker to attach to some obscure .on("error") event to avoid uncaught errors. and a lot of the time these 3rd parties are not aware of it.
I'm all for deno being built from the ground up to properly crash on uncaught errors. Silent ignoring is a really stupid decision.
I think the erlang/elixir model of fail fast and try to restart is the best for availability.
I don't remember the exact API, but basically an es module graph is a directed graph (e.g. edges have a direction), and because there is only one entrypoint in node, we can therefore create a hierarchy of modules. From this point on, you basically start at the root with X permissions, and from there each module can reduce the permissions of modules they import (or they can reduce their own permissions, but they can't raise them after that obviously).
probably didn't have to be designed this way, but it was designed pre-promises and I guess they are lothe to change it.
