2015前端组件化框架之路 about blog

[xufei]

这篇从一个月之前就开始动手，陆续写了这么久，花掉了这一阵很多的业余时间，其中整合了过去写的几段东西，到今天中午，还是不能完全满意，想想还是发出来算了，有认识不到的地方，希望大家指正吧。

[lifesinger]

感谢徐飞的分享，我们内部有一些讨论（文中提到的侯振宇、以及 KISSY 的作者现在对 React 极度狂热的 承玉 都和我在同一个团队、还有几位狂热的同学）。我的想法：

React 和 Angular，以我目前只看过官方文档和写过几个 demo 的感觉，以及结合当前蚂蚁金服的现状，我的想法有两点：

1、通用组件层面，我们一定要能通过某种方式复用起来，而不是跨一个体系（比如 YUI、KISSY、Arale 等），组件就复用不起来。通用组件，简单来分，可以分为 UI 组件和工具组件。对于工具组件，遵循 CommonJS 模块规范，已经能做到跨体系共享，甚至跨端复用（浏览器、Node 等）。我们痛点在通用 UI 组件层面，比如一个日历、一个对话框等，这些可抽象的通用组件，是否可沉淀下来可持续发展？做到和上层应用架构无关？这一点上，我非常顶 React 的思路，通过 component 可以把一个组件很好的封装起来。而 Angular 的 directives 明显还是封闭体系，脱离了 Angular，就用不了。通用组件层面，比如 Angular 写一个日历非常蛋痛，我个人觉得明显不对。

2、应用架构层面，对于纯前端（还需要有一定经验）来说，React、Flux 不错，但明显不适合蚂蚁金服的现状。即便对团队里现有的前端工程师来说，全 component 式开发，推行起来估计也非常有难度。这一点我可能理解不够，但总感觉什么都往 js 里整，在业务层可能有点过激。在蚂蚁金服的现状下，在业务应用层里，HTML First 应该还是当下最合适的方式。浏览器现有标签 + 部分类似 web component 的标签，可能还是最合适的。有点像当年 XHTML 和 HTML5 之争，以及 ES4 与 ES5，最后胜出的，不是追求完美的 XHTML、ES4 等，而是理想与现实混搭的 HTML5、ES5 。应用架构层究竟怎么做，Angular2 挺不错的，但为什么我感觉 Angular2 还是野心太大？不甘心只做应用架构层？而是想把通用组件层也做掉？是解耦的成本太大？

组件化的目的，个人觉得不是复用，而是提高可维护性。通用组件通过复用提高整体可维护性，但业务组件，追求复用，不一定是降低维护成本的有效方式。并非把所有的一切整成组件，就是可维护性最好的。业务层的模糊不清、变化迅速等，也许上层（比如页面层），目前的模板、行为、样式分离，就是一种很好的最佳实践。

说多了，由于对 React、Angular 涉入不深，可能理解有误。但真心想说，我们除了研究技术本身，还得回归到团队的人员现状。除了要让前端们写代码更舒适，我们还得想办法，在应用架构层把门槛降低到，让 JAVA 开发也能快速用起来，同时能保持一定的代码可维护性。这是我们面临的赤裸裸的挑战，这个挑战必须扛过去。

[island205]

上次 @lifesinger 来 Teambition 交流对我启示很大。说一些我目前的看法：

目前没有好的框架，将来也很可能没有

我零零散散使用过很多框架，还看到过很多。每个框架都有基于这个框架做得比较好的产品。然而没有一个框架是好用的。这里说的好用包括：上手快，框架原理好理解，开发一个产品的各个部件都很成熟（数据层，UI层，路由层）。

大家可能都觉得 Backbone 简单，上手是简单，框架原理好理解，但是第三点没法满足，其实 Backbone 很难，因为开发稍微复杂的产品时 Backbone 的基础模块提供的功能就捉襟见肘了。

