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

[axihe]

前言

老哥们，我叫朱安邦，想与大家一起交流下新出的 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 怎么看待的？

[BBCCBB]

不建议盲目追新技术.

虽然你是来推广你博客的 🐶

[axihe]

@BBCCBB 为了避免继续讨论我是来推广博客的，我把博客链接和 B 站频道视频的链接已经移除去掉了。

我聚的如果新技术是优秀的解决方案，感觉空闲时间学习新技术并没有什么不好，作为技术储备还是可以的；

[putaozhenhaochi]

v 站不推荐长文技术文章。下次推广记得发链接

[maomaomao001]

@axihe 哎, 起反作用了, 上 b 站 频道吧, 想看看

[jmyz0455]

楼主的 b 站我一直有看，请坚持，加油。

[Zitro]

我一直觉得 V 站的 node 节点配色太伤眼了，特别是这么大段文字

[BBCCBB]

@axihe 哈哈, 讨论的内容还是不错, 不过还是不建议盲目追新技术. 地址你贴上来吧, 还是有人愿意看

[saberlong]

我不是做前端的，deno 发布时粗浅的了解了下。关于包的问题，deno 目前只是提供的核心部分的功能，方向没什么问题。缺的是配套扩展的东西。它应该是借鉴了 golang 的方式。golang 在 1.11 版本中提供这种方式, 也就比 deno 目前状况好点。然后在 go1.13 基本已经解决了。你提到的这些问题除了[多版本共存]这个，可能需要像其他语言一样，提供条件选择编译或者选择性特性的等方式来处理。

[gwy15]

一点题外话——楼主写文章能不能按自然段组织？这种一句话换一行的公众号文风不是很适合写这么长的文章，阅读的时候抓不住重点。

[axihe]

@gwy15 非常感谢你的提醒，长文章确实按照自然段组织比较好； V2 发出去就不能修改了，这次没办法改了，以后多注意，谢谢提醒。

[whileFalse]

deno 的几个点本来就不是为了打动前端而设计出来的。

LZ 听说过 Serverless 吗

[axihe]

@saberlong 谢谢老哥，主要感觉这种方式好像并不比目前的 npm 优秀；还有就是不清楚 Deno 真正擅长的应用场景是什么方面，感觉和 Nodejs 做的事情好像差不多；虽说刚出来生态不行是正常的，但目前模式好像并不能促进第三方包的繁荣发展。

[xujiahui]

v2 node 节点这配色看的我眼花, 不过楼主的长文还是坚持看完了, 感觉写的蛮好的, 就是一下子列的问题太多了, 有点懵

[xujiahui]

nodejs 就只学了一点点, 感觉到的一个问题就是很多方法是 callback 形式的, 用 promisify 转一下也觉得有点不爽

[murmur]

@whileFalse serverless 就是个吹牛逼的概念，小厂的 serverless 叫被大厂卡住脖子，大厂的 sererless 叫高度复用，以前买了云服务器，你至少被卡的时候还有打包搬家的机会，现在好了，你的家具都是别人提供的，你只有自己走人了

[whileFalse]

@murmur #15
“VUE 就是个吹牛逼的概念。以前用 jquery，被卡的时候还能换别的库。现在好了，你的组件都是别人提供的，你只有自己走人了”

你不喜欢不等于天下人都不喜欢。serverless 能做到没人用的时候成本缩减到 0，大量流量到来的时候几乎没有扩展上限。就这一条，没有第二种技术能做到。

[guolaopi]

@whileFalse
@murmur
还专门去搜了一下啥是 serverless 。。。
果然前端也要开始面向 KPI 搞架构了吗。。
以后数据库归云服务商，服务归云服务商，连 TM 页面都要归云服务商了吗。。。
真牛逼。。。

[libook]

从新技术的角度来看，我十分欢迎 Deno 的这种新方向的探索。但同时，我很讨厌部分 Deno 布道者邪教一般的宣传手段。
参加了 2020 年的北京 NodeParty，一个自称是 Deno 核心开发成员的嘉宾直接当着所有 Node 开发者的面踩着 Node 来宣传 Deno，所使用的论据无外乎以下几点：
1. Deno 是 Node 之父开发的，因为 Node 之父认为 Node 很失败。
2. Deno 是用 Rust 开发的，因为 Rust 很高效、很安全，所以 Deno 也很高效、很安全。
3. 以后大家都用 TypeScript 了，没人用 JS 了。
4. Node 从发布到爆火用了很短的时间；现在不上 Deno 的车的话，等 Deno 爆火了就失去职业竞争优势了。
我本人从事 JS 栈开发 7 年了，对于 Rust 也有一定的了解，可以说当时的这位布道者发表的讲话中至少一半都是吓唬不了解实际情况的人的；关键是完全没有介绍 Deno 本身技术上的特性优势以及所擅长的应用场景。

