- react能满足未来的发展需求吗，大家是从哪些需求方面考虑的选择react的？可维护性？性能？靠山？还是其他方面？
- 如果编程技术再次发生巨变后(类似react的出现带来的巨变)，项目中存在的多套框架/编程模式如何处理呢？我很想统计大家现在的还维护多少框架“陈旧”的项目，是什么样子的框架，打算如何处理。
- react继续的发展relay + graphql还会耦合到后端，如果被新的技术取代了，代价是否太大？
ps: 其实我想说做前端真…（省略1w字）
React会是最终的归途吗？大家怎么看？
fe
#1
2 Likes
jiyinyiyong
#2
我选择 React 最重要的因素就是他的两个靠山, 一个是 Facebook, 一个是函数式编程.
首先是 Facebook, 他既然敢在生产环境用, 我就不怕他随随便便砍掉这个项目.
而且为了他们自己产品开发方便, 性能高效, 就不断会做改进,
这是我们希望看到的, React.js 越来越强大, 越来越稳定.
然后是函数式编程, 这个不是工程师们灵机一动搞出来的, 都以经半个世纪了,
从上世纪 50 年代的 Lisp, 到 80 年代的 Haskell(Miranda, ML),
纯函数编程当中 Immutable, Pure Function 概念都已经弄得比较透彻,
我相信这也是 React 未来性能和开发效率能不断提升的基础.
Angular, Polymer, 当然也是很棒的想法, 可是其中让我不理解的太多, 我说不准了
比如 Polymer 如果是做 Web Components 的 Polyfill, 那么就不是一个彻底的解决方案,
而是需要基于已有的 HTML 的缺陷, 提出很棒的办法来改进,
但是, 就像 ES6 一样, 旧的 HTML 或者 JavaScript 的功能还是要坚持的,
也就是说不能解决全部问题…
未来 React 很可能被其他的框架超过, 因为 React 作为第一个框架, 必定有大量的历史包袱.
我期待的是 Facebook 能基于已有的语法和代码, 提供更强大的底层实现来进行改进,
考虑到我们自己的开发实力比不上 Facebook, 我对于 React 的未来还是挺乐观的.
fe
#5
话说的没错。但是层出不穷的前端技术会让整个公司的历史代码千奇百怪，由其的是现在的框架都比较复杂，还不是jquery时代的人人都能维护。比如如果现行的技术栈都依托在react上，历史项目的技术框架是angular，开发人员换一批后，估计angular的开发人员都走光了，维护历史项目就成问题了，这是比较大的维护成本。
想想未来可能的新技术就头痛。不反感新技术，只是对前端日新月异的发展有点反感了。而且整个前端社区还挺乐意逐新。
pinyin
#8
前端技术之前发展太慢，所以出现jQuery走天下的情况，其实是不正常的
后端刚开始的时候大家也是写perl和意大利面代码，后来就知道应该用MVC和ORM啊分层啊之类
前端领域现在就像刚出现框架概念时的后端
而且现在Facebook的flux反过来走在后端主流架构MVC的前面了
真是哪里有压迫哪里就有反抗啊
fe
#9
我不觉得这是倒退。组件化的开发方式体验非常棒。
“布局、样式、行为”分离适用于web站点。对于越来越复杂的web应用，需要组件化的开发方法，分不分离不觉得很重要，只要不妨碍后期维护，怎么做都是对的。
1 Like
jiyinyiyong
#13
Functional Programming 标志性的语言 Haskell, 有几个重要特性:
- Pure Function
纯函数只要输入的参数一样, 返回的结果一样, 这样就能带来好处,
- 如果函数参数一样, 就可以用内存优化, 避免重复计算, 提高性能
- 这样的代码严格控制了副作用, 比如读写文件, 能提高可靠性
- Lazy Evaluation
举个例子, 函数参数是个表达式, 但表达式不会立即求值… 可能比较难懂, js 没有这个性能.
这个不要紧, 按前面一个特性理解就好了.
- Immutable
数据不可变, 在 React 当中就是 Diff 对象的时候超快.
正常 JSON 对象做 Diff, 整棵树遍历, 在函数式语言对比引用就能判断出来了.
数据不可变也能提高代码的稳健性, 因为数据不会随随便便被修改.
但是! Haskell 虽然设计得很好, 但是非常学术化, 简直就是一边研究数学一边写程序
所以 Haskell 本身没有大规模铺开, 只是其中几个特性被人抄来抄去.
推荐两份文章, 一份中文一份英文:
https://www.byvoid.com/blog/why-functional-programming
https://wiki.haskell.org/Introduction
那个…我还补一句吧, 这两篇文章我也不能全看懂. FP 实际上水挺深的.
jiyinyiyong
#14
人家写的软文呢, 我已经在文章下边回复避免误导了
http://www.csdn.net/article/2015-04-30/2824597-samurai-native
stars
#15
jQuery 时代？为什么一个只专注 DOM 操作的js库，在前端成为时代？那只是它用在 DOM 操作方面好，但是jQuery 处理大数据的情况下性能好吗？喜欢 jQuery 的人看来只专注展示类页面的开发，这类开发只专注页面布局，页面样式，以及用 jQuery 处理一点简答的页面逻辑，其次再找点 jQuery 插件做一些图片 Slider, 时间控件，你认为一个只专注操作dom操作的类库就能称霸前端时代？如果这样，为什么社会要出来前端框架，MVC，MVP，MVVM。。。出了纯展示类页面需要加载性能要，所以页面 js 追求精简，展示类页面数据量不大，比不上非展示类的页面，非展示类的页面里面页面逻辑负责，场景设计复杂，数据量大，我以前面试过一个只会 jQuery 前端开发，我问如果那 jQuery 写一个分页面，实现思路是什么？他只是勉强的给我说：“我以前只做展示类页面，页面里面没有这样操作，只要展示数据在页面就可以了。”大多数做展示类的前端开发，只用 jQuery 反而失去了对原生js的研究，只会做简单且封装好的js操作，如 jQuery！看清世界，为什么用 React，在展示类页面不好用，因为本身文件自身很大，而在非展示类的页面，如果一些系统管理，如果用户的后台管理系统，等这类用 React 去做扩展很好。它对 DOM 操作性能也是大家都知道。一句话：大牛出来非展示类发展出来的，你看看哪个认为 jQuery 的人能成为前端大牛？
fe
#18
能否分享下你们碰到的坑？难做体现在哪里？只给出这样的结论会把新人吓跑的。
组件化，就是两个步骤
- 提取公共通用组件，例如表单元素、日期控件，为了解耦action，可以使用props提供回调等
- 提取业务组件，这个照着React官方例子，划分页面得出各个组件。