Why do I think DeNO is a JavaScript runtime going in the wrong direction?


Why do I think DeNO is a JavaScript runtime going in the wrong direction?

Translator’s Preface

In for《DeNO’s research skills》When the first translation article was introduced, I saw this article. At that time, I still felt that I couldn’t control it, so I wrote some entry-level DeNO articles first.

In the twinkling of an eye to 2021, from《DeNO biweekly》The first issue continues to start a new year’s journey of DeNO, so I recall this article. I feel that I can understand DeNO from another angle after reading this article and related articles, and then translation begins.

Compared with the previous direct translation of the article, this article has many places to take notes (even “eye opener”), so it is unique to open up the “translator’s preface” chapter of this article to sort out the original text and Its Related videos on the other side of DeNO.

Just as the original text said, this is bound to be a controversial article. From the two videos introduced in the article, the number of clicks is slightly greater than the number of likes, and the comment area is full of “hot” discussions, we can see the collision of multiple views. There are also some over criticisms in the original text, but it does not prevent the following translation from restoring the original author’s point of view one by one!

So, in the original text and the two videos, the original author Mehul wants to say why DeNO is not so good? His views are summarized as follows

Note: if you want to read the original text first, you can skip reading and look at this simple summary later.

  • DeNO and node doCompetitive relationshipBecause you have to make a choice in your next project.
  • What DeNO is doing nowThe results are not manyMost of the features can be solved in node ecology.
  • URL importIt’s still a disaster. There are many star projects in NPM, such as “only one line of code“, “stealing user data secretly”, “injecting mining code”, “compatibility problems affecting many upstream libraries”, etc. URL import itself can not solve these problems, let alone a strong community like node to ensure a trusted dependent library, There won’t be more developers willing to join the DeNO ecosystem.
  • becauseTypeScriptIt is a superset of JavaScript, so you can choose to skip type verification. At this time, it is recommended that novices directly use typescript on DeNO. The programming pit will be very large, and a lot of any types are likely to appear. In the case of frequent debugging errors, the learning cost of typescript is high, and it is easy to write low-quality code.
  • TypeScriptIt doesn’t run directly on DeNO. In fact, it has become JavaScript. Why should it be integrated into DeNO?
  • securityIt’s a very difficult thing, DeNO’s propaganda of his “safe sandbox” is bound to bear a lot of responsibility. There is no need for DeNO security sandbox, which can be supported by docker and other containers or virtualization technology. At the same time, scripts that really want to destroy will find their own way to avoid security problems.
  • According to the current versiondeno --allow-runRun the main process so that the opened sub process can easily break through the verification of the security sandbox to obtain more permissions. For example, it is found that DeNO’s“Safety sandbox”It’s not as safe as it’s said.
  • There’s no need for DeNOIntegrating too many tool chains(code formatting, testing tools, typescript, etc.) in one, let all kinds of third-party tool chains build ecology together, at the same time, ensure the focus of DeNO itself and provide more friendly plug-in support.
  • Asynchronous model of nodeIt wasn’t eliminated, promise and event listener models have not been eliminated, so it is uncertain how DeNO will solve these problems.
  • In the future, it is not sure how many developers will be willing to gradually build mature libraries in NPMMove to DeNO

It can be seen that whether you are a node developer or a DeNO enthusiast, there are many things worth thinking about in these views. But there are also biases. For example, DeNO is described as a programming language, and DeNO’s ecology, which has only developed for more than two years, is compared with node ecology, which has been built for ten years. DeNO is destined to have its own unique development path.

Finally, the author Mehul summarizes the real face of DeNO v1.0 in his eyes

DeNO = (in most cases) [typescript + node + properly configured docker container + single executable program + < various gadgets > – NPM]

The translation begins

So far, I haven’t found any on YouTubecodedamnThe same channel (more than 100000 developers subscribe) is not excited about the release of DeNO v1.

Last week, I posted a video on my channel about some of the reasons why I don’t think we need DeNO – another JavaScript runtime based on V8 and node. These reasons are very simple to me.

At the same time, through this article, I can expand the video to explain more reasons. But if you want to watch the video first, take a look at this:

Why DeNO will fail — my view of node.js V / s DeNO

Why do I think DeNO is a JavaScript runtime going in the wrong direction?

To prove that I’m not against DeNO or even JavaScript in general, I’d like to state that I like JavaScript better than many other programming techniques. My main technology stack is only around JavaScript – node / react / mongodb / react native / nativscript / ionic / and even more related libraries you can think of.

I also mainly use JavaScript as a language, so let me use itYouTube channelAnd oneDeveloper PlatformThe number of subscribers reached more than 100000.

But the important thing is that it is very important to see the two sides of a matter from a fair and objective perspective. Of course, there is a good side to DeNO, but there is another side that most people haven’t seen / written about yet. Let’s have a look!
be careful:_ This article is destined to be a controversial one. Let’s be polite and control our emotions first. I would appreciate it if you could read the full text carefully until the end, and then say more about your ideas_
I’ll list my social accounts at the bottom of this article, and I hope we can have more good discussions on this topic.

