非常真诚的想和老哥们讨论新出的 Deno 和 Node.js

前言

老哥们，我叫朱安邦，想与大家一起交流下新出的 Deno，在我看来 Deno 可能不是那么的优秀，我其实对 Deno 还是比较悲观，但是也看到不少布道者还是非常看好 Deno 的，知乎上还有网上也搜索了一些答案，但是感觉好像都是根据宣传的一些转述;

目前看到的都是 Deno 的 Hello World 级别的演示，Github 上也看到不少基于 Deno 的开源产品，但是看了下质量，基本都是很粗糙的，仅仅是把东西实现出来，感觉这种粗糙的项目并不能帮助深入了解 Deno ；

一般大公司会在新技术这方面做尝鲜，请问 V2 的老哥们，你们有知道哪个大厂最近在筹划用 Deno 做一些线上的产品么？或者有没有看到基于 Deno 的比较优秀的项目；

感觉很多人和我的看法相反，我在想是不是我对 Deno 了解的比较片面，非常希望听听老哥们对 Deno 的一些看法，希望增加下了解，先谢谢了；

这篇文章是我发到博客的一篇文章，（为避免讨论我是来推广的，我删掉了链接）

以下是文章的内容：

最开始 2020 年 5 月 13 号的时候，Deno 出来后，我就开始着手了 Deno 文档的翻译

翻译完以后，我想着我再用 Deno 写一个博客，把博客开发的过程录制成视频，来抢中国区 Deno 视频教程的首发；

这可以给我的阿西河网站引入很多流量；

但是在开发博客的过程中，我发现 Deno 是一个挺无聊的发明，目前看来根本就不能用于生产环境的开发，deno 只是一个 demo ！

即使我录了一套 Deno 视频教程，里面应该也基本都是骂 Deno 的，对于想学习 Deno 的小伙伴，可能会脏了你的眼，影响你们学习心情，所以就算了；

我把我对 Deno 的一些感悟分享给大家，其实我对 Deno 态度是消极和悲观的，这个观点仅限于目前的 Deno 状况，今天是 2020 年 5 月 24 日。

Deno 的处境还是不怎么好的；

我从天时地利与人和，这方面来说 Deno 目前的尴尬情况；

天时：Deno 能不能借助当前的大环境力量

首先说 Node.js 刚出来时候的大环境情况；

Nodejs 诞生的大环境

JavaScript 并不能渗透到后端的，当时前端的地位没有现在这么强，那时候前后端分离也不流行；

开发的场景基本就是：前端写好静态页给后端，然后后端套页面，后端吐页面，前端 的 JS 代码文件，是后端页面引入的；

发布的时候，前端只需要发自己的静态文件就可以了，页面的静态文件时间戳由后端更新，也就是渲染页面的权利是由后端控制的。

这种方式目前还是适合很多对 SEO 有需求的场景

现在大家感觉这种方式很 low，但是这种方式在当时是主流，我们并不能用现在的眼光和技术水平看以前的蛮荒时代。

那时候前端话语权非常低，很多单位由后端人员代替的，低级点的前端，写写静态页就可以了，那时候前端被调侃叫"切图仔"；

前端基本上要后端脸色的，前端人员也非常希望有更多的话语权，很多公司也感觉到这种方式对人员的内耗非常严重。

前端网页是 JavaScript 一统江湖的，绕不过去，突然这时候 Nodejs 出来了，告诉大家 JavaScript 也可以搞后端。

这就是打瞌睡的人，正好有人送枕头！所以就有大量写 JS 的开发人员，投入到 Nodejs 的学习和生态建设中。

在这种情况下，小伙伴们，你们说 Nodejs 会不会火起来？？

裤裆里冒烟，当然了！

很明显的事情，Nodejs 可以让大家解决通点，可以都用 JS 写东西，一端多用，不用一会写 Java，一会写 JavaScript，这难道不香么？

由于 Nodejs 的产生，通过 React/Vue这类框架，前端终于可以把渲染页面的权利抢下来了，由前端进行路由控制和页面渲染，后端提供接口，这种前后端分离 +Mock 假数据的工作方式，已经成为目前最流行的方案；

很多前端开发者，已经用行动来表明，自己加入和支持Nodejs的生态圈。

我们再看看当下的开发环境是不是需要 Deno

Deno 诞生的大环境