楼主文章一开始提到的天时部分我是比较认同的。一项新技术的推广会遇到两个问题：
1. 潜在用户群体是否足够大？
2. 为什么要学习这个新技术而不是用已经掌握的旧技术？
对于第 1 点，Node 是使用 JS 作为语言的引擎，而且当时几乎没有相近的竞争者，而 JS 语言开发者的群体超级庞大，所以 Node 的潜在受众也是非常庞大的。
对于第 2 点，Node 亮出了异步非阻塞的杀手锏，这个虽然很多语言都能实现，但鲜有像 Node 这样深入骨髓、开箱即用，在大家正在对高并发编程津津乐道的时期，Node 自然而然就成为了焦点。

发现网上依然有人 node_modules 的黑洞梗说事，那些人怕是依然生活在 2014 年，在 2015 年 npm 发布 v3 的时候就已经把依赖打平了，剩下的逻辑依赖嵌套太深的问题是开发者的锅，也不可能简简单单靠使用 URL 引用的方式来解决。如果希望把所有项目的依赖都放在一起共用可以用 pnpm 。事实上 Node 只定义了 node_modules 机制，并没有强制要求必须用 npm，而如何利用这一机制完全取决于开发者选择什么包管理器，如今面向 Node 的包管理器有很多，即便都无法满足个人需求，自己写一个也不会很难。

Deno 虽然早期以 TypeScript 作为卖点狂踩 JS，但是只要它是基于 V8 的就肯定逃不了 TS 转 JS 的步骤，所以后来在 Deno 已经看不到那么激进的宣传了，目前官网上已经变成了“A secure runtime for JavaScript and TypeScript.”这样比较包容的文案了。我想 Deno 团队后来也不希望把自己特化成为 TS 专用引擎，而失去 JS 庞大的生态支持以及对 TS 没有需求的用户群体。

个人觉得 Deno 有两个特性是比较独树一帜的，一个是沙盒，另一个天生支持编译为 WebAssembly ；但从我所接触的 Web 开发领域来看，沙盒本身就不是一个频繁出现的需求（特别是容器化大行其道），而可以编译为 WebAssembly 也是得在有其他需求必须在 WebAssembly 环境中运行 Deno 的时候才会有用；所以从天时的方面，Deno 远不及当年的 Node，未来的推广还有很长的路要走。

有机会的话，体验一下 Deno 也是挺好的，但是不建议抱着用 Deno 来取代 Node 的心态，事实上现如今的工程凡是达到一定规模的，都不可能依靠某单一技术栈建立起来，多接触各种技术，了解技术之间的差异，能够帮助在特定的情景选择最合适的技术来达到最大收益。

[murmur]

@whileFalse 你说成本，我跟你说能不能活下来，以前玩云的时候，只是服务器租的别人的，到后面云吹大了，数据库、缓存、安全买的是别人的，这都可以理解，等到 serverless，你数据库是别人提供的轻量服务，用户是绑定了别人的账号体系，连一些核心服务（比如视频、音频、图像、语音、文本处理）都是别人的，那你还有什么意义，等别人想抄的时候，一只手就捏死你

[murmur]

@guolaopi serverless 是有意义的，但是绝对不是吹牛逼那么强，比如你开发一个动森小程序，这东西不盈利，那么自然也不应该让你付出太多成本，无论是开发上还是部署上，你用小程序的免费配额，给一群人用用也是够的，腾讯也不会蛋疼到抄这个东西来用。对于这种纯查询、不涉及状态、生死都无所谓的东西，最适合 serverless 了

[no1xsyzy]

@murmur #15
@whileFalse #16
俺还在想 FaaS 也行…… 原来就是 FaaS……
FaaS 的问题不是 FaaS 概念本身，而是生态撕裂吧

[guolaopi]

@murmur
我理解就是连公网 IP 和域名都不给你了，反正用户能打开你写的这玩意儿就行了。

后续发展怕不是阿里云定制版启动器可以访问阿里云上的 serverless 应用，
腾讯云定制版启动器可以访问腾讯云上的 serverless 应用？

[Jirajine]

1. deno 暂时没有解决什么痛点，这点赞同楼主。
2. node 迁移到 deno 相对比较容易，生态还是有机会搞起来的。
3. deno 可能会在 wasm 、rust 互操作等方面发力。
4. 个人比较期待基于 servo+deno 的方案用以替代 chromium+node 的 electron 、nw 等框架。

[murmur]

@Jirajine python 2.7-3.0 的迁移用了多久，现在 2.7 还没死光呢，node 迁 deno，观望

[liuxey]

@Jirajine #23 servo + deno 简直是豁然开朗，可谓神级搭配，希望有大的公司或组织能往这方面钻一钻

[Jirajine]

@murmur #24 Python 那是直接不兼容了，deno 和 node 都是跑 ECMAScript，语言标准一致，区别只是在一些 api 方面。
比起 node 只能调 C shared library，deno 要是能直接调用 cargo crate，直接用 rust 写扩展，你说香不香。还能像 Lua 一样嵌入到 rust 程序里面，rust 又能编译到 wasm，再加上 Mozilla 的 servo 等项目成熟以后，吸引到 npm 的生态迁移，把 js 的生态和原生高性能结合起来，用 rust 给 js 开发 web 框架，结合高性能和开发效率还有 SSR 、wasm，玩法丰富多样。