Angular 上手看上去很快？框架原理就不好理解了，而且真的，Angular 各个部件也不是很成熟；在某些方面很强，比如双向绑定（其实实现部分真的很难看），路由组件（ng-router，ui-router）；但 UI 层（directive）、数据层（angular-resource）等等都是渣渣，因为看上去很 Promise，但本质上很难用。

React 本质上是一个类库，横向就是 Backbone.View 或者是 Angular 的 Directive；上手很快，也比较容易理解。比起后面这两个还有一些优点：性能高；比起 Backbone.View 而言，React Component 会自己管理自己的子孙节点；比起 Angular 的 Directive ，最明显的区别就是简单。但 React 与 Angular 一样，实现太野，只是借助 virtual dom 性能高。

总结下来，单就 SPA 这个领域，需要很多基础组件（数据层、UI层、路由层），目前相关的框架和类库都提供了一方面或者几方面的功能。数据层方面 Backbone 更优秀（虽然不是完美），UI 层 React，路由层 Angular 和 React-Router 都还不错。但没有一个框架在这三方面都做到了最好。更期望更多的解决单方面的问题的类库出现，组合使用，总比一个被一个框架绑架了强。

没有永恒的框架，只有永远需要实现的需求

技术都是为业务服务，业务一直都有，但是技术就是会更新换代，目前前端技术就到了应接不暇的程度。可能一两年前心里盘算着，就这么做，这就解决问题了，一劳永逸了，但事情完全不是这样。某个技术只是在一段时间某个项目有用。随着时间推移、项目变迁、人去人来，技术必然轮转甚至被淘汰。

不用太迷信某个框架，尤其是目前这些流行的框架，到底解决了全球多少前端的需求呢，可能 1% 都不到。

选择技术或者是框架，更多的应该看看能不能提高生产力，能提高多少，随着技术的演进，现在选择了这个技术，未来迁移的成本有多大？技术、需求、产品都有时效性，到时间了自然都会被淘汰。

公司现状决定技术走向

每个公司都有现状，比如蚂蚁金服前后端比很小，但是 Teambition 前后端比很大。现状就决定了技术走向。支付宝的前端没法全部改成 React，没法完全前后端分离，因为没时间也没资源这么做。而 Teambition 前端资源比较充裕，产品线都是 SPA 应用（这个也可能是充裕的原因），前后端分离很彻底。所以技术选型更多的看公司，不是一个技术到底有多优秀（而且，没有哪一个是优秀的）。为什么 Google 那没多产品都没有用 Angular？乖乖，都用了岂不是作死的节奏。Angular 没有那么强的普适性，也不是那么优秀的框架。

bibi 太多了，有时间再来bibi

[binlaniua]

我这里封装了一套 https://github.com/binlaniua/AngularAdmin

文档来不及完善, 不过公司内已有几个系统使用，基本覆盖了场景, 还在持续维护

献丑了

[island205]

顶了，我是 @寸志。反正我现在更加迷茫了

[tiye]

我是 React 一派的, 为 React 辩解一下 😄
而且我很同意 @petehunt 认为 Web Components 存在设计缺陷的问题(某个视频, 忘了)
另外我也认同 Mozilla will not ship an implementation of HTML Imports

React 编程的思路是这样子的:

• Model

先确定有哪些数据, 其中哪些是存储在数据库的, 那些是存储在对应模块上的
存储在数据库的部分, 对应 this.props 属性, 模块上的对应 this.state 属性
上面的数据构成了 Model, 相对服务端 MVC 来说用 this.state 解决了界面操作的 Model 问题

• View

View 基本可以套用服务端模版渲染数据的思路, 根据判断间条渲染即可
界面的模块化是 View 降低复杂度的主要手段, 无论 Polymer 还是 React 这都不变
从 Model 到 View 的整体思路, 可以按下边这样的概括:

var render = function(Model) {
  return View;
}
event_loop(function(){
  var currentView = render(currentModel);
  map_view_into_user_interface(currentView);
})

每一次 Model 有更新, 完整绘制整个 View. 思路非常清晰.
同时, 也会遇到问题, 有两个很明显:

• 性能问题, 完整重绘整个 View 必然是慢的
• 单一 Model 无法实现, 极少的情况数据会全部放在一起, 还能总是保持一份
• immutable data 和性能问题

对于这种重绘的性能问题, 函数式编程里给出了惰性计算的解决方案, 也就是用内存减少重复计算
对 React 模块来说, 就是传入模块数据不变时, virtual dom 不需要重复 render 和做 diff
正文说了, 原本 js 需要递归匹配, 而 immutable data 不需要, 因此可以明显提升性能

• Single Source of Truth 和多份 Model 的问题.

React 当中子模块继承父模块数据的时候, 约定是不允许修改父模块的数据致
也是用 immutable data, 就像数据库, 要 update 就写好请求提交, 然后从数据库拿到更新之后的数据
这样, 子模块与父模块重复的数据, 实际上保持了一份, 思路继续非常清晰
而 this.state 对应的模块自身的数据, 只有自身一份, 也就不会出现状态不一致

通过这样的方案, React 实现了一套非常贴合 MVC 思路的架构
我认为这样一套方案对于图形开发来说已经是很好了

再回来说其 MVVM 之类的框架, 当然也很好解决了模块化跟 DOM 自动维护的问题
但是模块 B 从模块 A 的数据 d1 获取了一份自身拥有的 d2 时, 就不再是 Single Source of Truth
独立的数据越多, 数据处在各种状态相互之间产生交互的排列组合的数量也就越大
结果是程序员需要顾及更多状态的组合(而强制遵循 Single Source of Truth 组合结果会少一些)
而因此我也担心 MVVM 之类框架, 是否会因此导致更加复杂的解决方案不断出现

还有一个是模板引擎的问题. 我举的例子可能有点难懂.... 比如说 Go 代码编译到汇编
HTML 像是 Go, 浏览器中 Skia 绘图引擎的每个操作可以比作汇编
HTML 渲染的过程于是就像是 高级语言编译到低级语言, 然后执行 , 这样一个过程
React 做的, 是在 JavaScript runtime 当中生成 View 对应的数据形态, 经过优化, 渲染到屏幕
这是个数据变换的问题, 非要设计一套带数据绑定的模板出来... 是不是很奇怪?

[Justineo]

先顶再看

[wileam]

先顶再看

[binlaniua]

忘了说了，用了这套 http://www.keenthemes.com/preview/ 只是全部封装成了指令和服务, 覆盖开发场

景, 封装api提供给开发调用, 数据接口全部 promise

[liuweifeng]

先顶后看+1

[leeluolee]

继续努力， 希望下次regularjs可以进民工兄的博客

[luqin]

正在使用react来组件化前端

[Hwangss]

Web component 的路还得走很久，越来越感觉自己落后，懈怠

[liuyanghejerry]

其实我挺喜欢webpack + vue的组合的~

[terryvi]

得奋起直追啊

[luqin]

目前正在使用 react + reflux + webpack + gulp 实现单页同构应用

[lyuehh]

看完了，写的不错。 polymer最近会发布0.8版本，年内发布1.0， angular2今年估计也会发布，都不错，react 不是很喜欢。。

[zhu-meng-han]

顶完再看

[yijian166]

顶顶顶，赶紧加油学习～～～

[wyodyia]

写得真不错。。。。。。

[whilefor]

考虑的全，提到都是最前沿的东西

[jabez128]

好棒！

[markyun]

支持飞哥， 好多字，回去慢慢看。

[antife-yinyue]

沙发被抢，伤心

[zhuxiaojian]

工作不饱和，有空写这个

[gearchou]

目前接触前端组件的时间很少，感觉自己落后了很多 ~~~~

[weekeight]

先赞后看

[LingyuCoder]

给民工大大点赞

[sunnyzhouy]

恩 够长

[LiuJi-Jim]

前排没了，二环占个位置慢慢看。

[LearnShare]

对于这个问题，主要存在两种倾向，一种是仅仅把“控件”和比较有通用性的东西封装成组件，另外一种是整个应用都组件化。