首先 Deno 做的事情和 Nodjs 基本是一样的，它只是基于 Nodejs 的一些改进，并没有 Nodejs 带来的跨时代意义！

Nodejs 的推出是从 0 到 1，而 Deno 的推出，是从 100 到 101 ；

当前 Nodejs 已经发展很成熟了，Deno 目前对于前端人员来说吸引力不大；

因为 Deno 刚出来，所以比不上 Nodejs 是肯定的，但是长期来说，Deno 对开发人员的吸引力将是一个观察点；

这个观察点，我们可以从招聘网站上的岗位需求来判断，目前我没有看到前端岗位要求会 Deno，相反我看到非常多的前端岗位需求，要求会 Nodejs，或者说会Nodejs是加分项！（这是废话，这是正常的，Deno 才出来几天啊，不成熟是非常大的关系）

目前非常多的公司愿意为 Nodejs 这门技术买单，他们付出真金白银的要求你会这些技术，说明 Nodejs 的企业级应用市场是有的。

至于 Deno 的发展，招聘市场上的工作岗位需求量是非常靠谱的一个观察点，如果公司的岗位需求中，要求掌握或者理解 Deno 的岗位慢慢增加，甚至超过要求 Nodejs 的岗位，到那个时候 Deno 就属于事实上超过 Nodejs 了。

大部分人找工作都是为了钱，学更多的技术是为了拿到更多的钱，升职加薪等等，这是大多数人的想法；

公司只要有大量的 Deno 工作需求；那么市场上的培训班，自媒体，书籍等各方面，都会雨后春笋一样冒出来，也会迫使开发人员去学习 Deno 。

目前 Deno 对人员吸引程度来说，远远低于当初 Nodejs 对开发者的吸引。

我的总结是：在天时方面，Deno 没有任何优势； Deno 只是属于 JavaScript+ v8 运行时的一种尝试，最开始 Nodejs 是这样，Deno 也是一种；

整个开发者环境并不是那么迫切需要 Deno，公司对 Deno 的需求并不是那么强烈； Deno 想要解决的场景，目前已经有大量成熟的方案；

并且对前端的吸引力也不大，现在前端的流行框架React/Vue都是基于 Nodejs 生态的，如果你想深入搞前端，那么搞懂 nodejs 会让你事半功倍，只要你写React/Vue这类项目，无论你嘴上支持Nodejs还是Deno，你都是行动上支持了Nodejs，目前Deno也还没有React/Vue/Angular这样杀手锏一样的框架。

Deno 目前的情况是，在大前端开发人员这边，已经有成熟的 Nodejs 场景，完全没有必要搞 Deno ；

在后端语言那里，已经有 Java，C#，C++，Go 等语言，Deno 也没有比他们更出彩的地方；

所以 Deno 是非常尴尬的，Deno 想要做的应用场景，目前都有成熟的解决方案，它也没有在事实上解决什么业务上的痛点。

地利：相同的解决方案，Deno 是不是做的更好？

Deno 是刚出来，如果他的解决方案是更好的，吸引到越来越多的人参与其中，那么翻身只是迟早的事情了；

我们来看看 Deno 的潜力如何；

Deno 看着宣传挺唬人的，但是我们真正仔细研究会发现，现实并不是宣传的那么美好！

首先 Deno 功能和 Nodejs 类似，他没有解决新的业务需求以及痛点。

一般这类框架级别的东西被发明出来，宣传的时候都是解决某个场景或者痛点；

但是 Deno 的宣传却不是这样的，我们打开 Deno 的官网，会看到官网介绍是

• 默认为安全，除非手动开启权限。
• 默认支持 TypeScript 。
• 仅一个可执行文件。
• 有内置的小工具。
• 拥有一组标准模块库。

看完这个我当时在想，这些都是边边角角的，所有的生产项目，都不会因为你这个几点来使用的；

Deno 的目标是什么呢？ Deno 想干啥呢？就是你想解决什么痛点呢？

直到现在，Deno 官网还是没有这类的介绍。

抛开 Deno 的目标，我们就单单看 Deno 目前的介绍，会发现，Deno 解决了一些问题，同时又引入了更大的问题。

Deno 解决了本地项目node_moudule问题，又引入了更大的坑

Nodejs 大家吐槽最多的，就是node_moudule的相互引用的层级依赖问题，Npm 的套路是有 2 套node_moudule； 本地有一套node_moudule，全局也有一套node_moudule，这两套是可以完全没有关系的。

