我们为什么需要 React?

7月13号更新, 其实我想问的不是angular跟react哪个好,哪个不好. 我想问的是,react的代码相对繁琐,那么在繁琐为代价的前提下为我们解决了哪些痛点?最近在学习react, react概念虽然简单,本身使用这个库也不复杂. 但是学到后面一点冒出了三个东西: Flux,Reflux,Redux; 加上这三个东西,我就觉得react一点都不简单. 因为react学的还不够深入,所以还没有意识到很多问题. 但是既然出现了Flux,Reflux,Redux,存在肯定有存在的理由, 那就证…
关注者
1410
被浏览
120682

40 个回答

我们需要技术栈提供好用的模块化方式,可以是Web Component,可以是非Web Component的某种机制,不管什么库或者框架,我们需要技术赋予我们完成一个抽象,一次构建,多处复用的能力,并且这个过程不能太麻烦,不能做个很日常的抽象翻半天文档。

我们需要数据绑定,在各种粒度上真正实现事件驱动,因为这样我们就不用自己重复手写本质上并不依赖场景的从视图到数据从数据到视图的自动更新,否则我们就得自己操作DOM,优化DOM操作,还要自己维护状态,一自己维护状态,就要陷入状态同步的漩涡,浪费大量时间和精力。

我们需要技术栈隐藏掉平台的微妙差异,写一段代码可以真正实现跨平台,而不用我们自己纠结于那些本不该应用开发纠结的事,我们需要持续稳定的跨平台支持,最好的移植就是不用移植,这在商业上有很大的价值。

我们需要库或者框架好学,好用,从第一天起就能快速开发,而不是不得不经历几个月的学习曲线那种,因为大多数团队的程序员水平都存在梯度,我们不希望因为一个技术栈把初学水平的人挡在门外很久,理想的状态是技术本身能对招聘工作完全透明,同样的工期,同样的项目,随时找人都可以,招人的时候不用写得过于具体,只要会JavaScript就能快速上手,我们需要概念负担尽量少的技术栈,真正理解了Simplicity的技术。

我们希望技术栈有非常好的性能,性能的水平和垂直扩展性都很好,这样我们就不用项目写到一半回头去纠结应用开发团队很难解决的性能问题,我们需要在快速开发和基础性能之间平衡得很好的工具,而不是因为要强调某一方面而对另一方面关注太少的那些工具。

我们需要使用的工具有专业的团队或者社区持续地跟进,最好这些团队和社区自己就把自己的东西投入生产使用的技术,这样至少对我们来说风险就有起码的控制。我们不需要那些心血来潮,永远不成熟因为永远没有专门投入的技术。

我们需要那些普通人喜欢用,也用得好的技术。

React满足上面的一些方面,不满足另一些方面,和其他工具一样。你需要React,是因为两点

第一,你充分评估了你的项目,理解你要解决的问题是什么,是快速开发,性能,团队的ergonomics,多数情况下要解决的问题是多个要素的平衡
第二,你充分评估了React这个栈,理解它是解决你的具体问题的最佳工具,你真的理解了自己的场景中非用React不可的那些事情


如果你觉得React快所以需要,事实是React并没有那么快,尤其是大型应用,小型应用里快是不重要的,所有的框架都足够快。
如果你觉得React开发快所以需要,事实是React并一定是最好用的,尤其是当你考虑了团队的构成。
如果你觉得React是Facebook开发的所以需要,我的揣测是经历过一个社区adoption的高峰以后,Facebook未必能解决剩下的那1%的问题。
如果你觉得React Native很火所以需要,这或许是一个理由,但RN也不是唯一选择,从各方面评估,NativeScript这样的栈并不比RN坏多少,也许还稍微好一点。如果是大预算的商业开发,RN甚至不应该成为首选。

首先题主要区分两个概念:React 本身和 React 生态圈所推崇的主流应用架构。

React 本身其实还算简单的。最简单的理解,一个组件的渲染函数就是一个基于 state 和 props 的纯函数,state 是自己的,props 是外面来的,任何东西变了就重新渲染一遍,是不是很简单?

但是,如果抛开 React 生态圈现在所有的那些东西,只用 React 本身来做个大型应用,你 hold 得住么?我可以打包票,99% 的开发者 hold 不住。因为大型应用会带来很多规模上的复杂度,比如跨组件通信,多组件共享状态,多人协作的可维护性,大量嵌套组件的性能问题... 等等。这些东西如何处理,都是靠前人填坑才一步步产生了今天的各种设计模式。Flux/Redux 的繁琐,本质上是针对大型应用的复杂度所作出的权衡:用繁琐一些的 API,换长线的可维护性。在规模不够大的应用里,这些问题并不那么明显,那么这些繁琐的 API 也就显得有些过度设计了。

Dan Abramov 自己在推上多次强调过,Redux 的设计是以几个原则为优先的:要让状态的变化可追踪,可重复,可维护。为了达成这个目的,才会有 reducer, action, action creator, middleware 这些概念。本来一个 callApi(res => a.b = res) 可以做到的事情,现在你需要先写全套然后配上 thunk middleware 才能做到。因此在规模不够的应用里使用 Redux 肯定会觉得杀鸡用牛刀。然而 React 生态圈里面之前并没有适合中小规模应用的状态解决方案,因为 Flux 从一开始就是冲着 Facebook scale 去设计的,并没有考虑中小规模的应用。最近 MobX 也算是在 React 生态圈里搞出点小动静,就是因为它填补了这个空白,然而用 React + MobX 本质上就是一个更繁琐的 Vue。

如果做个比较的话,Vue 本身不加任何库就可以很好地满足中小规模应用的需求,配合 Vuex 可以满足大规模应用的需求。同时由于 Vue 的依赖追踪机制,不管 1.0 还是 2.0 都不存在过渡重渲染的性能问题,shouldComponentUpdate / reselect / ImmutableJS 之类的统统不需要。

其实本来没想提到 Vue 的,只是因为有些人的答案里面非要拿 Vue 来比较。

回到题主最早的问题,我们需要 React/Redux 么?从可维护性的角度考虑,大型应用确实需要,但这不代表任何规模的应用都得用它,更不代表它就是最好的。如果一个方案能够用更简洁的方式满足你的项目对应规模的可维护性需求,并且让你用得爽,那就相信你自己的心,不要因为一些宣传文案看上去很高大上就盲从。

很多 React 传教士喜欢标榜 React is not easy, but it is simple... 我想说,Life is short, easy is underrated.

总结一下:别人说用得爽,不代表你会用得爽;自己用得爽的才是真的爽。适合自己(或者手头项目)的才是最好的。