• Why I Believe Deno is a Step in the Wrong Direction for JavaScript Runtime Environments
  • By Mehul Mohan
  • Originally published: 2020-05-14
  • Translator: hylerrix
  • Note: This article follows the freeCodeCamp translation specification and will be included in the translation of Deno’s Study.

The translator sequence

In the “Deno study of the art” to introduce the first translation article, saw this article, at that time also feel unable to control, focus on the first to write a number of entry-level Deno article.

In 2021, with the first issue of Deno Biweekly continuing the New Year’s Deno journey, I thought back to this article. I thought that I could read this article and related issues to understand Deno from another perspective, and the translation began.

Compared with the previous direct translation of the article, there are many places to take notes (even “eye-opening” places), so the “translator’s preface” chapter of the article is specially opened up to sort out the other side of the original text and related videos of Deno, and what they are about.

As the original pointed out, this is bound to be a controversial post, as the two videos featured in the article both had slightly more clicks than likes and were filled with “hot” discussions in the comments section. The original text also has some excessive criticism, but do not hinder the following translation after the beginning of one by one to restore the original author wants to express the point of view!

So, what is Mehul trying to say in the original article and both videos about why Deno isn’t that good? Their views are summarized as follows:

Note: Skip the reading if you want to see the original article first and read the brief summary later.

  • Deno and Node do compete because you have to choose between your next project.
  • There isn’t much that Deno is doing right now, and most of the features can be handled well within the Node ecosystem.
  • URL import was also a disaster. NPM already has a number of star projects with “only one line of code”, “stealing user data”, “mining code injection”, “compatibility problems causing many upstream libraries to be affected”, etc. URL import itself does not solve these problems. And without a strong community like Node to secure trusted dependency libraries, there won’t be many developers willing to join the Deno ecosystem.
  • Since TypeScript is a superset of JavaScript, it is perfectly possible to skip type validation, and it is recommended that a novice programming with TypeScript on Deno will be exposed to a lot of any types. With frequent debugging errors, TypeScript is also expensive to learn, making it easy to write low-quality code.
  • TypeScript doesn’t run directly on Deno. It runs in JavaScript, so why should it be integrated into Deno?
  • Safety is a tough thing, and Deno’s promotion of its “safety sandbox” is bound to take a lot of responsibility. Deno security sandbox is also unnecessary, and can be fully supported by container or virtualization technologies such as Docker. At the same time, scripts that really want to do damage will find their own way around security issues.
  • In the current versiondeno --allow-runRunning the main process enables child processes to easily break through security sandbox verification to gain more privileges. For example, finding Deno’s”Security sandbox“Is not as safe as claimed.
  • Deno doesn’t need to integrate many toolchains (code formatting, testing tools, TypeScript, etc.) into one. It’s nice to keep Deno focused and provide more plugin-friendly support while having a variety of third-party toolchains build the ecosystem together.
  • Node’s asynchronous model is not obsolete, and neither are the Promise and event listener models, so it’s not clear how Deno will address these non-obsolete issues.
  • It is uncertain how many developers will be willing to move mature libraries from NPM to Deno over time.

As you can see, whether you’re a Node developer or a Deno enthusiast, there’s a lot to think about. However, there are some errors, such as the description of Deno as a programming language, and a direct comparison between Deno’s two-year-old ecosystem and Node’s decade-old ecosystem — Deno is destined to have its own unique development trajectory.

In the end, Mehul summarizes his view of what Deno V1.0 really looks like:

Deno = (in most cases)[TypeScript + Node + properly configured Docker container + single executable + < various gadgets > -npm]

Start the translation

So far, I haven’t found a channel like CodeDAMN on Youtube (more than 100,000 developers subscribe to it) that isn’t excited about the release of Deno V1.

Last week, I posted a video on my channel with some “why I don’t think we need Deno — another JavaScript runtime based on V8 and Node” reasons that seem pretty succinct to me.

With this article, I can expand on more reasons outside the video. But if you want to watch the video first, check this out:

Why Deno will fail — Node.js V/S Deno: My Opinion

To prove that I’m not against Deno in general or even JavaScript itself, I’d like to state that I like JavaScript better than many other programming techniques. My main technology stack is only around the JavaScript — Node/React/mongo/React Native/NativeScript/Ionic/you can think of even more related library.

I’ve been able to get more than 100,000 subscribers to my Youtube channel and a developer platform using JavaScript as my main language.

But the important thing is that it is important to maintain a fair and objective perspective to see both sides of an issue. There are certainly good things about Deno, but there’s another side to it that most people haven’t seen/written about yet. Check it out! _ Note: This article is bound to be a controversial one. Let’s be polite and keep our emotions in check first. I would appreciate it if you could read the full text until the end and then say more about your thoughts. I’ll list my social media accounts at the bottom of this post, and I hope we can have more good discussions on this topic there.

Deno vs Node: A veritable rivalry

There are a lot of people in the industry saying, “There is no competition between Deno and Node, there is a lot to learn from each other.”