Npm 还有临时安装的实现，比如我想使用vue-cli或者create-react-app的脚手架工具，来创建项目；

因为这两种脚手架都是一直迭代的，所以使用最新稳定版来安装项目，也是不错的选择；

如果我在全局安装create-react-app或者vue-cli，那么每次做新项目，我如果想要使用最新的脚手架来生成项目，我只能每次都要更新全局的依赖；

如果我使用 npx create-react-app my-app 就是不错的选择，npx会临时下载下来，使用完以后就删除掉，每次都会使用最新的版本来生成项目。

Deno 的套路是，在项目本地没有依赖文件的，它的套路是把依赖文件都下载缓存到全局； Deno 没有本地依赖的概念，也没有临时安装的概念（只是当前，后期可能也会改进）；

这样做的好处就是，项目本地看着不那么臃肿，因为它的依赖都存在全局了；这么做的缺点是没有本地依赖环境，Deno 的这方面功能没有 Nodejs 强大；

如果你项目 A 有一套依赖文件，项目 B 有一套依赖文件；此时你想删除项目 A 的所有依赖文件，但又并不想影响到其它任何项目。此时在 Nodejs 是可以做到的，当时在 Deno 里是没办法实现的；

项目的依赖都在全局的DENO_DIR里了，项目生成的代码和缓存的源码都在DENO_DIR里。

此时你想删除项目 A 的所有依赖文件，如果想准确删除，只能一个一个手动删除了，或者暴力一点，直接清空DENO_DIR目录。

清空后，再次运行的项目 B 时候，会重新的下载依赖；

但是此时 B 项目下载的依赖，能保证和之前的依赖文件一样吗？？这就引入到了下一个缺点。

Deno 使用去中心化的仓库

对于 npmjs.com 搞 Nodejs 的肯定门清，npm 是推动 node 蓬勃发展的重要根据地。

任何人都可以在 npm 上发布包，只要写合法的 package.json 文件就可以了，比如你在 package.json 文件里面指明 main 入口文件，name 、license 、description 等字段来说明这个包，也可以放练习方式和 git 仓库地址，issue 地址，别的开发者使用过程种有问题，可以通过package.json文件的信息与包作者进行联系。

但 Deno 的作者认为 npm 它是中心化仓库，Npm 的解决方案并不好，所以它搞了去中心化的思路

我本人是从事区块链方面的开发，基本每天都是与这种去中心化解决方案打交道；

区块链行业，现在已经有完善的去中心化解决方案，但是这一套并不适合 Deno 这种场景；

当我看到 Deno 这个包引用和管理机制的时候，瞬间感觉 Deno 这种方式是非常不合适的；

我预测，Deno 的这种通过 URL 引入和管理包的模式，必定会限制 Deno 的发展，如果 Deno 不修改或者没有尽快提出更好的解决方案，Deno 绝对会被这种方式给拖累；

如果你要通过去中心化的方式来解决包引入的问题，那么你随之而来的工作就是要解决源文件的可靠性问题；

Deno 的去中性化的可篡改性

比如我在 Deno 包怎么封装？ 这篇文档里，写了一个封装 Deno 包的 DEMO，地址在 http://deno.axihe.com/demo/hello.ts

项目引入的时候，直接 import 就可以了

// 注意，这里引用的包是第三方的包
import "http://deno.axihe.com/demo/hello.ts";

你在今天看到的是现在这个样子，你把项目写好后传到 Git 仓库；

你能保证明天这个 URL 还能返回你意料之中的文件内容吗？

假如你的同事明天上班，拉了 Git 仓库的代码，发现引入一个新的包，但是运行发现，项目跑不起来，通过排查，发现原因是第三方的包，内容更改了，你此时有没有崩溃的心情和骂娘的冲动？

吃一堑长一智，有过这个坑以后，我们肯定会为项目添加文件校验，这个校验是我们能做的；

假设我们项目中使用的每个第三方的包，我们都算出一个 Md5 值储存，每次下载的时候，都用下载的最新文件计算的 MD5 值和以前配置中的 MD5 值做比较。

如果 MD5 值不匹配，那么就提示依赖被修改了；

但是即使我们发现 URL 返回内容不符合预期，我们又如何找到预期版本的内容呢，之前的内容我们怎么找呢？

