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

2020-06-01 11:32:29 +08:00
 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 的官网,会看到官网介绍是

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

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 返回内容不符合预期,我们又如何找到预期版本的内容呢,之前的内容我们怎么找呢?

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

如何锁定版本?

我们引用第三方的包,通过 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 等,学这些可以立即用于工作,对你工资和跳槽都有帮助,学这些难道不香么?

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

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


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

9596 次点击
所在节点    Node.js
46 条回复
no1xsyzy
2020-06-01 16:01:53 +08:00
@murmur #15
@whileFalse #16
俺还在想 FaaS 也行…… 原来就是 FaaS……
FaaS 的问题不是 FaaS 概念本身,而是生态撕裂吧
guolaopi
2020-06-01 16:02:21 +08:00
@murmur
我理解就是连公网 IP 和域名都不给你了,反正用户能打开你写的这玩意儿就行了。

后续发展怕不是阿里云定制版启动器可以访问阿里云上的 serverless 应用,
腾讯云定制版启动器可以访问腾讯云上的 serverless 应用?
Jirajine
2020-06-01 16:24:47 +08:00
1. deno 暂时没有解决什么痛点,这点赞同楼主。
2. node 迁移到 deno 相对比较容易,生态还是有机会搞起来的。
3. deno 可能会在 wasm 、rust 互操作等方面发力。
4. 个人比较期待基于 servo+deno 的方案用以替代 chromium+node 的 electron 、nw 等框架。
murmur
2020-06-01 16:41:49 +08:00
@Jirajine python 2.7-3.0 的迁移用了多久,现在 2.7 还没死光呢,node 迁 deno,观望
liuxey
2020-06-01 16:50:00 +08:00
@Jirajine #23 servo + deno 简直是豁然开朗,可谓神级搭配,希望有大的公司或组织能往这方面钻一钻
Jirajine
2020-06-01 17:00:11 +08:00
@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
2020-06-01 17:45:14 +08:00
@whileFalse 这么对比不对吧 , A 厂商的 serverless 方案 和 B 厂商的 serverless 方案可能很不一样 (更别说,也许还还深度整合了自己什么特色服务) , 导致最后, 根本不可能移出去 (私有部署) 吧
不是很了解, 求科普
whileFalse
2020-06-01 19:24:48 +08:00
@maomaomao001 基于 vue 的代码能移到 angular 吗
@murmur aws 不会抄你的业务。
saberlong
2020-06-01 19:31:30 +08:00
@axihe 从要干的活的角度来讲,确实没优势,要干的活没变。golang 包管理体验下来,优势是获取包只需要一个 http 下载和几个 http 接口。不用关心包管理工具自身协议和逻辑,二次定制化开发成本非常低。比如实现本地缓存仓库,内网环境代理服务,跨团代码仓库独立,跨团队包访问鉴权,无缝集成各种版本管理工具等。反证对它来说,只要通过 http 拿到,并且无篡改就好,中间经历了什么完全不在意。
saberlong
2020-06-01 19:38:24 +08:00
@axihe 做得好,完全能做到对开发人员透明。做在内网,使用内网 dns 。开发人员无需配置各种仓库等环境。
Torpedo
2020-06-01 19:57:40 +08:00
deno 总和 node 比。可是 node 的核心优势就是能直接运行 js 啊,这样不仅仅是吸引大量开发者,更是复用很多已有的 js 的代码。
如果脱离了 js,那 deno 和别的 go 、py 、java 比,没看出来有什么优势
otakustay
2020-06-01 20:35:22 +08:00
在我看来 deno 是一个理想主义者的追求,生于理想也当安于理想进而葬于理想,没必要工业化
fescover
2020-06-01 21:31:18 +08:00
node 2009 年刚出来还不是啥都没有,我们应该给点时间让 deno 发展生态。
matrix67
2020-06-01 22:12:29 +08:00
@Zitro 为啥就这个主题的风格不同,好蛋疼
fundon
2020-06-02 00:28:41 +08:00
可能前面一些布道者的言论激怒了你;但我个人理解应该对 Deno 这个新鲜事物一些时间和宽容看待,一个生态的成熟、标准化、工业化需要更多人参与进去,才能达到多赢。Node 不也是如此成长起来的吗。

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

对于个人,尝鲜、深入(现有)也可以,这个取决于每个人的兴趣、技术栈追求。
Nugine0
2020-06-02 00:55:52 +08:00
npm 兼容层有人在做,只要有轻松迁移的方案和第一个杀手级框架,相信会出现大规模迁移到 deno 的浪潮,这需要时间。

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

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

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

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

默认 ts 是一个巨大优势,没错,是巨大优势。
ts 是 js 超集,它的类型系统就是最大的卖点,不能接受动态火葬场的人无论如何也不会回去写 js,反过来转移却很轻松。向 ts 的单向转移趋势已经非常明显了。
wenerme
2020-06-02 01:06:06 +08:00
deno 的确很好,值得尝试,但是觉得 yarn2 补足了 node npm 的很多短板,特别是没有了 node_modules 开发体验真的不太一样的,有类似 deno 那种清爽的感觉,但更可控。

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

如果选择尝试 会优先考虑 yarn2,deno 在没有大型框架 (例如现在用的 nextjs 、nestjs )支持的前提下很难直接啃,作为脚本语言使用现在的模块逻辑会面临墙的问题,所以还是很繁琐。
Nugine0
2020-06-02 01:12:18 +08:00
deno 承担包管理,提供标准库,提供一系列工具,拥抱 web 标准,部分模块与浏览器直接兼容,这都是大一统的思想。对于个人来说,它不会限制开发的灵活性,而是减轻了在各种配置中折腾的痛苦。

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

吃饭看现在,追新看未来,deno + rust 的组合前景美好,值得投资。
lizz666
2020-06-02 07:52:59 +08:00
等它普及了再说
darknoll
2020-06-02 08:42:34 +08:00
这颜色闪瞎眼

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/677421

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX