尤雨溪:TypeScript不会取代JavaScript

洪少 发表时间: 2020-10-11 23:00 阅读:56 收藏:0

近日,Evrone 与 Vue.js 的作者尤雨溪进行了一次访谈,了解他对于无后端与全栈方法、以及 Vue.js 适用场景的看法,还有他本人如何在工作与生活之间取得平衡。

记者: 嗨 Evan,很荣幸你能接受我们的访谈。那就先从一个简单的问题开始:您的全职工作岗位是由 Patreon 资助的,大多数人恐怕都没有这样的机会。您能聊聊怎样在工作与生活之间找到平衡,特别是如何避免长期工作带来的倦怠心理吗?

尤雨溪: 虽然我这份工作看似自己说了算,而且大部分时间也都是待在家里,但我每天还是会遵照固定的时间表。庆幸我有孩子,所以只要完成了工作内容,我可以马上陪伴家人。另外,我会在感觉需要的时候给自己安排一段比较长的假期,可能是几个礼拜。这一点对于上班族来说可能比较困难。

记者: 厉害!Vue 3 版本即将发布,在此之后,您是打算休息一阵子,还是马上开始规划 Vite build 系统的下一个版本?

尤雨溪: 我总是存着一大堆工作。在 Vite 方面,目前的目标就是努力提升稳定性——这是一套新系统,用户总会在我当初的设计场景之外使用,所以我得花点时间思考项目的下一步要如何发展。关于 Vue 3.1,我也已经有了一点想法。但休息是肯定的,给自己充电非常重要!

记者: 您是 Google Creative Lab 中的创造力技术专家与艺术史专家。在 Vue 项目当中,您有没有感觉自己的数学、算法以及数据结构功底有点薄弱?在您看来,是不是只有学习过计算机科学理论才能成为程序员?还是说只要能写出平平无奇但却易于理解的代码就可以?

尤雨溪: 坦率地讲,我遇到的这类问题不太多。我个人觉得 Vue 或者说大部分前端框架对于数学和算法专业知识的要求不算太高——至少跟数据库比没那么高。 我觉得自己在算法或者数据结构方面的确不强,虽然提升这方面能够肯定会有所帮助,但想要管理好前端框架项目,最重要的还是了解用户、设计出合理的 API、建立技术社区并长期维护项目承诺。

我觉得编写所谓“平平无奇却易于理解”的代码没什么不好,我不太认同这话里隐藏的那种贬义倾向。 实际上,编写出这样的代码也需要一定经验,而且好代码的核心在于执行效率高而不是令人拍案称奇的实现思路。 没有接受专业的计算机科学教育当然也能编写软件,不过每一位开发者都应该重视专业教育背景带来的扎实基础。我个人一直采取比较务实的态度——先开始做事,哪怕做得不好。在做的过程中,我们会找到自己的不足之处,并确定下一阶段该从哪些方面提升自己。

记者: 说得好。借助 Nuxt.js 与 JAMstack 等技术方案,开发者得以专注于处理应用程序的前端部分,因为后端部分只需要直接交给 minimal/JS/BaaS 即可。您怎么看待这些“无后端”或者说“全栈”开发方法?

尤雨溪: 我觉得这是一种强调以技术推动产品制造的开发思路。开发者们之所以选择这样的栈,是因为它们正适合自己当前构建的产品类型:后端逻辑相对简单,而前端交互更值得关注。虽然不是什么万灵药,但这类方案确实非常适合特定一部分应用场景。

记者: Vue 已经经历过多次重写。如果时光可以倒流,您会对现在的年轻人们提出怎样的技术建议?

尤雨溪: 请一定认真思考这个问题:怎么才能更好地拆分与解耦内部模块。

记者: 最近几年来,我们发现 JavaScript 与 TypeScript 可以说是齐头并进。您是怎么看待这样的趋势的?是会最终向核心 JavaScript 当中添加某些类型,用 TypeScript 取代 JavaScript,还是做出其他选择?

尤雨溪: 我觉得向 JS 本体中添加类型的可能性不大——因为 JS 是一套由社区委员会负责类型设计的系统,而根据 TC39 委员会的运作方式来看,这事没戏。另外,TypeScript 也不会取代 JS,前者只是 JS 的一个超集。我个人认为,JS 与 TS(带类型的超集)并行发展才是最合理的未来方向,而且这一点在可预见的未来不会改变。

记者: Vue 的用户群体已经超过百万。您认为衡量技术采用率的最佳方法是什么?Stack Overflow 问题热度、GitHub 星评以及其他公共访问指标都不错,但也有不少企业用户需要在隔离网络中工作。他们提不出多少问题,但却实实在在在“使用技术”。我们该怎样把他们纳入到技术普及率的计算中来?

尤雨溪: 对于开源软件来说,核定采用率确实是个老牌难题了,因为用户并没有义务上报自己的使用情况。而作为软件作者,我们也确实没有可靠的采用率跟踪方法。也正因为如此,我才觉得 devtools 扩展用户数量应该作为最可靠的指标,因为它至少覆盖到了全体用户。

记者: 即将发布的 Vue.js 3 中包含大量摇树(Tree Shaking)处理方面的更新。在您看来,为什么摇树处理用了这么久才正式登陆现代框架?是因为里头有什么重大阻碍吗?

尤雨溪: 摇树的工作机制,取决于源代码的特定构造方式——换句话说,只有在项目起步时就在代码编写与 API 设计中考虑到摇树机制,才能保证摇树拥有最好的效果。而现在,我们之所以需要引入大量变更才能实现摇树友好,就是因为直接摇树要么会影响到 API 变更、要么需要进行重大的结构调整(这会带来严重风险)。

记者: Vue 3 当中“基于函数的组件 API”提案遭到了社区成员们的强烈反对。事后来看,您有哪些值得与其他开发者分享的观点?

尤雨溪: 社区成员们之所以反对,是因为他们担心项目管理方会废弃掉 Vue 当前的(2.x 版本)API,其实我们并没有这样的想法。作为项目作者与维护者,我们一般会在日常工作中与热心的早期采用者交互,而他们对于新思路的态度往往比普通用户更开放、更积极,这也导致我们没能对向下兼容性给予应有的重视。用户不喜欢自己熟悉的一切被他人硬生生夺走,我已经深切理解到了这一点。

总而言之,最重要的是了解用户需求。但这事并不简单,有时候我们需要投入大量精力才能获得可靠的需求信息。倾听是必须的,综合各方面诉求才能得出合理的结论。

记者: Vue 的用例范围非常广泛,从小型企业到中型代理机构,再到市值数十亿美元的上市公司皆在其中。LV 公司与美国宇航局也在使用 Vue。有哪些使用 Vue 编写的高复杂度真实前端案例,给您留下了深刻印象?

尤雨溪: 问题在于,大多数“高复杂度真实前端案例”都不开源。我觉得要回答这个问题,大家可以多看看 Vue Devtools 与 Vue CIL UI,虽然它们不属于典型的面向消费者型 Web 应用程序,但无疑都属于由 Vue 编写而成的强大界面成果。

收藏
评论区
发表评论