而且如果这么做了，我们把校验给做掉了，可以保证不符合预期的内容都会被提示，但是又引入两个新的问题；

• 包的作者，如何小幅度更新自己的现有包？

  • 比如第三方包，某一个地方想优化一下，改善下算法，并不影响现有更能，只想从1.0.0 更新到1.0.1，这个包已经发布出去了，如何更新呢？
  • 我是更新原有 URL 的文件呢，我还是使用新的 URL 呢？

• 包的作者和开发者，怎么实现多版本共存呢？

  • 比如 jQuery 的作者，做了一个 1.X 的版本，对低版本浏览器的兼容版本；但是也有其他版本，使用新特性提高效率的版本；
  • 类似这种场景，开发者和包作者应该怎么解决？目前看来只能通过不同的 url 路径来控制，通过 url 地址不通来区分。

  http://deno.axihe.com/demo/1.0.0/hello.t
  http://deno.axihe.com/demo/2.0.0/hello.t
  

如何锁定版本？

我们引用第三方的包，通过 url 返回内容发现，这个包已经更新了，

我们如何找到预期版本的内容？？

URL 对应的文件被修改了，它曾经的文件，如果不是特意做备份，我们好像恢复不了了。

Deno 如何解决隐私包的问题

我们公司内部，有好多场景是我们封装的包，只打算我们自己团队内部使用，不想开放出去；

类似我们公司的这种场景，Deno 怎么解决呢？

Nodejs 项目上，我们也有很多私有的包，最开始我是搭建 Npm 私服，但是运行一段时间，感觉这类方式非常不优雅，后来改为的方式是私有的 git 仓库；

package.json 里的包对应配置使用 SSH 方式加 git 仓库地址就好了，仓库只需要添加团队内开发者机器的 SSH 公钥就可以了；

如果在 Deno 里面，它的引入包机制，仅仅是 import 引入 url 来处理，没有别的机制；

我们就只能通过拨 VPN 来下载依赖了。

目前官方还没有明确给出什么解决方案，也比较期待后续有什么好的方案来实现。

Deno 包的搜索问题

我们平时写项目，用到第三方包的概率非常非常大，目前第三方包的搜索是 Deno 官网做的；

目前我们想要找第三方模块，都在官方的 Third Party Modules页面上；

如果我想把我的包发布出去，我需要在他们 Github 上特定仓库提交我的申请，官方通过后，其它开发者才可以搜索到；

这种方式并不适合生态的建设，第三方包的作者可能因为这个原因放弃到官方上申请，从而导致搜索不到更多优秀的包，而且 Deno 官方也要在这上面浪费大量的时间和精力。

而且又带来一个问题，因为所有包都是官方审核的，如果我的项目使用官方审核通过的包，生产环境出问题导致有利益损失，那么是不是可以向 Deno 官方讨一个说法？

如果 Deno 没有责任，那么肯定就是 Deno 只是一个平台，不能控制作者上传什么，如果是这样，那么还有必要进行审核后再发布么？

而且这种明显是限制生态的行为下，Deno 又准备通过什么方式吸引开发者来追赶 Nodejs 的生态呢？

这也是一个非常重要的观察点，我们要看看 Deno 后续是怎么处理这些事情的。

上述 Deno 的遇到的问题，Npm 都有成熟的解决方案

我说的 Deno 的这种问题，都是企业开发的时候，需要考虑的问题；

Npm 都有成熟的解决方案 , 而且 Deno 宣传的时候，很多布道者也不老实，不说实话，说 Npm 是中心化的仓库；

他们说的是 npm 官网，但是却不提 npm 的 package.json 也是支持去中心引用的，package.json是支持任意 Git 仓库的，也可以去中心化，这点要说明一下；

Deno 宣传时候要基于 Nodejs 缺点，做一个更好用的 Deno，那么这些问题又该怎么解决呢？

Deno 的方案只是解决了去中心化，却引入了很多缺点；

Deno 项目方和布道者也并不能用 Deno 还是个孩子，还在进步来解释；

如果这种第三方包的核心问题解决不了，Deno 生态怎么蓬勃发展呢？开发者的学习信心如何鼓舞？

这是一个非常有影响的因素；

默认支持 TypeScript 有利有弊

首先我们要确认一个观点，TypeScript已经非常流行，越来越多的人使用 TypeScript，这个是毫无疑问的；