对前一种方式来说，这里面只存在数据表格这么一个组件。
对后一种方式来说，这里面有可能存在：数据表格，雇员表单，甚至还包括雇员列表界面这么一个更大的组件。

这一前一后好像是颠倒了。

[OllivanderMe]

看完还得再翻翻

[PeterRao]

先占位再看

[kainy]

前排没了，二环占个位置慢慢看。

[dolymood]

赞！

[christieheli]

先占位再看

[barretlee]

很多地方在最近的开发过程中深有体会，团队也想出了不少解决方案。文章太长，有空再读一遍。

[fengmk2]

终于细细看完，真的很赞。

[akira-cn]

赞~~

[hustxiaoc]

占位

[jasperHuang-jser]

好文

写的好棒，基本涵盖了前段这几年的各种东西，民工出品，必属精品

[noscripter]

mark

[Sorrowhere]

最后的总结，大赞！

[Tankpt]

占位先顶再看

[FrankFang]

先顶再看是什么鬼习惯？

[riaeasy]

的确，随着浏览器功能、性能的提升，现在的web应用已经基本可以实现桌面应用的效果和交互体验。
这也是我们开发RIAEasy的初衷。
目前，我们的RIAEasy已经实现完全的模块化、组件化、可视化，已经基本可以用于webMIS的二次开发。
演示地址：http://www.riaeasy.com:8081

[zensh]

棒极了，目前组件化的思路都把界面模板和交互逻辑捆绑在一起实现，有没有想过像 JS、CSS模块化一样，专门实现基础 HTML 的模块化呢？然后再在这个基础上实现组件化。
https://github.com/teambition/mejs 在做这个尝试~

[island205]

@riaeasy 这是什么鬼？

[zensh]

感觉 @riaeasy 还在实现上个世纪的东西：太丑了；如今强调极致的视觉和交互，riaeasy 无法适应啊

[xufei]

@zensh HTML模块化的，然后也需要继续做依赖（也就是包含）关系的管理吗？我前年那两篇里想过这方面的事，但后来想想，如果不追求界面的复用性，好像也就无所谓了……

[xufei]

@jiyinyiyong 数据排列组合的问题，你有道理，我再想想。

模板的问题，在mvvm框架里，模板是视为数据的配置文件的，因为在前端领域，界面必定是改个不停，改一种在HTML上一些属性之类的语法，应该是要比修改程序逻辑这种方式的可维护性与可靠性更高。

[leeluolee]

@zensh @xufei 从实际经验来看
依赖关系最好维护在一个模块系统里， 无论是什么前端资源。 所以能全部静态化当然是最好的选择， 现在browserify或AMD甚至system.js 都有很好的方案来解决这个问题。 如果无法静态化（比如需要服务端填充的模板文件）， 退而求其次也只能使用类似fis的整体构建工具提供的模块方案。

不知道你的模块化是不是和css预处理一样的针对html的单独模块化 这个意思 ？ css资源无法有效灵活的参与模块化的原因是它的层叠样式， 它对顺序敏感， 且全局性容易被覆盖。

[tiye]

@xufei 我理解是这样, 两种框架的"模版"部分, 相对于 HTML 的写法,

MVVM 代码会多出来

• ng-if, ng-bind 等等属性
• 值是字符串或者表达式

React 的 JSX 的话,

• 会多一些 props 传进去,
• 事件绑定的方法
• js 写的一些逻辑
• 值是 js 当中的数据

对比来说, 内容差不多... 只是 JSX 写起来肯定不如 Angular 更符合 HTML 风格罢了
我个人会觉得 Angular 表达式当中的代码不是普通的 js 会烦恼一些

React 是不推荐在 render() 方法当中写 setState 或者发送 Action 操作的,
实际上 render() 方法所做的仅仅是渲染界面而已, 控制得还是比较清晰的
我可以确定 update 操作都通过 this.onWhateverClick 写在 render() 以外, 不因为改界面而修改了
https://facebook.github.io/react/docs/interactivity-and-dynamic-uis.html

