kevinkassimo

The very first line of sample code is linking to Deno standard modules, basically the standard library for Deno, aiming to be feature complete enough to bring down the side of dependencies

TBH I am not probably the right person to answer this. Bartek has been working on a lot of internal refactoring these days and he had some discussion with Bert (presenter in dotjs video) on the topic. Maybe ask him in the Gitter chatroom?

For people who are interested to learn more about the current status of Deno, we have a Gitter chatroom: https://gitter.im/denolife/Lobby

Feel free to ask any questions there!

By default remote imports does allow network access, but when running the downloaded scripts, they subject to network permission settings.

Also if you are just worried about any remote imports anyways, there is a `--no-remote` (turn off http[s] resolution) and `--cached-only` (only resolve remote module if it is already downloaded and saved in cache) flag on `deno run`

I believe the current goal is by the end of January (and the main blocker right now is v8 inspector support (debugging in Chrome devtools)).

However internally there are quite a few things need to refactor. Since Deno aims for better Web spec compliance, we need an overhaul of the Worker implementation we have right now. So likely existing API interfaces under the Deno namespace is stabilizing soon, but many of the Web-compat APIs still need frequent updates

Also scripting feels nice in Deno so far. Also the ease of using a script written by someone else hosted on the web to do stuff, without worrying it taking over my machine, is cool IMHO.

I remember saw something long time ago that type hints does not really offer much performance benefit here. Also TypeScript types aren't that reliable anyways since you can always @ts-ignore them. Real impact of TS on runtime performance is more or less an encouragement to developers to create objects of similar shapes that are easier to optimize.

JITs create "shapes" or "hidden classes" anyways: https://v8.dev/blog/fast-properties . They also do many speculative optimizations.

The Rust v8 wrapper used in Deno is rusty_v8: https://github.com/denoland/rusty_v8

The whole privileged side (except for v8 itself) is in Rust.

Deno does transparent compiling and caching of TS into JS. This allows interesting behavior such as the ability to import TS files with explicit .ts extension in JS files, e.g. `import A from "https://example.com/a.ts";`

We currently support Rust message-passing based plugins. Rust sources can be fetched with Cargo or other alternative tools.

Maybe (just "maybe" for now) we will be able to support plugin imports. In that case dylibs could be directly pulled down from network just like normal files (don't take my words as official though -- we have not decided on that yet)

There have been attempts to add some util functions for loading such plugins easier: https://github.com/denoland/deno/pull/3471

You don't really need NPM hosting with Deno. What you need is an index: sources can be hosted elsewhere independently, and instead people can build sites for popular module lookups.

A package manager is different from package hosting. In the case of Deno you can still build and use third party package managers (and they might be able to utilize Deno's import-maps support to achieve some "magic")

Yep that is the intended Deno standard modules -- the goal is to have a standard library large enough to cover most use cases (and that this standard library would not depend on external sources), while making sure that it is independent from the Deno binary to avoid bloat and allow choices (you can definitely implement your own alternatives)

Are you running deno 0.10.0 versus Node? Since there has been some internal refactoring it should now be 80% wrt basic http req/sec (ref: https://deno.land/benchmarks.html#all , though the benchmark might have not covered everything)

Overhead from Flatbuffers is a major reason of the slowdown and we are seeking to get rid of it.

Then how about a site like unpkg.com? The definition even becomes much more blurry as redirections and other possible protocols are involved.

It is actually more interesting about the definition of “per module”, because technically every single file is its very own module from the view of V8, and is reinforced in Deno since we are trying to be web compatible, so there is not even a package.json-like construct for you to identify the “root” of any library, more so as there is no more index.js magical resolution

For certain purposes (especially for writing servers), I would actually suggest Go and Rust as much better replacements for Node.js :) (Ryan also mentioned, if you notice, Go as better alternative for fast servers in the original JSConf video)

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)

Replying to Flatbuffers concerns:

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.

You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox. (For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect atm)

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.

As a contributor to Deno, I am actually quite surprised that this got resurfaced on Hacker news after the hype June last year.

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...)

Created this guide to discuss some current designs of Deno, a secure TypeScript server-side runtime created by Ryan Dahl, the creator of Node.js.

It aims to make the current codebase and design more accessible and possibly encouraging contributions.

Might contain errors or unclear descriptions. PLEASE help point them out and submit issues on Github!