阿西河

所有教程

公众号
🌙
阿西河前端的公众号

我的收藏

    最近访问  (文章)

      教程列表

      抓包专区
      测试专区

      朱安邦聊 Deno 与 Node.js

      前言

      本文已发布到我的Bilibili个人频道,视频地址是: https://www.bilibili.com/video/bv1Zg4y1B7bq

      以下是聊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 本身做的没有问题,它官网是明确表明,同时支持JavaScriptTypeScript的;(我认为使用ECMAScriptTypeScript可能会精确)

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

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

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

      Deno 是同时支持TypeScriptECMAScript的,布道的时候,应该同时说出来,

      而且两者都是一等公民,使用上功能没有任何区别!只要会 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

      Deno 的技术先进性,并不能决定他会不会火!

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

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

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

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

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

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

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

      Deno 应不应该学?

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

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

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

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

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

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

      先把工资搞上去,岂不是美滋滋?

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

      目录
      目录