JAXenter: Hi Ryan, nearly two years ago you began developing Deno, which started out with the idea of evolving into an alternative to Node, building upon different concepts. Now, with v1 just around the corner, what would you say is the main difference between Deno and Node?
Deno had to pursue ideas that were incompatible with the existing ecosystem.
Ryan Dahl: Deno uses a radically simple module system where modules and URLs are in one-to-one correspondence. Furthermore, Deno can execute TypeScript code out of the box. These two features have the effect of greatly simplifying the developer workflow. Deno is stricter with security than Node; by default, scripts are run in a secure sandbox without access to the operating system – users can opt in conditionally to provide further functionality – this is to correspond to the browser security model where websites ask for permission to access the camera or location info. Generally, Deno acts more like a web browser – it is, in essence, a web browser for command-line scripts.
SEE ALSO: The badass trio: Agile, JavaScript, and startups
JAXenter: An important question for many developers is how Deno integrates with the larger JavaScript ecosystem. Will it be possible to use Node modules in Deno?
Ryan Dahl: To achieve this much simplified workflow, Deno had to pursue ideas that were incompatible with the existing ecosystem. Today it’s unfortunately generally difficult to take a Node module and run it on Deno and vice versa. That said, these are both command line JavaScript engines built on V8 – they are pretty similar – and we expect, ultimately, that these compatibility issues will be worked out. One of the efforts made in this area is https://deno.land/std/node/ which exposes a Node-compatible “require” function in Deno.
JAXenter: How about specific modules for Deno – are packages like lodash already ported to Deno?
Ryan Dahl: Yep, many modules will work out of the box on Deno, lodash is one of them:
import snakeCase from "https://deno.land/x/lodash/snakeCase.js";
console.log(snakeCase("fooBar"));
We keep an index of third party modules that work on Deno at https://deno.land/x/.
JAXenter: What are your plans for stability and further development after v1 has been published: Will there be a guaranteed maintenance time frame for the version or maybe a schedule for further major releases?
Ryan Dahl: v1 is about stabilizing the built-in JS APIs so developers can build with the confidence that their code won’t break. However, we have a lot of development happening and we will continue to release weekly updates. We don’t have a timeline for 2.0 yet, or even what that would mean feature-wise, but people can expect regular stable releases.
SEE ALSO: Node 14 released with diagnostic reports as stable feature
JAXenter: With v1 being almost finished, are there any features already scheduled for later releases? If so, what can we expect to see in further Deno releases?
We’re exploring if TypeScript type-checking can be done in Rust.
Ryan Dahl: After 1.0, more effort is going to be put into the Rust APIs for embedding Deno in other programs and for making plugins to extend Deno’s features. We are working on a built-in linter (deno lint) with which we hope to increase code quality. We’re exploring if TypeScript type-checking can be done in Rust rather than using the JavaScript TSC – this would dramatically improve startup time.
Thank you for the interview!
The post Deno 1.0 – “Deno is a web browser for command-line scripts” appeared first on JAXenter.
Source : JAXenter