<p onClick={this.handleClick}>
  You {text} this. Click to toggle.
</p>

倒是 Angular 我记得有下边这样的写法, 我有点担心, 这个模版会修改组件数据状态啊:
https://docs.angularjs.org/api/ng/directive/ngClick

<button ng-click="count = count + 1" ng-init="count=0">
  Increment
</button>

[lichunqiang]

touch the future

[masai1969]

顶一个

[jguang]

！

[strwind]

占位 先

[2youyou2]

好长！

[xufei]

@jiyinyiyong 修改组件的数据状态，这个应该不是这么理解啊，如果你不把组件理解成从界面到数据的一个整体，就不会有这样的担忧了。在这种情形里，界面模板作为配置文件，用于初始化绑定关系，然后，你就可以当它不存在，认为最终渲染出来的是另外一个东西。如果它最终生成的html不是在模板基础上，而是替换了原有的那片，是不是更好理解些？而且，数据模型与视图模型之间，这里是需要手动维护一下关系的，界面上的所有东西，其实只反馈到视图模型，然后从这里再往模型同步，理论上是不存在视图操作直接就把数据模型层修改掉的？

[basecss]

终于看完了，真的很不错。

[tiye]

@xufei 感觉我的理解大致上是一样的... 顶多算具体实现就算不一样..
"修改组件的数据状态"那句我不明白指的是哪个问题?

[xufei]

@lifesinger 蚂蚁金服这里面提到的几个人的状况，我一直在关注。

跨体系的组件复用，这个事情没有想的这么难，如果有这个打算的话，那就是不管基于原生或者什么东西，先实现组件的功能，让它们没有依赖，然后用每个组件化框架给它加壳。

在angular这样的体系里实现组件，其实特别容易，因为很多组件干的事情都是很低级的dom操作的封装，而且，一旦封装，基本只能按照默认的状况去使用了。关于这方面，我在这篇里提过：xufei/ng-control#2

我理解你说的Java开发人员的事情，实际上，我面对的情况可能比你还恶劣，我这一阵参与的项目，全部都是完全没有前端的，比如你看到我前几天说青云那个女工程师的事情，她用backbone实现青云控制台，为什么我知道这么清楚，因为我带着两个Java的人干了同样的事情，只是我们用angular，他们也实现了这么多功能，但其实并不了解angular的原理，因为基于angular，把分层之类的东西做好，路由之类的规划好，告诉他：

http请求相当于你连接数据库
service相当于dao
controller相当于bl
html模板相当于freemarker或者velocity

他立刻就以非常熟悉的方式去干活了。

我觉得要解决让Java人员深度并且轻松参与此类项目，关键还是分工，最好不要让他几层都写，用其他不基于模板形式的组件化技术，他不可避免都要有熟悉dom的过程，这就大大提高门槛了。而如果告诉他，把html模板当配置文件写，他心里会舒服很多。

ng2我现在不太看好，原因是aurelia，我认为在同一个方向上，后者的实现比ng2更好，aurelia比现在的ng2更有资格叫ng2。

[xufei]

@jiyinyiyong 就是你上面最后那个例子

[xufei]

@island205 上面这段说得很好啊

[tiye]

@xufei 哦, 我举那个例子是想对比这一句:

在前端领域，界面必定是改个不停，改一种在HTML上一些属性之类的语法，应该是要比修改程序逻辑这种方式的可维护性与可靠性更高。

不过如果你指的如果是修改 HTML 属性跟修改 JavaScript 代码的差别的话, 我理解偏差了.
我以为单纯对比两种写法哪一种控制得更好一些.. 这样操作状态代码直接写进模版了我更担心.

[tiye]

@island205 我是来吐槽的. 😆
Backbone 的 Model 层也不省心, React 用 JSON 结构加上个粗粒度的事件管理效果还更好一些.
简聊能切换 React 因为当时功能还不是很多, 而且原来 Backbone 写的结构预期也不够好.