[maomaomao001]

@whileFalse 这么对比不对吧 , A 厂商的 serverless 方案 和 B 厂商的 serverless 方案可能很不一样 (更别说,也许还还深度整合了自己什么特色服务) , 导致最后, 根本不可能移出去 (私有部署) 吧
不是很了解, 求科普

[whileFalse]

@maomaomao001 基于 vue 的代码能移到 angular 吗
@murmur aws 不会抄你的业务。

[saberlong]

@axihe 从要干的活的角度来讲，确实没优势，要干的活没变。golang 包管理体验下来，优势是获取包只需要一个 http 下载和几个 http 接口。不用关心包管理工具自身协议和逻辑，二次定制化开发成本非常低。比如实现本地缓存仓库，内网环境代理服务，跨团代码仓库独立，跨团队包访问鉴权，无缝集成各种版本管理工具等。反证对它来说，只要通过 http 拿到，并且无篡改就好，中间经历了什么完全不在意。

[saberlong]

@axihe 做得好，完全能做到对开发人员透明。做在内网，使用内网 dns 。开发人员无需配置各种仓库等环境。

[Torpedo]

deno 总和 node 比。可是 node 的核心优势就是能直接运行 js 啊，这样不仅仅是吸引大量开发者，更是复用很多已有的 js 的代码。
如果脱离了 js，那 deno 和别的 go 、py 、java 比，没看出来有什么优势

[otakustay]

在我看来 deno 是一个理想主义者的追求，生于理想也当安于理想进而葬于理想，没必要工业化

[fescover]

node 2009 年刚出来还不是啥都没有，我们应该给点时间让 deno 发展生态。

[matrix67]

@Zitro 为啥就这个主题的风格不同，好蛋疼

[fundon]

可能前面一些布道者的言论激怒了你；但我个人理解应该对 Deno 这个新鲜事物一些时间和宽容看待，一个生态的成熟、标准化、工业化需要更多人参与进去，才能达到多赢。Node 不也是如此成长起来的吗。

对于工作，选择成熟、稳定、适合团队的就可以。

对于个人，尝鲜、深入（现有）也可以，这个取决于每个人的兴趣、技术栈追求。

[Nugine0]

npm 兼容层有人在做，只要有轻松迁移的方案和第一个杀手级框架，相信会出现大规模迁移到 deno 的浪潮，这需要时间。

后端方面，ts 从语言设计、开发效率和表达力等方面讲都是一流的，用 ts 写后端是一个值得尝试的选项，deno 还缺成熟的后端框架。

DENO_DIR 是可以指定的，不一定是全局，这就提供了 vendor 和项目隔离。

deno 有锁文件，能查出模块是否被篡改，不需要手动验证。

去中心化的包管理也能中心化，想想，如果 npm 下场提供 deno 模块托管会怎么样，这就能解决生态问题。

默认 ts 是一个巨大优势，没错，是巨大优势。
ts 是 js 超集，它的类型系统就是最大的卖点，不能接受动态火葬场的人无论如何也不会回去写 js，反过来转移却很轻松。向 ts 的单向转移趋势已经非常明显了。

[wenerme]

deno 的确很好，值得尝试，但是觉得 yarn2 补足了 node npm 的很多短板，特别是没有了 node_modules 开发体验真的不太一样的，有类似 deno 那种清爽的感觉，但更可控。

deno 运行时控制这一块我觉得 node 迟早会借鉴，目前本来就有针对 node 内建模块进行打包的逻辑，例如 yarn2 的 pnp 是修改 require fs 逻辑实现的。

如果选择尝试 会优先考虑 yarn2，deno 在没有大型框架 （例如现在用的 nextjs 、nestjs ）支持的前提下很难直接啃，作为脚本语言使用现在的模块逻辑会面临墙的问题，所以还是很繁琐。

[Nugine0]

deno 承担包管理，提供标准库，提供一系列工具，拥抱 web 标准，部分模块与浏览器直接兼容，这都是大一统的思想。对于个人来说，它不会限制开发的灵活性，而是减轻了在各种配置中折腾的痛苦。

安全性限制发展？如果向用户要权限会限制发展，那这个实现一定是有问题的，正常权限不会引起反感。

吃饭看现在，追新看未来，deno + rust 的组合前景美好，值得投资。

[lizz666]

等它普及了再说

[darknoll]

这颜色闪瞎眼

[maichael]

@whileFalse #28 AWS 不会抄业务，但是可以卡你 ban 你不给你用。

[whileFalse]

@maichael 有证据吗还是脑补的？

[abcbuzhiming]

@whileFalse 你在胡说什么，你的 serverless 解决了数据存储层的扩容和缩减没有?

[whileFalse]

@abcbuzhiming Aurora Serverless，DynamoDB，FireStore 一大批，不了解没必要着急下结论。

[lxml]

说了半天 deno 的缺点， 作为一名 go 程序员 简直是百感交集，

[ryanlid]

建议 2 年内不学，然后自己吃独食？