@ch3rub1m 对 ng2 不熟，不好对比。仅从个人角度来看，ng2 除了 Rx 和 TS 的部分以外，剩下的对我没有什么吸引力。而这两者虽然不是 ember 内置的，但也可以很方便的通过 addon 得到支持，所以没有感觉到任何 ember2 的劣势。

#11 楼 @lwd369 没错，的确是这样。

@chareice 好的，我会讲的，刚好我对这二者都比较熟。

@stephen 数据驱动，首先数据要“流动起来”，否则怎么驱动呢？你的应用场景可能数据流动的因素不是特别大，大部分时候数据都是“静止”的，主要工作都集中在响应用户“编辑”也就是操作 DOM 上，所以自然你会觉得数据驱动不合适。但是用某种框架也不总代表就为了数据驱动，这只是一种建议罢了，用框架也可能是为了别的好处，没必要因为一个点觉得不合适就全盘否定，技术选型还是要全面考量的。

另外数据驱动其实可以代表两个层面的意思，一个是高层面的驱动框架各个部分衔接起来，还有一个则是更具体的层面，比如说一个组件内部用状态变更来重绘视图——可能把这个叫做状态驱动更合适吧。

假设做一个富文本编辑器，状态的变更无非就是由用户的动作带来的，如果能把每一种用户可能的动作都映射为某种状态，那就很容易让视图响应用户交互而重绘，接着就是绑定各种事件到各种元素上来接收用户动作 -> 追加业务逻辑 -> 改变状态。

问题是，我的组件要怎么分割？理论上我可以用一个组件搞定整个编辑器，但由于所有的状态映射都被封装在一个组件里，那么：

1. 这代码是否好维护，好抽象（重用）？或许我可以利用框架提供的机制来进行部分的解耦，比如 Ember 有 Service（不太清楚 vue 2 有没有，但普通的 POJO 也是可以的）
2. 是不是任何状态的变更都需要视图重绘？
3. 各种交互有没有可能分类？让它们共同使用一个组件？（比如说编辑器的各种按钮）

类似的事情即使我不用框架了，改用传统的方式写也一定会做等价的思考，无非就是里面部分东西的叫法不一样了，分离解耦的边界决定条件可能也会不一样了，但终究会视其复杂性对整个应用程序做一个合理的组织——这一点不管用不用框架都是应该的，而框架本身的意义也在于此，即应用某一种哲学来帮助你更好的组织和管理你的应用程序。

你不妨自己列一个表，不用 vue，以及用了 vue 之后会对你写这么一个应用产生哪些影响？自己评估一下权重打打分，结果不难得出。

#5 楼 @stephen 这很难说，得分析的再具体一些（各种功能点）。坦率地说做这样一个东西没有几个靠谱的前端工程师是不行的，并且即便如此也还是需要依赖一些第三方的东西，视开发人员的技术实力和资源限制而定。那些现代的框架 可以 少用甚至不用 DOM，但并不是不让用。什么时候应该用那是需要自己来判断的。比方说我们的应用里也有大量的图表，做这个东西 d3 就是专业的，而 d3 也是以操作 DOM 为主的，这种时候 ember 或者其他框架并不会阻碍你什么，也不会提高操作 DOM 的难度。反而是如果你熟悉这些框架的话，它们还会在很多细节上帮到你，比如说丰富的生命周期，有用的助手函数／类等等。

如果一定要判断合不合适，还需要更具体的细节，比如规模，比如数据的规格和支持等等。我在正文里会描述一些适用和不适用的场合，具体的你到时也可以参考一下。

#38 楼 @ch3rub1m 242650456

#3 楼 @darkbaby123 engine 和 fastboot 都挺稳定的，Linkedin 已经在内部大范围的使用了 engine，用户也能从他们的 mobile app 上体验到（尽管用户并不知道 engine 是个啥），fastboot 要解决的问题其实是应用程序的开发者如何区分那些不可在 node 下运行或者只能部分支持的代码（源自于 DOM 的缺失），这需要大量的 sample 来逐步总结经验。有很多的 addon 已经开始做这个方面的迁移了，我自己做过一些常规的事情都没什么问题。不过做过 SSR 的我深深知道，痛点往往出现在那些不怎么常规的地方，这也正常，毕竟 SPA 的 SSR 不管在哪里都是很前卫的事情。

routable component 因为 2.9 的 glimmer 2 跳票了，所以目前未知，可用的样子我曾经给你看过，只是具体时间不清楚，我估计至少 EmberConf 2017 会给一个交代，明年春天。

#1 楼 @cxh116 过去很多用于 SEO 友好的方式都像打补丁一样是一种 compromising，事实上，SEO 不是对任何类型的网站／应用都那么重要的。比方说我们做应用程序的也都会有一些内容页面，官网／帮助／教程／范例等等，这些东西可以不需要用 Ember 做，或者说不需要做成 SPA，也就不存在 SEO 友好的问题。而应用程序本身就算 SEO 友好也无法提供 SEO 所渴望的那种信息。另外，搜索引擎也在不断进化，它们也不再像从前那样“挑食”，你可以提供给爬虫信息的方式越来越多，不见得非得靠内容静态化。比如说提供足够丰富和准确的 meta 标签也是一种方式（在 head 标签内）。

对于 SPA 来说，真正能做到“无伤 SEO”的可能只有 SSR（服务端渲染）了吧，我在之前讲过 React 的 SSR，但那些都是自己折腾出来的，没有所谓官方的整合支持（官方只提供一些工具函数）。Ember 则有提供 ember-fastboot，这是官方团队提供的集成方案，目前还在测试阶段不过已经能用了。我会放在正文里单独介绍一下的。

#36 楼 @lwd369 眼下也就是看着牛逼一些罢了，我们自己也知道里面存在的不足，最近正在全力制作一些新的功能的新的体验，明年会更好，并且我们全面使用 Ember 了，目前的感受就是很爽，问题当然会有，但是基础框架是很满意的，具体的问题要创造性的具体解决，这是任何框架都会遇到的。

#33 楼 @ch3rub1m 生不逢时？我不觉得，事实上很多现代 JS 框架的创新举动都是 Ember 开创或者首倡的，很多后起之秀都继承或学习了 Ember 对整个社区的贡献，在这个历史时期，Ember 的出现和繁荣恰到好处。准确的说并不是 Ember 生不逢时，而是它相对来讲更超前一些，它瞄准的目标是 Ambitious Web Apps，而这类的应用哪怕在目前的 web 届也都少数，能做好的更是凤毛麟角。相对而言，Ember 对于多数 web 开发者而言就显得“困难”一些罢了，因为它的开发者和社区的大多数人都是走在探索 web apps 的较前沿的，用户基数不大我倒觉得很正常。

我以前觉得 Ember 和 Rails 很像，但现在显然不是这样了。Rails 当年火起来离不开一个“快”字，在服务端渲染技术高度成熟的时代，Rails 汇集了几乎所有 web 开发的最佳实践，并且给出了最合理的应用程序架构，所以它生而逢时了。然而就应用程序形态来讲，Rails 也没有改变服务端渲染的本质，它只是把所有的菁华打包给你（主厨推荐）而已。

但 Ember（以及其他的 SPA 框架）却是要探索新的应用程序形态，为了能在 web 上开发和提供桌面级应用程序的体验，并且还能在此基础上提供 landing page 的服务端渲染，这是过去的应用程序框架没有成熟解决方案的事情。在这件事情上如果获得大票的用户基数而且评价还相当高的话，那就说明已经很成熟了，那时候我们应该能够看到很多很多非常棒的 web apps，而不是只是 content pages，今天的 React ／ Vue 等等算做到了吗？在我看来只是把热度炒高罢了，前路依然很远。

过去我也喜欢推广一下 Ember，但现在比较少了。一方面是我自己探索的更深入了，问题更多，需要研究的时间也就更多，没时间扯；另一方面则是绝大多数“应用”还是处于内容形态而不是应用形态，相应的多数开发者也就不需要 Ember，这是必然的，你没在 web 平台上做过桌面级的应用，你当然不会觉得 Ember 的好处在哪里。别的人再去推荐也没有什么用处的，因为需求的局限性就在那里摆着。

就在昨天看到一个老司机在 medium 上的文章，他大意是这是他第三次写文章评论 Ember，前两次都是喷，说他是多么多么 hate Ember，他以为如果还有第三次也一定还是喷，而且会喷的更厉害的，但自己都没想到第三次他想说的却只有：I Love Ember Totally！这种差别是因为前后几次评价是源自于使用 Ember 在不同的项目上所获得的体验，你要解决的问题不同，对工具的体验自然也就不同。

今天我们所见的一些人一直在喊着：“我不要 A 也不要 B，我就只用 X，它就是最好的，没有之一”，这不就等于拿着一个锤子，然后试图把所有的问题都当成钉子么？或许他们自打学会开发起，所面对的问题就只有钉子吧，所以你给他们去推荐电钻啊、焊机啊之类的东西也是白忙乎，他们用不着啊。