[island205]

@jiyinyiyong 别这样，React 是没有数据层的。那是你基于别的类库实现的。我已经说了 Backbone 数据层，比起其他框架要优秀，但也好不到哪里去。

[tiye]

@island205 了解. 我是照着 Facebook 给的例子抄的.

[jinwyp]

寸志上面那篇总结的很不错, 但目前我还是觉得最好的方案是angular(star最多,仅次于jQuery).
实际上react(我没有深入研究使用) 还是无法和angular相比, 功能和结构都满足不了开发需求,尤其是开发效率.

backbone我做过一个复杂的电商的购物车, 例如京东那样, 有满减,单品促销,换购, 赠品的. react的view除了高性能虚拟dom,对比backbone并没有太多功能. 仍然就是backone view的加强版, react的概念的组件化很容易忽悠人(入门快,和backbone一样, 做大了很容易就混乱了.) react的组件化目前仍然无法,angular的directive相比. angular的directive 功能的确多,但都是为了解决实际问题设计出来的, 例如 楼主提到的第4点和7.4点, 组件之间的嵌套和相互调用,数据传输, 目前react只能在js中手写代码处理.(这里不包括flux架构) 例如 angular官方文档的例子 https://docs.angularjs.org/guide/directive 中的Creating Directives that Communicate 这节和 Creating a Directive that Wraps Other Elements 这节中, 里面设计的概念非常多, (官方没有深入详细说明,文档从1.2就没有更新过,必须差评),试想一下有10个组件要互相数据依赖计算(电商购物车场景),在react中就很难处理. 写出来的代码和jQuery并无多大区别.
所以MVVM是必须引入的(减少代码的关键), 组件要引入绝不是react这种, 一定是angular或polymer这种, 否则就不要引入. 组件目前的状态,我看既不是为了减少代码,也不是为了复用(除了基本组件日期,弹出框这种) 目前组件的作用就是更好的把业务代码结构化. 至于MVC还是Flux的最上层建筑就看项目大小. 目前我觉得只有企业级后台ERP业务可能需要Flux这种非常灵活的结构, web网站mvc肯定够了,维护起来也不麻烦.

react的价值目前看来我的觉得反而是替换后端的模板引擎意义更重大, 最近准备把后端ejs换成react配合前端的angular使用, 因为目前的后端的模板都是字符串模板, 语义化太差了.

angular的第三库的确难用, 因为结合了上面的各种风格第三方库在由于angular版本进化太快. 所以选择那些仅依赖angular的库还是不错的, 例如angular strap 而不是angular-ui/bootstrap

其实不想用angular的 用backbone + 其他mvvm 库 目前看来是最适合的, 用到不爽的地方在去用angular的directive解决.

路由层 还是后端路由靠谱, 前端路由只在某些页面庞大的时候可以用用. SPA还是算了. Google用angular少是必然的, 一家靠搜索引擎的公司肯定不可能用SPA这种对搜索引擎不友好的技术

[xufei]

@jinwyp @jiyinyiyong @island205 model层确实是backbone的相对完善些，不过这一层是比较容易自己补足的，也就是我提到的那层store。服务端渲染这个事情很难办，mvvm这个方向基本没法搞这事了

[binlaniua]

react的数据透传是麻烦事，flux增加了开发的代码复杂，用react写出来的代码量不是一般的多，还是很期待2.0的正式发布

[luqin]

大家有没有react开发的大型SPA应用？最关键的部分是前端分层分工明确，模块可集成开发。目前在这方面有什么好的办法？

[AKIo0O]

讨论来讨论去，还是angular好用。

[Galen-Yip]

好文！这是最好的时代，也是最坏的时代。每天都感觉有很多的新东西。感觉就像以前玩帝国时代，从刀耕火种到帝国文明，前端目前的状态是春秋战国时的百家争鸣，但注定，淘汰与合并，虽不会大一统，但分足鼎立，一些独特的党派可能也独树一帜，受的影响不大。但潮流就是这样，虽然我们不知道将来会发展成怎么样，但路就再脚下。