但是这并不能断定，后续没有更好的框架啦，后续可能还会有更好的同类产品来替代它；

而且后期 ECMAScript 也可能更新的和TypeScript类似；目前ECMAScript也正在这方面发展，那么到那个时候开发者就会像当初抛弃CoffeeScript一样抛弃TypeScript;

到那个时候 TypeScript 就不是优点，而是包袱了；

Deno 本身做的没有问题，它官网是明确表明，同时支持JavaScript和TypeScript的；（我认为使用ECMAScript和TypeScript可能会精确）

但是很多布道者宣传的时候说TypeScript 是学习 Deno 的基础，大概意思是现在必须会TypeScript了，贩卖一波焦虑后，然后再推荐TypeScript课程，卖卖课！

这个贩卖交流再卖课的套路，对于自媒体来说是对的；

首先我觉得恰饭是对的，但是这种恰饭的同时，有失公允的夹私就不对了，想方设法的往 TypeScript 上面引导，是很不好的现象。

Deno 是同时支持TypeScript和ECMAScript的，布道的时候，应该同时说出来，

而且两者都是一等公民，使用上功能没有任何区别！只要会 JavaScript 就可以写 Deno，会不会TypeScript都不影响 Deno 的学习；

在做这个基础上然后推荐使用TypeScript，再卖课，我觉得是没有问题的；

布道者如果不同时说，很多新手还以为只能TypeScript呢；

很多人感觉新手不会这么傻，自己去看官网不就好了；话是这也说的，但是很多新手学习还是大部分从视频，文章，中文文档入手的，布道者的推动影响力还是会影响不少人的。

Deno 同时承担了运行时和包管理器的角色

Deno 自带编译和测试构建工具，Deno 同时承担了运行时和包管理器的角色

很多人感觉这个是优点，我认为这个是缺点；

Angular 在国内没有React/Vue火，除了它本身版本 1.0 和 2.0 相比的迭代问题；

另外一个点就是它做的大而全，当初React/Vue布道者，怼Angular的一个主要点，就是大而全，不灵活；

真实开发中定制化的需求很多的，做得大而全是一种方案，优点和缺点都很明显；

如果你用 Nodejs 的包，感觉 Npm 不好，那么你可以用yarn来管理包。

如果你感觉把包发到 Npm 官网，太中心化了，你想去中心化；那也是没有问题的，你放在自己的 Git 仓库，比如放 Github 仓库，npm 直接从 Github 上拉依赖，这也完全可以啊；

但是如果你使用 Deno，如果你不想使用官方的这种方式，你有没有别的选择呢？

主流思想和去耦合和模块化，就是实现一个东西，做成模块化的，互相之间不存在必然的联系，这样维护和迭代会比较方便；

很多方面 Deno 团队并不专业，人员一时也做不过来，这是一个事实，Deno 现在发出来的稳定版，它的标准库还有很多unstable的地方；

这种情况下，就需要更多的第三方包的开发者来维护生态；

Deno 在没有那么多精力全面把控的情况下，同时做了这么多的事情，可能并不是好事情。

结论就是：Deno 做的事情比 Nodejs 多，但又没有什么明显的优势。

安全性或许会限制发展

Deno 增加了安全性，首先要承认 Deno 的安全机制是比 Nodejs 好的，这是一个优点；

这个优点再国内的企业级应用中，就是一个缺点；

真正做产品的时候，需要做的业务，一般都会迫使开发者想方设法的多要权限；

如果选择 Deno，这种让自己放弃权限的行为，我认为可能并不会特别受欢迎；

我们做技术，是服务于公司产品的，国内为了赚钱，产品为了达到目的都会各种骚操作，比如大家经常吐槽的苹果手机剪切板的权限问题；

公司不关心你什么技术，解决问题就好了，你用什么技术，这是你们技术部的问题；

如果使用一门技术让自己限制太多，别人的产品能实现，你弄 Deno 不能实现，领导层会怼你的"是不是能力有问题？"；

同时 Deno 也给出了方案，你也可以开启全部权限的；

Deno 真实项目中，开发者可能并不会严格按照需要的权限来控制，基本-A要全部权限；

如果是这样的话，Deno 的安全机制，是不是又显得不那么安全了？

这只是我个人对可能发生的一种猜想，还需以后慢慢观察。

其它是后发的原因