DeNO vs node: a real competitive relationship

A lot of people in the industry are saying: “there is no competition between DeNO and node. They can learn a lot from each other.”.

To some extent, I agree that node and DeNO can really learn from each other. But is there really no competition between the two? I totally disagree with this point of view.

Let’s revisit the common features of DeNO and node

  1. They are JavaScript runtime environment;
  2. They can run on any computer that can run V8;
  3. They are supported by ECMAScript standard;
  4. They are all being actively maintained.

If you have been a fan of DeNO for the past two years, it is impossible to use DeNO as the technology selection of new projects without choosing node.

Similarly, if you have never used typescript before and think you want to try DeNO, it will be difficult for you to use all kinds of modules in NPM ecology at the same time.

So: the developers of DeNO and node do have differences at the moment – you have to make a choice, and I would like to say that this is a very important example of the competitive relationship between them.

What’s good about DeNO?

First of all, I need to list the advantages of DeNO’s propaganda on himself. Why does DeNO say that he is a better runtime

  1. It overcomes some shortcomings of node;
  2. It is a safe runtime environment by default;
  3. It has built-in typescript support;
  4. It decentralizes promise’s support to the bottom layer;
  5. It is built on rust language (compared with C + + for node).

In the following chapters, I will focus on each of the above advantages of DeNO to see what node can learn from them. I will also explore, when necessary, why DeNO is not so meaningful.

Where did DeNO paint the lily?

Let’s start to pick up the unique selling proposition of DeNO and analyze them one by one

Default safe runtime environment

It’s a very popular feature in DeNO, and I’m surprised. DeNO directly supports a secure sandbox environment by default, unless you explicitly choose to enable access to the file system or network and other functions.

DeNO does this because it wants to be closer to the browser. It’s nice that DeNO adheres to the ECMAScript standard, but why is he so keen to get close to the browser first?

Perhaps the answer is that DeNO wants to maintain good compatibility between the code written on the client and the server. But DeNO wants to support the browser so strongly that I think the direction is a little bit wrong, even a little too far.

Although node does not support “safe runtime”, after careful consideration, I think it is reasonable to support node:

  1. As we all know, you should not run untrusted code and executable files on the system. That’s why we always choose a library like express to node (rather than a library that claims to be 100 times faster than express). Trust comes from the extensive use of the community.
  2. I don’t know of any programming language that provides such a sandbox environment as DeNO. Although this function may be good, it seems that it should be done by 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. Sandbox isn’t that easy – I’m not an expert on network security, but I think the more functions there are, the more attack areas there are. DeNO promises to provide a secure runtime environment, but I want to say that security is difficult to achieve. DeNO’s commitment brings huge security responsibilities. The world’s largest companies need to invest hundreds of millions of dollars a year for independent developers and security companies to support their white hat program. So where will DeNO take their “security environment”? Time will tell.

So, what can node learn from DeNO? I want to say that I won’t learn too much. Node may introduce some identification of security environment from competitors, but it doesn’t make much sense. If you want to run some unknown code on your system, you’d better clone a C / C + + repository and run the make command to damage the system.

If you ran arbitrary code on your systems, you might as well clone a C / C + + repo and run a make command over it and get your whole system compiled.

As far as I know, you can’t sandbox file systems or network access in underlying languages like C / C + + – it’s not efficient.

Note: Recently I found that--allow-runThe DeNO of the flag can do almost anything. The video introduces the related contents in detail

Breaking through the safety sandbox of DeNO — DeNO is not safe

Why do I think DeNO is a JavaScript runtime going in the wrong direction?

Built in support for typescript

Cheering for the progress of typescript at this stage, I’m glad DeNO supports typescript out of the box.

Note:  thank@lilasquared It is pointed out that DeNO can also run out of the box  .jsDocuments. This paper focuses on the use of  .tsFile writing code. Of course, DeNO can run the. JS file directly.

But let’s take a step back: do you know why JavaScript and node have tens of thousands of developers around the world? Because the barriers to entry are almost zero. JavaScript is flexible and allows you to make a lot of mistakes. Typescript will always give you some strange mistakes.

It’s bad for production level applications: you don’t need these trendy things in a production environment. At the same time, for learners, JavaScript is tolerant. Even if you may encounter some bugs, you can easily correct them. To quote a sentence, JavaScript can be quickly coded and get things done.

For beginners, I’m worried 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 may see a lot of such code:

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

Typescript is a superset of JavaScript. You can inadvertently write a very poor quality typescript code, just using typescript will not make your project impeccable.

Until you remember that you could have written typescript in node, this experience is really interesting. I believe that now every large company that uses node in a production environment has introduced typescript to write Projects – without exception. When you’re dealing with a lot of files and their dependencies, dealing with a lot of code, JavaScript is really hard to expand.

Typescript is a revolutionary toolkit in JavaScript ecosystem, which better supports both static and dynamic languages.