前面有人的评价就很准确，非要拿 SPA 框架去开发 Ruby China 的客户端，这就是用牛刀杀鸡，吃力不讨好的行为。当然，用做自己练习是无可厚非的，但如果做不出足够出色的体验就不要拿出来给“他们”看，因为他们会觉得你费这么大力气也不过就是 10 年前的技术能达到的水准罢了，有什么意义？

如果真想练手，去做做真正的应用程序，比如说 cform.io 这样的（原谅我打了个广告，因为我不知道还有什么更接地气的实例），只有做这样的东西你才能体会到 Ember 这样的框架究竟强大在哪里，久而久之你就会知道所谓“生不逢时”不过是一场误会罢了，那些逢时的人追捧的无非就是热度，然而解决的问题领域还是十年前的那一套，具体的技术都有一些进步，可是战场并没有变啊。

顺带说几句最近的感受，我加了一个 QQ 群，以 Ember 为主题的，群主也是一个身体力行在国内推动 Ember 的同行。在里面一个来月吧，做了一点微不足道的工作，很多人和我讨论问题或者闲聊期间，普遍都喜欢说：Ember 在国内环境好差啊，用户好少啊……

我个人其实很难理解这种想法，或许只是单纯的吐槽？然而对比一下 Slack 上的 Ember 社区，却从来没见过有人在上面喊 Ember 在 xxx 环境好差啊，用户好少啊……这算是中国特色吗？

如果我们一定要把某种情感付诸在用户基数、占有率等等数值指标上的话，那么我们难道不应该高兴才对吗？因为在各行各业，真正站在食物链顶层的都是少数派，Rails 这么牛，用户基数大得过 Java／php 吗？So what？我们能因此证明 Rails 不如它们？它们才是最优秀的，没有之一？

同样的道理怎么到了前端就完全颠倒过来了？我心中的解释就是：这个行业领域还很不成熟，大多数人看不到未来发展的方向究竟是怎么样的，也分辨不清到底什么才是重要的或者优秀的技术进展，理不清技术发展和需求领域变动趋势的关联关系，因此很容易被“煽动”，很容易被“同化”，同时也容易在用户基数处于劣势的时候产生很强烈的不安全感。

上述的阐述仅仅代表个人观点，很多词语打了引号不是为了强调，而是为了弱化这些词语本来的意思，看不懂语文的就不要来喷了。根本的意思就是这些现象并不是绝对错误的，而是现实发展阶段的必然性，就好像过度追求经济发展的速度就会产生一批性情粗劣的土豪富绅一样，并且热衷抱土豪大腿的也一定是多数人，然而这并不代表这个世界就没有清流存在了，而清流之所以清，还不就是因为少而精呗。所以不要因为身边用的人少就觉得自己吃亏了或者低人一等了，重要的是你心里明白究竟什么才是适合你的，什么才是你要追求的。

Vue 会如此受欢迎最重要的原因依我看就是：文档好。

#6 楼 @xiaoronglv 反正我已经在上海住了 7 年了，要我分享什么啊？

可惜，今晚老爷子来上海要去接他，否则就去捧捧场了，后面还有魔都的活动吗？

#2 楼 @darkbaby123 至少官方不认为它是稳定的，昨天刚看到官方的一个声明，大意就是成立了基金会为后续发展作保障，前期做了大量文档补完工作，从现在开始专注 v2

Babel 和 Ember 两家主创携手奉献啊（还有 Google FB），在主流的 JS 框架里头，估计俺大 Ember 又一次要走在前面了。

嗯，韩国出了几个 vim 届好手，这个客户端还不错，用了一段时间，还没找到最合适的 color scheme

罗技鼠标会有问题，因为官方驱动不兼容，正在修复中。其他品牌不明。

@tcstory 在上海？可以来聊聊

@ericguo 哇，感觉受宠若惊，我还被惦记着呐。

最近半年是忙了些，不过也积累了很多经验心得，等忙过这阵再憋大招好了。其实也是蛮尴尬的，老在 Ruby 社区发前端担心跑题太远，不过对这里有着特殊的感情，所以总当家一样写了点东西就首先放到这里。🙏

@JellyBool 我 Ruby 就是渣渣，哈哈，不敢来献丑的。

先不说单独执行页面脚本的好办法，就当这个方法你已经知道并且用上了吧。Turbolinks 实现的是页面无刷新的视图更新，当你从一个“页面”进入到下一个“页面”的时候，浏览器并没有重刷新。这就意味着在上个页面创建的对象（比如说定时器回调）依然存在于内存之中，你必须要先清除旧的定时器然后再执行新的，所以并非“不是个好办法”，而是必须得用这个办法。