To some extent, I agree that Node and Deno can learn from each other. But is there really no competition between the two? I totally disagree with that.

Let’s review the common features of Deno and Node:

  1. They are both runtime environments for JavaScript;
  2. They all run on any machine that can run V8;
  3. Both are supported by the ECMAScript standard;
  4. They are being actively maintained.

If you’ve been a Deno fan for two years, it’s unlikely you’ll be able to use Deno for a new project without Node.

Similarly, if you’ve never used TypeScript before and think you want to try Deno, you’ll have a hard time using all the modules in the NPM ecosystem.

So: Deno and Node developers do have a split right now — you have to make a choice, and I’d say this is an important example of the rivalry between the two.

What’s so good about Deno?

First, I need to list some of the advantages that Deno claims about itself, and why Deno says it’s a better runtime:

  1. It overcomes some of Node’s shortcomings;
  2. It is a secure runtime environment by default;
  3. It has Built-in TypeScript support;
  4. It relegated Promise’s support to the bottom;
  5. It is built in the Rust language (compare it to C++ for Node).

In the following sections, I’ll take a look at each of these Deno benefits and see what Node can learn from them. I’ll also discuss, if necessary, why Deno doesn’t make sense yet.

Where does Deno gild the lily?

Let’s take Deno’s Unique Selling Proposition (USP) and break it down:

A secure runtime environment by default

This is a very popular feature in Deno and I was pleasantly surprised. Deno supports a secure sandbox environment by default, unless you explicitly choose to enable access to the file system, network, etc.

Deno is doing this because it wants to be more relevant to the browser. Deno’s compliance with THE ECMAScript standard is great, but why is it so keen to be first to the browser?

Perhaps the answer is that Deno wants to maintain good compatibility between the code written on the client and the server. But Deno is so keen to support browsers that I think it’s going a little too far.

Node doesn’t support a “safe run time” — but after much thought, I think there are reasons to support Node:

  1. As we all know, you should never run untrusted code and executables on your system. This is why we always choose a library like Express for Node (rather than just any library that claims to be 100 times faster than Express). Trust comes from a lot of use by the community.
  2. I don’t know of any programming language that provides such a sandbox environment as Deno. While this might be nice, it seems like it should be left to a container environment such as Docker. I believe that a well-configured Docker environment can better handle the security of untrusted files than running untrusted Node code in a sandboxed Deno environment.
  3. Sandboxing isn’t that easy — I’m no cybersecurity expert, but I think the more certain features there are, the greater the potential for attack. Deno promises a secure runtime environment, but I would say security is hard to achieve. With Deno’s promise comes a huge security responsibility. The world’s largest corporations are spending hundreds of millions of dollars a year on independent developers and security companies to support their security white hat initiatives. So where does Deno take their “safe environment”? Time will tell.

So, what can Node learn from Deno? I would say not much. Node may be able to introduce some security environment identifiers from its competitors, but it doesn’t make much sense. If you want to run unknown code on your system, it is best to clone a C/C++ repository and run the make command to damage the system.

The translator’s note: (1) If you got better input code from your professors, you got better results from them. You might as well clone a C/C++ repo and run a make command over it and get your whole system compromised.” It’s not easy to see why Node/Deno suddenly went to C/C++.

As far as I know, you can’t “sandbox” filesystem or network access in low-level languages like C/C++ — it’s not very efficient.

Note: Recently I found that Deno with the –allow-run flag enabled can do almost anything. The video goes into more detail:

Breaking Deno’s security sandbox – Deno is not safe

Built-in support for TypeScript

I applaud TypeScript’s progress, and I’m glad Deno supports TypeScript right out of the box.

Note:Thank you@lilasquared It was pointed out that Deno could also operate out of the box.jsFile. This article focuses on using.tsFile writing code. Deno can, of course, run.js files directly.

But let’s step back: do you know why JavaScript and Node have tens of thousands of developers around the world? Because the barriers to entry are virtually zero. JavaScript is flexible and allows you to make a lot of mistakes. TypeScript always gives you some weird errors.

This is bad for production-grade applications: the production environment doesn’t need all this hipster stuff. At the same time, for learners, JavaScript is tolerant, even if you may encounter some bugs, but also easy to correct, quote, JavaScript can be quickly coded and things get done.

For starters, I worry that if they choose to use Deno (and are required to use TypeScript) because they don’t know TypeScript yet and want to quickly run through the code on the server, we’re likely to see a lot of this:

const httpResponse: any = await getAPIResponse<any>({ myParams })
// ...
const someOtherVariable = something() as any
// ...
any.any.any
Copy the code

TypeScript is a superset of JavaScript. You can write bad TypeScript code without even thinking about it. Using TypeScript alone won’t make your project watertight.

It’s a fun experience until you remember that you can write TypeScript in Node in the first place. I believe that every large company that uses Node in production now introduces TypeScript to write projects — no exceptions. JavaScript is really hard to extend when you’re dealing with lots of files and dependencies and lots of code.