Therefore, DeNO declares that it will have built-in typescript support. But I want to ask why it has to be like this? Indeed, if it is not built-in, it may need to introduce Babel and webpack to complete this work. But isn’t it important to build ecology around a bunch of third-party tool chains? Don’t we want to enhance DX?

Translator’s note: DX, developer experience, is short for developer experience. When the user of a software or system is a developer, the developer experience (DX) is equivalent to the user experience design (UX).

JavaScript will still be JavaScript, keeping its own style. Besides, if DeNO can run typescript (or typescript like language) directly, I don’t think it’s a problem. In fact, DeNO just converts typescript code into JavaScript code and runs it.

From these perspectives, it can be seen that DeNO seems to be an integrated version of various tools under node. DeNO includes a testing tool, a code formatter, typescript, etc. at one time. I prefer a streamlined programming language and add plug-ins myself when appropriate – of course, I can’t represent all developers, that’s just my point.

Why do I still need a built-in code formatting tool when I have a prettier library that focuses on code formatting? Why should we solve this kind of good thing?

Single architecture does provide a lot of tools together, but it is also really huge. A more streamlined and focused core library can better maintain and expand.

Promise’s support goes down to the bottom

Compared with node, the release of DeNO V1 doesn’t make much sense to me. I have great respect for the founders of node and DeNO, but node has something that DeNO doesn’t have – the support of many experienced developers around the world.

Node is contributed by nearly 3000 developers and is the leader of asynchronous I / O event processing. DeNO does build on rust and exposes an abstraction similar to promise. But node has C + +, 3000 developers and more than 10 years of development and maintenance.

Node’s asynchronous model has not been eliminated, neither have promise and event listener models, so I’m not sure how DeNO will solve these problems.

Goodbye, NPM

The important thing is that DeNO doesn’t support NPM. Ryan (the creator of node and DeNO) is promoting the relevant features of go language. Let me think of some package managers:

  1. npm for JS (obviously)
  2. NPM for JS
  3. apt-get
  4. Composer for PHP
  5. Brew for Mac OS
  6. Cargo to rust (DeNO is built on rust)

I think it’s a bad step not to use package manager to manage. There’s too much package manager can do: Mark versions, write scripts, manage dependencies, and so on. Why doesn’t DeNO use NPM? I don’t know, but here’s what I thought:

  1. First of all, because DeNO needs typescript ecology, but the latter ecology is more JavaScript. Correction: DeNO also works well.jsDocuments.
  2. Secondly, a large number of NPM modules need to use file / network or even more conditions, and these denos are very strict, and 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 can’t work with NPM, so there’s no package. JSON. Next we’ll see how DeNO handles modular systems.
  3. The number of NPM modules is huge and even bloated, but this is also the strong vitality of node ecology. Want to find a library to extract the contents of tar file into stream? You can choose tar steram. Want a data format validation library? You can choose joi. Want to cooperate with JWT? You can choose JSON web token. I wonder how long it will take for developers to make their libraries compatible with the DeNO system?

DeNO takes a completely different approach to modular systems. But in any case, DeNO is trying to “patch” existing NPM modules in some way. So I don’t see much significance in using DeNO except trying to “hack around” a TS + node project in the docker container.

According to what I know about DeNO, this is what DeNO is now

Deno=(in most cases) [typescript + node + properly configured docker container + single executable program + < various gadgets > – NPM]

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


I’m as excited about DeNO as anyone else. But when DeNO was ready to completely rewrite JavaScript to run, my expectations changed.

I didn’t mention many nice features like DeNO’s automated typescript documentation, because I hope this article aims to show the other side of DeNO. Because the advantages of DeNO can be found in almost any other DeNO article, I need to emphasize the two sides of the coin again.

To be honest, DeNO seems to have taken on a lot of responsibility and cost for some small benefits, including transferring the debt of existing NPM modules and code bases. Do you agree or disagree with my views? I’m looking forward to your idea. Contact me on twitter@mehulmptorInstagramit’s fine too!

Good luck!

Welcome to@hylerrix/deno-tutorialA star or watch in the warehouse.

“DeNO research” ecology has supported four different directions of the warehouse, continue to build

  • deno-tutorial: core warehouse, e-book center, all kinds of original / translated articles around DeNO.
  • deno-feedly: DeNO biweekly, bilingual, summarizes the news of DeNO every two weeks, the work of 2021.
  • deno-algorithm: want to use typescript to brush leetcode algorithm on DeNO? Maybe you can take a look at this (it’s only been open source for a long time, brush some questions and then publicize).
  • awesome-deno-cn: see the full map of DeNO resources in the Chinese community for pr.

And more e-books built using the DeNO ecosystem, such ases-interview(ECMAScript + interview Dictionary) and so on[email protected]

Why do I think DeNO is a JavaScript runtime going in the wrong direction?

Recommended Today

Looking for frustration 1.0

I believe you have a basic understanding of trust in yesterday’s article. Today we will give a complete introduction to trust. Why choose rust It’s a language that gives everyone the ability to build reliable and efficient software. You can’t write unsafe code here (unsafe block is not in the scope of discussion). Most of […]