Besides this, it uses the same module system as the browsers do. The JS module system is in my opinion very well designed and intuitive. No need for AMD or CommonJS or Node require's.
Other good things about Deno is that it includes a lot of goodies by default. In that single binary you get in your command line interface:
- A very very decent and fast bundler (bundling in JS is a mess, the Deno is straightforward and needs no config and no hacks, which, surprisingly is unique in the JS bundling scene)
- Testing library
- TypeScript support (for those that like it)
- Documentation generator
- Linter
- Syntax modifier (like prettier)
- Official VS Code plugin
Unlike Node, it uses Rust to bridge the gap between the JS engine and the OS, and leverages on a lot of very cool Rust libraries.
So it's not aiming to be revolutionarily different from Node, rather a second shot at Node.
I also had that question in my mind until I tried deno a couple of weeks ago. There are a few great things I've discovered that IMO makes it a great alternative to node.js:
- Deno + std library has a lot of batteries included. Have you tried creating a web browser project with node.js recently? Just adding a few basic dependecies to compile and bundle your code will leave you with node_modules having hundreds of other dependencies. With recent cases of malware slipping into npm dependencies tree, I'm a bit fearful of starting a new project and infecting my computer (not too crazy imagining that one of the developers of those hundreds of deps will be careless with their SSH keys). "deno bundle" basically solves that for me.
- I can't think of a reason why I would not use typescript these days. Not having to install tsc or create a tsconfig.json is a killer feature for me. Not to mention compiling ts with Deno feels really fast (maybe because they don't have to load the whole typescript compiler into the JS VM on every run?).
- As a consequence of Deno's fast startup + tsc support + great standard library + automatic dependency download, I've found a vastly superior alternative to python for writing quick and dirty scripts for automating various tasks. So for me Deno is not just for writing servers, it is also for using typescript as a script language for automating my desktop and server workflows.
These are just a few things that stand out for me, there's certainty more to Deno than it may initially appear.
* Running a build tool with only file access to the source files
* Trying a cli script without granting it access to everything by just showing the help
In times where a linter has 10000 dependencies, I'm in desperate need of sandboxing.
People on hackernews are easy to judge companies when they leak customer data. But what if we the developers are actually the problem by executing megabytes of foreign code just with faith.
Deno glue code around V8 is written in Rust.
It tries to be as close to the browser API as possible, using ES-Modules instead of CommonJS and doesn't require a package manager.
Also, it compiles TypeScript automatically.
The C++ V8 api is very reasonable to be used in a safe way. So i dont see this as a good point unless of course for people that wan to write some parts that need to be optimized in Rust.
Don't deal with NodeJs that much, but is a lot of node functionality in C++ modules? and if so they are presenting a lot of security bugs in a way that Rust might see appealing?
Because by not having direct access to the V8 api in its native language might limit you, the "glue coder", in the things you really can do.
Maybe this is not the best way of putting it. They use Rust for all the system bits including networking, so it's not like they just wrote some JS to V8/C++ glue code in Rust.
Anyway in security terms it will probably turn out negligible as the percentage of code in safe Rust are probably low compared to the whole thing.
Than in memory usage, if it replicates Eletron,it would turned out almost the same, giving is not the C++ core the one that is most memory hungry.. is mostly the renderer process with WebKit and V8 executing big portions of javascript code in memory.
Giving if such a branch existed, it would use typescript which in turn is the same V8/javascript pipeline that is memory hungry.
So, addressing to the parent poster, i don't think it would change much in terms of security or memory pressure if compared to Electron.
Sometimes i think Rust give some people high expectations, that it would be very hard to actually replicate in real life experiences, giving software is much more complex and as in Deno, requires other core parts that cannot be realistically rewritten in Rust, and even if they could, while we can see how software written in Rust can be safer, it still needs to prove the claim for bigger, sensitive pieces of software that requires a lot of "unsafe" techniques to work like JIT's and OS's and therefore might not feel that much of a difference giving the size and complexity of the project.
--allow-env allow environment access.
--allow-hrtime allow high resolution time measurement.
--allow-net=<allow-net> allow network access.
--allow-plugin allow loading plugins.
--allow-read=<allow-read> allow file system read access.
--allow-run allow running subprocesses.
--allow-write=<allow-write> allow file system write access.
--allow-all allow all permissions (same as -A)
Node and Deno are dedicated runtimes to run Javascript using the V8 engine. Both provide a standard library of additional functionality to make them worthwhile beyond just browser code.