看到一篇文章《为什么 ReactJS 不适合复杂的前端项目》

#1

http://insights.thoughtworkers.org/more-than-react-1/

感觉里面的槽点还挺多的，想听听大家有何看法 :smiley:

1 Like
#2

菜鸟强势围观。
onclick的问题我也碰到过，怪自己太年轻。

1 Like
#3

只能同意一部分,

于是我把ReactJS用Scala重新写了一个。代码量从近三万行降到了一千多行。

都换了一门语言了, 让我怎么说. JavaScript 虽然表达能力确实不如 Scala.js . 但是作者写的 js 代码很多写 js 时间长的人看还是会喷的吧. tab 缩进, 夸张的换行, 还避开了 ES6 语法, 还全局包装一个函数调用.

问题一：ReactJS组件难以在复杂交互页面中复用

作者的意思是依赖少的组件可以复用, 依赖多的, 特别是依赖消息的组件不好复用. 但这个事情要看情况, React 的模块封装其实是很清晰的, 不足在于代码会稍微多几行, 同时对组件之间横向传递消息做了限制. 确实有麻烦的地方, 单不是普遍麻烦导致复杂页面不适合用.

问题二：ReactJS的虚拟DOM 算法又慢又不准

如果不做任何优化, React 确实是慢的. 正确的说法是 React 的性能优化很繁琐, 而不是本身慢.

至于说"不准", list 的问题明明是需要 key 的… 常识.

问题三：ReactJS的HTML模板功能既不完备、也不健壮

这个我也说 ClojureScript 写 React 漂亮多了, JSX 确实有问题. Scala.js 具体看什么语法.

问题四：ReactJS与服务器通信时需要复杂的异步编程

这是 JavaScript 的问题.

总体觉得作者使用 React 不够深入, 某些想法先入为主了, JavaScript 坑很多, 但别把这些都当做是 React 的问题.

#4

这个应该是Binding.scala作者吧，说自己的好于reactjs

#5

看了，就是在说他自己的框架好。x

#7

其实确实更好, 但是主要是 Scala.js 比 JavaScript 牛逼, 跟 React 没有啥关系.

#8

看了一下，只能呵呵了。

借用一篇文章《选择 React 是商业问题而不是技术问题》

#9

赞同，选择react是一种长期的技术红利，当然这也包含在商业范围内，
再扩大点来说，选择的是一个方向，而非具体的某一个框架

#10

谢谢你的反馈。但是我根本没贴 JavaScript 代码呢。为什么要喷我？

第二篇到第五篇的确会有许多代码作为比较，包括ReactJS的也包括Binding.scala的。麻烦您到时候多给我一些反馈。

#11

你的链接里是 JavaScript 代码, 如果不是你写的… 但那个代码跟 Facebook 平时写的 React 代码差距是不小.

我是 ClojureScript 阵营的, js 同样看不上, 拿 ClojureScript 跟你比啰.

#12

期待后续 :grin: 这个圈子很需要这样的声音。

#13

对啊，我觉得我写的框架还蛮好的。我觉得你可以学习一下。

#14

ReactJS版的TodoMVC是这个家伙写的：https://github.com/passy

#15

不管怎么说, 这个代码还是很多奇怪的问题.

#16

即使指定了propTypes，ReactJS也不能在编译前提前发现错误。只有测试覆盖率很高的项目时才能在每个组件使用其他组件时进行校验。 即使测试覆盖率很高，propTypes仍旧不能检测出拼错的属性名，如果你把onClick写成了onclick， ReactJS就不会报错，往往导致开发者额外花费大量时间排查一个很简单的bug。

这用TypeScript就行了吧？

有些缺点看起来用RxJS就可以解决，比如精确的数据绑定。
不过Netflix为了复用Redux的开发工具还给RxJS写了个Redux的中间件。Redux还是很厉害的。

期待下一篇。

#17

有机会深入研究下