[tiye]

@luqin 我觉得我们写的算是不小了 https://talk.ai/v1/via/64fd15001r

@xufei 嗯, 就 React 目前没有 Model 层来说确实比不上 Backbone.
只是我感觉实际使用中自己简单做的数据层没有 Backbone 那么多限制, 反而功能更完善了.

@binlaniua 不至于更多吧, 难道是把模版的代码特别算进去了?

@jinwyp 我对 React 模块化机制的看法正好相反,
因为 Virtual DOM 的存在, 模块化反而是非常合理的, 把数据拼接在一起就完成了
这在 Backbone 当中是无法比拟的.
而 MVVM 当中模块的数据绑定也不简单啊, 虽然对于 Angular 这一点我不是很确定.

[binlaniua]

@jiyinyiyong 模板有逻辑在里面, 怎么能不算进去呢 ^_^, 而且react最主要不就是视图么

[tiye]

@binlaniua 还是算总的代码量吧, 要不 React 真是吃亏啊.. 这个事情我是这么算的,
Backbone 需要第一遍渲染 DOM, 要写写一遍模版的代码, 第二遍更新 DOM, 要写 jQuery,
而 React 只要写一遍, 然后就可以了...
这样一算代码量就少了.
当然跟 MVVM 比起来没优势, 因为 MVVM 把表达式代码直接写进 HTML 属性去了.

React 的话虽然是个 View 模块, 实际上对 Model 也是做限制的, 就是约定数据是不可修改的.

[tiye]

@LeezQ 楼上可以发个招聘帖~ http://react-china.org/

[binlaniua]

@jiyinyiyong 我不是喷react, 我也喜欢react, 而且我也写了一套reactadmin[半成品], https://github.com/binlaniua/ReactAdmin/tree/master/src ,只是react现在没找到好用的数据透传, 之前看到GraphQL, 为之一动，坐等开源，还有更劲爆的 react native

[riaeasy]

可能这里有人不理解RIAEasy是做什么，因为这里的人主要是做前端的吧。
如果说，之前的前端主要是界面、美工的话，这个没有问题，问题是，现在的浏览器、虚拟机这么强，web前端已经不只是界面、美工了，完全可以实现以前只能在桌面做的工作了。
其实，这也是本篇博文中提到的web的前景。
看了博主其他文章之后，知道博主是完全理解软件应用工程化的意义所在。一个软件要工程化，除了界面、美工、人机接口之外，还涉及可扩展性、可维护性、可靠性、及时响应业务需求变化等方面。
RIAEasy正是希望实现一种可控的、可扩展的、可视化的、易于维护的、快速的开发，能够将原来桌面应用换成web应用。
RIAEasy的前端核心是模块化(module)、控件化(widget)、可视化(visualEditor)、数据敏感(store)、动态加载(require)，实现web单页面应用；后端核心是js化，把以前用java、C#实现的服务器端换做js实现。RIAEasy是一个前后端统一的工具，能够实现工程化。
在RIAEasy里面，设计就是运行，你所看见的就是运行时的状态，而不只是所见即所得。
只是，现在的前端的确框架众多，新概念、新技术层出不穷，让人难于取舍。不过随着桌面应用大面积的转向web，估计2、3年内，web应用会逐渐地统一标准了。

[riaeasy]

RIAEasy毕竟是从桌面转过来，一出生就带着桌面应用的基因，显得与时尚的移动应用有些不同。
但是，毕竟都是web应用，下一步，RIAEasy就将实现移动应用的包装。估计在5月份吧。
RIAEasy的真正魅力尽在 里面

[tiye]

@binlaniua 赞, 写了好多.
稍微对比了下, 你的代码当中 setState 比较少看到, 而 jQuery 操作跟组件有不少,
我的代码里在有意排斥 jQuery 的写法的. 可惜我放在 GitHub 上的都太简单了.

数据传输的问题同意, 只不过还在我接受范围内, 我也在期待 GraphQL 放出.

