你可能不需要React

建议时长： 🍱 10分钟

“反过来想，总是反过来想。” —— 查理·芒格

背景 🐣

“前端不就是个切图的嘛！”如果你听到这话很淡定，或者回答“啊，对对对！”，说明你已经是个“成熟 🥳“ 的前端了。其实在Node.js的出现之前，我个人觉得，切图仔的形象还是挺适合用来自我调侃的，这就像母校一样，只能我自己吐槽调侃，别人可不太行。其实我们大可以换个高情商的说法，比如视觉（UI 👀 ）交互工程师。

上面的小故事其实也在提醒着我们，前端的首要职责是关注UI界面的开发。为什么需要重新提起这个事呢，因为不知道从什么时候开始，页面/组件性能逐渐变成主流，导致我们经常过早地进行所谓的优化，难免会出现本末倒置的情况。

说白了，我觉得我们应该关注页面和交互设计的代码是否清晰可读，如果不去注意这个问题，后果不堪设想（dddd🙈）。这让我想起之前看过的一个很恰当的比喻，这样的代码就变成你和上帝的秘密，或者过一阵子，就变成了上帝的秘密了。

正文 🤔

言归正传，这一篇讲的主题是你可能不需要React，其实按照上面👆的说法很好理解，只要你的页面设计得当，用jQuery或者JavaScript来写也可以是清晰可读的，这样的话又何尝不可呢？除了上面说的应该关注的问题可以作为一个判断标准之外，第二个用来判断你是否需要React的标准就是开发的效率。下面通过一个简单的小demo进一步谈谈这个标准。

🌰 实现一个计数器，计数从0开始，取值区间为[0, 10]

实现1: JavaScript (CodeSandbox🚪)

基本思路就是：获取对应的dom元素，通过js直接操作dom，修改对应的文案和状态。

关键代码如下:

对于这种实现方式，如果需求不再发生更改，其实也还能接受，代码也还算清晰，但是如果你仔细一点就会发现，这里知识js代码，还有html呢，我们要操作真实dom的前提是它必须存在，说白了就是必须是命令式的，如果此时需求变更，你可爱的同事在修改代码时，把你html中的元素id换了一下，你原有的功能可能就出bug了。不难看出，这样的编码方式，经过多人的手，经过时间的洗礼，大概率都变得“摇摇欲坠”，自然而然地，开发的效率越来越低，后面维护的同事指定是一片哀嚎。

这里我们提出这种需求场景下一个很大的问题，就是无法实现局部开发。 怎么理解呢？如果你的代码牵一发动全身，那么对应的编码人员就必须拥有codebase的知识，这对于开发人员来说无疑是最不想遇到的，又何谈开发效率呢！其实现在的前端框架（库）都提供了对应的解决方案，这里就不一一展开了，我们来谈谈React是如果解决的。

实现2: React (CodeSandbox🚪)

基本思路就是：通过jsx实现对应的组件，通过数据来驱动UI视图。

这里我们不用关注两种方式的代码量差别，我们主要看看React这种基于jsx的写法有什么好处，为什么就解决了无法实现局部开发的问题。从文件结构不难看出，解决无法局部开发的杀手锏其实就是组件。 React偏向于all in js的道路，这样的设计就决定了他要为使用js写UI提供更高效的出路，毫不夸张的说，jsx是React能够崛起并且或这么多年的基石。这里对于jsx和React的关系也不详细展开了，后面系列会单独介绍。

回归正题，因为有了jsx，让开发者几乎不需要花任何代价，就能既享受贴合近乎原生html的体验，又能充分享受js这一动态语言带来的福利，一句话概括，用jsx开发UI简直比德芙还丝滑。再配合组件式的开发思维，可以轻松地实现局部开发。

写在最后 🥳

通过一个简单常见的demo，对比了两种方式的实现，不难发现，当你使用原生开发无法持续高效地开发UI界面时，React或许可以派上用场～

这也正好和React一直宣称的一致，自己只是一个用于构建用户界面的 JavaScript 库，而且如果你足够的细心，会发现React一直以来都致力解决上面我说的关键标准————不断为开发者提供持续高效地开发UI界面的能力。

彩蛋 🥚

今天的彩蛋就提出一个问题，欢迎 👏 大家评论区积极讨论，问题如下：

Virtual Dom是为了更好的性能吗，它的优势是什么？

温馨提示✨：

• Vdom更像是一种模式，是UI内存化的一种体现
• 在React中，通常使用React Element来代替Vdom这一说法，后来基于Fiber的架构中的Fiber单元，也可以认为是Vdom这一模式的实现方式之一
• 性能不是目的，是基于声明式、开发效率、跨平台等能力的一种妥协

参考答案在下一篇文章彩蛋区公布哦🙈～