你举的这个例子其实和“该页面单独执行脚本”这个诉求根本就没有关系，是一个 A／B 问题。

JSON API 原本是有一个 bulk extension 的，实际上 JSON API 是有一个扩展系统的设计的，而 bulk 是其中之一：https://github.com/json-api/json-api/blob/9c7a03dbc37f80f6ca81b16d444c960e96dd7a57/extensions/bulk/index.md

当然，标准对其做了规范是一方面，具体的实现有没有做那就要单说了。

然而这个扩展系统一直以来都是试验性质的，并且目前已经被 deprecated 了。照官方的说法，一个新的扩展系统正在开发中，希望它能长久稳定吧。

@zzxworld 是不是 SS 客户端开启了全局模式？一般用自动代理模式就好，实在有漏网之“鱼”，更新一下用户规则就好。

#12 楼 @tony612 嗯。我要表达的只是行不行的问题。

#5 楼 @tony612 You can create multiple Repos.

@tony612 Ecto Repo 的数据库连接可以在 config.exs 统一修改，如果更换数据库（但表结构不变的话）只需要在这里改一下就好了。如果表结构啥的都变了，那就 migration 写起，这点上两边应该是差不多的。

#59 楼 @m0ur3n

你做的这个 Demo 只能每列单选，而不是矩阵题不能多选。

#57 楼 @m0ur3n 矩阵题是一个大坑，

1. 以后我们未必会用这种方式来做矩阵题
2. 由于矩阵题可以是多选（不定项选择），所以直接滑动到下一项并不是一个合理的选择

一些竟品选择了多重下拉菜单来取代二维矩阵题，我们也在观察和尝试多种交互手段。

#55 楼 @m0ur3n

第一个问题可能只在个别的浏览器下会出现，你能否告知我详细的浏览器版本？

第二个问题其实没有问题，本来就是这样的，在没有交互之前，选项都是随机出现的，并没有顺序，所以也就没有前面的序号。

@1272729223

路由的问题：

路由有两个，前一个，后一个。你可以完全靠前置路由，后置路由则只负责唯一的 entry point（这是 SPA 架构）；你也可以全靠后置路由，于是每一个 entry point 都是预先渲染好的模版交给 client（这是传统的后端负责 view 的架构）；当然，你也可以对半掺，此处并无定式。

所谓 SSR，就是服务端负责渲染首屏所需要的 HTML。至于说 fetchData 发生在哪里 / 何时，或者路由是主要前置还是后置……等等等等，这些都是可选择的，根据你的需要来决定，本质上它们和 SSR 根本就没有直接关系，只不过你去尝试把前端的 view 放在后端来 SSR 的时候必然会遇到这些问题罢了。因果关系不要搞错，不是我写一篇 SSR 的文章就代表其他相关的技术选择和实现都只有我这一套，明白？

Isomorphic 的问题：

同构要解决的问题是同样的 module 在任何环境下都可以执行，拿 JavaScript 来说就是 node.js 和 browser 都可以运行。至于你是整个 framework 都能同构还是一个 library 可以同构，那也是你自己的事情。当你试图让整个应用程序都能同构的时候，最终的结果就好像你完成了一个后端 MVC 的应用，因为你整个前端的 MVC 都可以在后端直接运行，然而你不需要写两遍。

然而这只是一个结果，是因为我们践行 isomorphic 之后说带来的一个 side effect，但不是目的！不是说我为了造一个等价于后端 MVC 的框架才去搞 Isomorphic ……请不要因果倒置来理解这个问题，我发现这是你的特长。

没有 Isomorphic 的时候，举例：前端发 HTTP 请求可以用 $.ajax，但是 jQuery 是不能用在 node.js 环境里的，所以如果我要把用了 $.ajax 的视图用于 SSR 的时候我就懵逼了；node.js 有内置的 request lib，但这个又不能丢在浏览器里运行（你能直接把 rails 整个打包丢在浏览器里运行吗？），这个时候怎么办？isomorphic-fetch 可以。

所以请不要想多了，原始的动机仅仅是 react -> SSR -> isomorphic 而已，最终的结果就是我只需要按照前端习惯的方式去写 view，但是我得到了后端渲染的好处：首屏渲染快，而且不限于 root route，因为 react-router 可以直接在服务端解析，所以任何一个路由节点作为首屏访问的时候都是 SSR 的，为了这个好处才需要解决 isomorphic 的问题，也就是一切路由节点连带的 view 里的代码都能够在 B/S 两端执行，并且一俟 SSR 完成，路由又可以直接在浏览器里工作，于是其后的导航都是直接发生在浏览器里的，所以我们又得到了 SPA 的好处。