阅读 47

React Vue 与设计

一个幻灯片分享,现在整理成文章。

分享主要介绍了 React 与 Vue 的一些「八卦」,以及关于 API 设计的一些想法。



这里的「设计」不单指 UI 设计,还指向更广义的设计。

比如 API 设计,比如改革开放的总设计师 ...



React 与 Vue 有什么区别?可以从很多角度来讲。

也是面试比较喜欢问的一个问题,可以看出不同的侧重、不同的思考。



尤雨溪 "State of Vue" 演讲的幻灯片内容。

「传统 vdom 的性能跟模版大小正相关」,其实主要就是指 React,悄悄 diss 了一下 React。



React 作者之一 Dan,博客文章《React as a UI Runtime》中的内容。

介绍了「数据监听」的缺点,悄悄 diss 了一下 Vue。



Vue 3.0,借鉴了一些 React API 的设计。



Vue 3.0 新增的 Function-based API 设计,从 React Hooks 中获取了部分灵感。



React 社区形象大使 Dan Abramov。



丹 · 阿布拉莫夫,92 年,生活在伦敦,Redux 作者,后加入 React 团队。



Dan 的 Twitter 截图,关于自己对「代码注释」看法的转变。

从「代码应该自解释」到「怎么细致怎么来」。



Dan 的 Twitter 截图,官方吐槽自己的 Redux。

「我都不知道 4 年前写的这是啥玩意」。



React 简单还是 Vue 简单?

通常前端社区很多人会觉得 Vue 简单,其实 React 的 API 明显更少一些,理解起来概念也更少一些(好吧,在 React Hooks 出来之前)。

比如 React 中并没有 computed、watch、slot、emit 等概念。

但为什么大家普遍还是觉得 Vue 简单呢?



主要是因为,Vue 有中文文档!

而且,Vue 的文档设计与文字风格,都体现出了很高的审美水准与语言水平。



很多人以为开源是写代码就行了,其实完全不是一回事。

一旦开源,就不只是代码了,而是一个「产品」,就要考虑用户体验。

而这通常是很多程序员完全不理解也不会在意的地方。



Vue 官方文档的设计。

这一套字体、配色、代码格式的设计风格,已经成为了一种流行的文档设计风格,很多博客主题也模仿了这个设计。

跟尤雨溪一样代码水平的程序员也许有很多,但是跟尤雨溪一样审美水平的程序员就很少很少了。



与尤雨溪类似的一个人,阮一峰。

阮一峰的审美水准,不是体现在界面设计,而是语言水平。

他成为一个几乎每个前端都知道的程序员,主要不是因为他的技术水平,而是他的语文水平。



同样的一个东西,阮一峰写出来,总是更容易理解一点。

他能把一个知识点,梳理简化,输出为别人更愿意看、更能看进去的文字。

而很多程序员的文字水平,写出来的文章,只会让人感觉一团乱麻,完全看不下去。



为什么尤雨溪的「产品能力」这么出色?



尤雨溪的教育背景,跟计算机、编程开发、前端,都没什么关系。

而他的教育背景,正好让他具备了大多数程序员所不具备的审美与艺术素养。



尤雨溪的大致经历。

对 JavaScript 产生兴趣,通过一些创意项目进入了 Google 的 Five Program 工作室。

在 Google 接触到了 Angular,发现了 Angular 一些可以改进的地方。

2014 年 2 月,GitHub 上发布 Vue,Hacker News 上发贴,短时间内获得几百个 Star。

从此一发不可收拾,影响一直持续到今天。



API 应该如何设计呢?



ZEIT 的设计理念,可以成为 API 设计的一个标杆。



ZEIT 的 About 页面中,提到了三个理念。



Easy, Universal, Accessible. 这也可以成为 API 设计的理念。

重点是关于 Accessible 的描述,"To be accessible, great care has to go into the user experience and design."



"Great care has to go into the user experience and design."

这应该成为开发工作中的一个核心理念与哲学。



ZEIT 的开源项目,往往透露出一种美感。

比如 Next.js,安装完之后,控制台中一个 warning 也没有。

作为对比,很多开源项目,按照官方教程,第一次初始化,也会出现一大堆 warning,让人感觉很「糙」。



ZEIT 的开源项目,透露出一种 Open / Close / Principle 的美。

用艺术的思维和产品的思维去表现技术,这应该成为开发者的最高境界。



高内聚、低耦合,开发工作中常见的一个思想,其实还有多聚合、少继承。

但是能应用到实践开发工作思考中的就比较少了。



高内聚、低耦合,这种思想不只是在代码领域。

还可以引申到协作、组织架构等等,这是一种人类组织哲学。



目标明确、边界明确、设计优先、不迷信。

API 设计与开发工作的指导方针。



项目中应用 ESLint,使用无侵入的规则来约束规范行为。



项目中应用 Prettier,将无意义的的争议用自动化规范来解决。



感谢 GitHub。

开发工作的一个好处就是,它不像别的领域,并不知道真正优秀的东西是什么样子,大家可能陷入某个封闭环境内的迷信与崇拜。

开发工作,永远不用迷信某个小范围的前辈、不用迷信某个领导、不用迷信这个公司那个公司的大牛。

打开 GitHub,你可以直接看到全世界最优秀的开发者是什么样子。

这是伟大的信息对称,对很多领域来说是不可想象的,可惜很多人没有意识到这点。

不要将目光局限、自降上限,永远去追求最顶级的、塔尖的典范。



GitHub 上 React Reconciler 的源码



GitHub 上经典的 koa 洋葱模型实现的源码



"Eyes Forward"

不只是开发工作,更是一切的行为哲学。



谢谢。

完啦 😁


关注下面的标签,发现更多相似文章
评论