Deno 的标准库不稳定，生态差等等，这些都不算明显的缺点；

因为刚刚发布，也不能直接和 Nodejs 这么多年的成果相比较；

这也就导致，目前 JS 的服务器运行时，还是要选择 Nodejs 的。

人和：Deno 生态系统的建设

我有一个小网站，阿西河前端教程，主要是分享大前端相关的技术。

视频的开头，我也说啦，Deno 刚出来，我就翻译了文档，搞了 Deno 教程，Deno 文档等；

然后准备用 Deno 做博客，出一个 Deno 的博客搭建教程，想蹭一波 Deno 的热度。

但是实际开发中，感觉 Deno 这种的模式下，真的非常不好。

我作为一名潜在布道者，我是对 Deno 失去信心的，懒得做教程抢首发！

我只是个体，那么再看其他自媒体，UP 主，以及技术布道者的态度。

首先是同为 B 站大前端 UP 主的技术胖，https://www.bilibili.com/video/BV1Ev411z7Dt

他的结论我是认同的，但是它说的 Deno 优势，我认为只是看官网以及一些社区说的，他自己肯定没有真正的写过 Deno 项目，并没有去真实的了解实际的 Deno 开发；

而且技术胖说的九阴真经和易筋经的比喻也是非常有误导性的 !

技术胖的观点是现在公认非常厉害的 Nodejs，是 Ryan 一手创造的，他能写出 Nodejs 这个厉害的大杀器，那么它基于 Nodejs 缺点的 Deno 肯定就是另一个大杀器；

我认为他的观点是一个伪命题，Nodejs 的今天成就，是由 Ryan 提出的一个方向和雏形，但是 ry 感觉 nodejs 缺点很多，已经脱离了它的设想和规划，他很不满意，Ryan 在 2012 年就离开社区；

他在 2012 年离开以后的社区工作已经与 RY 没有什么关系了，我认为 Nodejs 的蓬勃发展是 2015 年开始的，Nodejs 能有今天的状态，大部分是社区贡献和维护的成果，并不是 Ryan 的个人成果；

更多人的观点如下：

• 为什么我仍然认为 deno 是下一代 node
• i5ting 的分享: Deno 不是下一代 Node.js ！
• 如何看待 deno 1.0 ？
• 如何评价 deno 对于 Node.js 的优势？
• Deno 会取代 Node.js 吗？
• 已经 2020 年了 Deno 现在怎么样了?
• 我不看好 Deno
• 如何评价 ry(Ryan Dahl)的新项目 deno?

我是如何看 Deno

Deno 的技术先进性，并不能决定他会不会火！

Deno 的生态才是核心与王道；

以前类似 Deno 想要打 Nodejs 的这种场景有很多；

出现最多的就是有语言想要吊打 Java，但是 Java 好像并没有受到多少影响，生态系统强，所以使用的人多，公司的岗位多，这样的良性发展是很难超越的。

目前 Nodejs 的生态好，开发人员多，公司岗位多，这也是一种良性循环。

Deno 想要在 Nodejs 目前的应用场景下正面硬刚，那么结果会很惨的；

Deno 如果避开 Nodejs 的应用场景，专注别的场景下的方案解决，猥琐发育还是可以的，但是这又可能错失很多发展。

我认为 Deno 最终的结果，可能是平平淡淡，不温不火的状态。

Deno 应不应该学？

我认为 2 年内不要学，首先它并不会辅助和提高你现有的技术栈，对你的工作可能没有什么帮助；

大公司为了探索，他们会使用，但是大公司用不用我们根本不用叼它；

只有在中小型公司大量被使用的语言和框架，这类的才是真正的火起来；

判断一个要不要学的一个标准是：大量中小型公司的前端招聘里，要求会或者了解 Deno 加分，那时候再开始学；

那时候 Deno 就已经很成熟了，学习文档和视频也会有很多，很多坑已经被前人补好了，就很成熟了。

即使你的时间很富裕，你把时间用来搞 Vue/React，搞 Node 等，学这些可以立即用于工作，对你工资和跳槽都有帮助，学这些难道不香么？

先把工资搞上去，岂不是美滋滋？

最后发表我的观点：我学技术是打算用来赚更多钱的，如果企业不愿意为这门技术买单的话，不能赚钱我还学个毛。

上面是我的一些看法，老哥们是对 Deno 怎么看待的？