[deonwu]

前端、后端一直很迷茫。

[knightuniverse]

对

• module
• Web Components

比较感兴趣，如果结合nodejs应该会很有趣吧。

[knightuniverse]

@deonwu 这个有什么地方迷茫的？

[jinwyp]

想问一下ls里面对 react熟悉几位 关于 angular官方文档的例子 https://docs.angularjs.org/guide/directive 中的Creating Directives that Communicate 这节和 Creating a Directive that Wraps Other Elements 这节中, React 怎么处理?

[tiye]

@jinwyp CoffeeScript 伪代码:

"Creating Directives that Communicate" 的 Demo,

• 点击 tab 切换内容
• 模块内部有 counter

# 不用 JSX 的话手动生成 DOM 构造函数
div = React.createFactory 'div'
span = React.createFactory 'span'

# 创建模块
docsTabsExample = React.createClass
  displayName: 'docsTabsExample'

  # 设置一个状态, 表示当前选中的 tab 位置
  getInitialState: ->
    selectedPosition: 0
    count: 0

  # 修改位置, 选中另一个 tab
  onTabClick: (index) ->
    @setState selectedPosition: index

  # count += 1
  onCountClick: ->
    @setState count: (@state.count + 1)

  # 较难看, 抽出来单独写
  renderTabs: ->
    div className: 'myTabs',
      [0,1].map (index) =>
        # 生成 className
        className = if index is @state.selectedPosition then 'active'
        onClick = => @onTabClick index
        # 绑定点击事件用于切换 tab, tab 的显示从简
        span {onClick: onClick, key: index, className}, "myTab #{index}"

  renderPane: ->
    div className: 'myPane',
      # Pane 的内容从简, 复杂的 DOM 写起来不如 MVVM 好看
      switch @state.selectedPosition
        when 0
          div null, 'myPane 0'
        when 1
          div null,
            'myPane 1'
            div className: 'counter', onClick: @onCountClick,
              "this as beed clicked for #{@state.count} times"

  render: ->
    div null,
      @renderTabs()
      @renderPane()

# 挂载到页面
React.render(docsTabsExample(), document.body)

其中选中状态通过 selectedPosition 表示, 渲染时读取细节
如果拆分模块, 就需要重复写参数传递 selectedPosition, onTabClick.

"Creating a Directive that Wraps Other Elements" 的 Demo,
因为 React 模块的 props 当中能直接传递 virtual dom 的数据, 默认就是支持的

[fdumpling]

必须点赞

[JimhooLiu]

看完了文章，也看完了评论，基本都是站在架构师的层面在讨论问题，似懂非懂。路漫漫其修远兮，吾将上下而求索。

[LittleBearBond]

先顶再看

[vagusX]

看完再看

[stoneChen]

占坑，太长了，慢慢消化

[ZKHelloworld]

看完了，顶一个

[mengzhiang]

仔细看，慢慢品位

[magicdawn]

先顶再看。。。搜了下，没有正在用的 Ractive.js

[magicdawn]

前端圈最热衷于造轮子了，没有哪个别的领域能出现这么混乱而欣欣向荣的景象。这一方面说明前端领域的创造力很旺盛，另一方面却说明了基础设施是不完善的。

node也是，前一阵找eventemitter用，什么eventemitter2、3 都跑出来了
https://github.com/search?l=JavaScript&q=eventemitter&type=Repositories&utf8=%E2%9C%93

[zquancai]

看完了，学到好多东西～正在用seajs+backbone+jq做SPA应用的毕业生路过，这SPA就是我的毕设，看了这篇文章，感觉我写的都好像有点落伍了。。。

[sdyxch]

所以我去写ios了。。等Object.observe MutationObserver主流之后 看心情回不回来

[tiye]

@zquancai 现在的前沿是 Isomorphic JavaScript, 前后端重用代码~
http://josdejong.com/blog/2015/03/28/a-broader-view-on-isomorphic-javascript/
http://nicolashery.com/exploring-isomorphic-javascript/