TypeScript is a revolutionary tool kit for the JavaScript ecosystem, with better support for both static and dynamic languages.

So Deno claims to have Built-in TypeScript support. But WHY does it have to be this way? Sure, if not built in, you might need to add Babel and Webpack to do the job, but isn’t that the point of having a bunch of third-party toolchains around you to build an ecosystem? Don’t we want to enhance DX?

Translator’s note: DX is short for Developer Experience. When the users of a software or system are developers, developer experience (DX) is equivalent to User Experience (UX).

JavaScript is still going to be JavaScript, it’s going to be its own style. Also, if Deno does run TypeScript (or a typescript-like language) directly, I don’t see a problem. But in reality, Deno just converts TypeScript code into JavaScript code and runs it.

From these perspectives, Deno appears to be an integrated version of Node’s various tools, including a testing tool, a code formatter, and TypeScript all at once. I prefer a streamlined programming language and add the various plugins myself when appropriate — of course, I can’t speak for all developers, and that’s just my opinion.

Why do I need a built-in code formatting tool when I already have an prettier library for code formatting? Why tackle something that works so well?

The individual architecture does come together to provide a lot of tools, but it’s also really big, and a leaner and more focused core library is better maintained and expanded.

Promise’s support is down to the ground

Compared to Node, the release of Deno V1 doesn’t make much sense to me. I have a lot of respect for the creators of Node and Deno, but Node has something that Deno doesn’t — the support of many experienced developers around the world.

Node is powered by nearly 3000 developers and is a leader in asynchronous I/O event processing. Deno does build on Rust and exposes an abstraction similar to Promise. But Node has C++, 3,000 developers and more than 10 years of development and maintenance.

Node’s asynchronous model is not obsolete, and neither are the Promise and event listener models, so I’m not sure how Deno will address these non-obsolete issues.

Bye, NPM

It’s important to note that Deno does not support NPM. Ryan (founder of Node and Deno) is promoting features of the Go language for this purpose. Reminds me of some package managers:

  1. npm for JS (obviously)
  2. NPM for JS (really obvious)
  3. apt-get
  4. Composer in PHP
  5. The brew is to the macOS
  6. Cargo to Rust (on which Deno is built)

I think it’s a bad step not to use a package manager to manage. Package managers can do so much: versioning, scripting, managing dependencies, and so on. Why doesn’t Deno use NPM? I don’t know, but here’s what I think:

  1. First, because Deno needs the TypeScript ecology, but the latter ecology is more JavaScript. Correction: Deno also works well.jsFile.
  2. Second, a large number of NPM modules require file/network usage or more, and these denOs strictly do not provide these permissions by default. So you need to inject a lot of redundant “permissions” fields into package.json to provide more permissions. However… Deno doesn’t work with NPM, so there’s no package.json. We’ll take a look at how Deno handles modular systems.
  3. The number of NPM modules is extremely large and even bloated, but this is also the strong vitality of the Node ecosystem. Looking for a library to extract the contents of a tar file into a stream? You can choose tar-steram. Want a data format validation library? You can choose Joi. Want to work with JWT? You can select jsonWebToken. I wonder how long it will take developers to make their libraries Deno compatible?

Deno takes a completely different approach to modular systems. In any case, Deno is trying to “patch” the existing NPM module in some way. So I don’t see much point in using Deno other than trying to “hack” around a TS + Node project in a Docker container.

Based on everything I know so far about Deno, here’s what Deno really looks like:

Deno = (in most cases)[TypeScript + Node + properly configured Docker container + single executable + < various gadgets > -npm]

Done! Let’s calm down and listen to my summary.

conclusion

I’m as excited about Deno as anyone. But when Deno was ready to completely rewrite the JavaScript runtime, my expectations changed.

I didn’t mention Deno’s automated TypeScript documentation and many other nice features because I wanted this article to show another side of Deno. Since the advantages of Deno can be found in almost any other Deno article, I need to emphasize again both sides of the coin.

Frankly, Deno seems to have taken on a lot of responsibility and cost for a lot of small benefits, including a lot of debt in transferring existing NPM modules and codebase. Do you agree or disagree with me on these points? I’m excited to hear what you think. Contact me on Twitter @Mehulmpt or Instagram is also ok!

I wish good!

After the full translation, please go to @hylerrix/ deno-Tutorial repository and click Star or watch.

“Deno study of the art” ecology has now supported four directions of different warehouses, continuous construction in…

  • Deno-tutorial: The core repository, an ebook concentration, is built around deno’s full ecology of various original/translated articles.
  • Deno-feedly: Deno biweekly, Chinese/English, will be published in 2021.
  • Deno-algorithm: Want to brush LeetCode algorithm with TypeScript on deno? Maybe you can take a look at this (just open source soon, brush certain questions after publicity).
  • Awesome -deno-cn: See the name to know the meaning, Chinese community under the deno resources full map, for PR.

For more ebooks like ES-Interview built using Deno’s ECMAScript+, please follow Github@hylerrix