"Vno" is a parser, compiler, and bundler and can be easily accessed through an integrated CLI tool that will either create an entire project from scratch, including an example file structure and components, or optimize an existing Vue project with a few simple commands.
Deno supports and encourages writing code in TypeScript but the way it works is: Deno bundles TypeScrit compiler, uses it to convert TypeScript to JavaScript and then executes the JavaScript.
It can also run JavaScript files directly.
Deno's runtime is a bunch of JavaScript APIs + TypeScript typings so that they can be understood by TypeScript code.
There's a great Software Engineering Daily podcast with Elio Rivero [0] (audio and transcript in link) that goes into depth on Deno, TypeScript, JavaScript support. It's interesting that compile time was the (TS) killer.
"Replaces" is a strong word. Deno is an attempt to make a better headless JS runtime given years of hindsight. Most of the things it does differently are welcome, but a few are controversial. And that's not even getting into whether or not it'll be able to hit the critical threshold of adoption. It's way too early to know the outcome yet.
I'm somewhat dismayed by how many things are having to be rewritten for Deno. A lot of the strength of JS is its ecosystem, and Deno would've had an uphill climb for adoption even if it were a drop-in replacement for Node. If it's basically starting from scratch, that seems bad. I think Deno has a lot of good ideas but I fear this might keep it from taking off.
Most Node code can be easily adapted for Deno. What we're seeing here is that instead of making a PR for the upstream Vue CLI to add Deno support, somebody decided to fork/rewrite it under a different name. I suspect this is driven more by branding/ego than technical concerns.
It's a bunch of tedious work but it's not exactly replacing. You're mostly changing imports. There are cases where things become more complicated, mostly advanced non-static usage of `require` features.
Fundamentally, Deno works way more like the language JavaScript is meant to be according to the vision of the ECMA committee (the ones who add features to the language).
Problem is that a lot of software was built upon areas where Node deviates from this standard (things like module system, language features, async management, etc) so there can't be a 1:1 translation in some cases
Yeah. All I'm saying is that, practically speaking, it's a huge limitation. Imagine if Clojure couldn't leverage Java's ecosystem. Or, rather, it could but first you have to fork each package so you can change all the import statements and standard lib calls.
I do wonder if they couldn't have provided a shim for the Node system-APIs, and maybe even a compatibility-mode for Node's import style? Something where you could drop a Node project into Deno, complete with NPM dependencies, and immediately run it, and then gradually convert it to "idiomatic" Deno code with the proper (typed!) system APIs and URL-style imports. If they hope to eventually replace Node, "scrap the entire library ecosystem" doesn't feel like a very realistic roadmap.
Actually that is being worked on (std/node is a shim for Node libraries that aims to make Node ecosystem 100% usable from Deno) but the idea is to build software with Deno's mindset and features on top of it. Just look at this Vue compiler, it is really lightweight in comparison to what the actual Vue compiler actually takes up in Node.
16 comments
[ 8.5 ms ] story [ 48.6 ms ] threadDeno supports and encourages writing code in TypeScript but the way it works is: Deno bundles TypeScrit compiler, uses it to convert TypeScript to JavaScript and then executes the JavaScript.
It can also run JavaScript files directly.
Deno's runtime is a bunch of JavaScript APIs + TypeScript typings so that they can be understood by TypeScript code.
[0]: https://softwareengineeringdaily.com/2020/09/28/deno-and-typ...
If it ever achieves it is another matter, regardless who is the author.
Problem is that a lot of software was built upon areas where Node deviates from this standard (things like module system, language features, async management, etc) so there can't be a 1:1 translation in some cases
I do wonder if they couldn't have provided a shim for the Node system-APIs, and maybe even a compatibility-mode for Node's import style? Something where you could drop a Node project into Deno, complete with NPM dependencies, and immediately run it, and then gradually convert it to "idiomatic" Deno code with the proper (typed!) system APIs and URL-style imports. If they hope to eventually replace Node, "scrap the entire library ecosystem" doesn't feel like a very realistic roadmap.