#16 楼 @nouh Component 也有 didInsertElement 呀。

#4 楼 @ssqq sublime 也是收费的商业软件，rubymine 也有免费使用的 license，何来不好之说？

#13 楼 @nouh 首先呢，CSS 样式真心不需要拆分，很少会有应用写的 CSS 文件庞大到无法容忍单一文件的加载，有多少人能把针对项目的样式代码写得和 Bootstrap 一样大的？然而 Bootstrap 的样式最终也就一个文件而已，合并上项目样式真心没多少。拆开了，HTTP 请求数反而上去了，得失之间还得平衡。

再者入口页面的样式冲突——怎么会？除非一个应用里用了同名的样式但样式的定义却不同。这只能说是你样式命名没有做好，和 Ember 没啥关系，换成别的不也一样？

一定要拆也不是不行，办法有很多，举例来说：

1. 最终生成统一样式文件的，处于复用并扩展的目的需要重写个别样式，可以在区分入口的路由处为路由模版添加作为命名空间的 class，以此来重写。
2. 按路由分割样式文件的，路由激活时动态修改 HEAD 里引用的文件。注意，Ember CLI 默认是把样式打包成一个文件的，即使你按照路由分开写也是如此，但是 Ember CLI 是可以配置的，你可以随意定义最终输出的样式文件，包括数量和路径等等，详情自行查阅文档。
3. 按组件分割样式的，这可能是未来的一种趋势，样式独立于组件之内，不互相干扰。这是一个很美妙的方法，不过真正的解决方案尚未成熟，很多人都在探索。你可以试试这个插件：https://www.npmjs.com/package/ember-component-css

#12 楼 @kisnows 输出 HTML 倒不是 Express 的直接职责，而是 Jade 的。你可以看一下 gulp-jade 的这段代码：

https://github.com/phated/gulp-jade/blob/master/index.js#L14

所以本质上不用 gulp 的话，就是要用 Express 去实现类似上面的功能，简单地说就是调用 jade 来输出 HTML。因为你是在 Express 里面调用 jade 的，所以你的模拟变量都是可以直接使用的。

#10 楼 @kisnows 明白了，我就说一件事，express 和 gulp 的中间环节是可以打通的，需要自己动手做一些改造；或者不使用 gulp 做 HTML 的最终 building，而是用 express 直接写出来，类似以前做 CMS 系统的页面静态化。

#8 楼 @kisnows 既然后端是 Java+JSP，那么 Express 里模拟变量是为了什么呢？因为当进入生产环境之后，真正运行的还是 Java+JSP 吧？在那时 Express 还会有作用吗？

如果还会有作用，那么这个作用是通过什么方式传递给 JSP 那边的呢？Express 暴露 API，然后 Ajax 调用吗？既然如此，何不把 Express 做的事情交给 Java？

如果没有作用了，也就意味着 Express 只是在开发时用一用，那么等到整合进 JSP 的时候，直接输出 HTML 交给 JSP 的开发人员并没有什么错误。

你所面临的问题其实归根结底就是架构上的分工没有明确的问题，你的职责究竟是什么？最终产出物究竟是什么？如果答案就是静态 HTML 的话，你所做的事情是必须的。但如果答案是你要做动态化的东西，可是产品最终要体现在 Java+JSP 的环境内，那么：

1. 要么把现在 Express 做的事情暴露 API 接口，然后用 Ajax 调用；这样即使交付给 JSP 环节的时候是静态 HTML 也没关系，因为数据在 JS 脚本里。要么把你的“模拟变量”的东西交给 Java；
2. 丢弃 JSP，但是 Java 要改造成纯粹的 API Service，前端这边用什么都无所谓，因为数据最终是靠访问 API 获得的，你作为前端的开发者可以得到最大化的“能力”，想怎么做就怎么做。

#11 楼 @darkbaby123

Angular 好玩吗？你是主要用 Ionic 做 mobile app？

#1 楼 @rasefon 不知道你说的 BIM 是什么……

#8 楼 @prajnamas 谢谢，打错字了。

@perish 在 Rails 里面可以用这个：https://github.com/alchapone/polymer-rails，我看过用它的一个 demo。

Polymer 是最接近 WebComponents 的 polyfill 实现，只是浏览器的原生支持还早。另外 Polymer 也只是组件化的部分，并不能替代完整的框架（特指在 SPA 的范畴内，非 SPA 的应用会有后端框架负责路由等其他部分）。在纯前端的领域，现在要让 Polymer“跑”起来还需要几个环节：

1. vulcanize：负责处理所有的 HTML Imports，inline scripts／styles，把它们归并为一个 HTML 文件
2. crisper：负责把所有的 inline scripts 抽取出去变成独立的 script file

另外就是用了 ES2015 的话，再把第二步的结果交给 Babel.js 或其他编译器输出成 ES5。

前面提到的 polymer-rails，用 rails helper 来处理 HTML Imports，用一个很大的 webcomponents polyfill 来处理其他的部分（7000 多行）。没有深入过它的实现细节，不过也是少不了一些 pre processing（为了能工作在现在的浏览器环境下）。

年初的 Ember Conf 有人讲了一篇 Ember＋Polymer 做 hybrid app 的东西，当时觉得挺好玩就实验了一下，的确，当 Shadow DOM，HTML Imports 等等都 ready 之后，组件的开发将会变成一种新的体验。

https://github.com/blangslet/treasure-hunt

这是 Ember＋Polymer 做的 hybrid app，由 Cordova 封装，可以克隆到本地体验一下，演讲者放了一个演示视频出来：https://www.youtube.com/watch?v=lXWVmbs5O8A

正确的做法是 helper，可以直接在模板里用，包括时间格式化也是。一定要折腾，可以用 serializer 在数据层解决，一劳永逸，controller 其实不适合做数据转换的，1 的时候也一样。

#10 楼 @EricZhu 对的，我其实在文中提到过以前会这么处理，不过你有没有注意我现在给出的解决方案（不止这一篇里的）里几乎不会出现 Controller？那是因为随着 Routable Components 的即将出现，Controller 将成为昨日黄花（在 Ember 的世界里），当然了，现在的版本有时候还是必须要用 Controller 的，不过我现在使用 Ember 的一个原则就是能不依赖 Controller 的就不写 Controller（当然是合理的范畴内）

这就是我本文给出的方案的缘由，不是说 Controller 里的 layout 钩子不好用，只是为了着眼于未来罢了。

#2 楼 @kaka 是的

#8 楼 @kosl90 严格来说，你是对的。不过 HTML 是用来“呈现”出 HTTP 状态的结构语言（比如说用户登录与否会改变 HTML 等等），而前端的开发归根结底就是根据 HTTP 的状态来操作 HTML（确切地说，DOM），所以我们已经习惯了直接说“HTML 的状态”。以前后端渲染是由后端“记住”当前的状态，然后渲染出 HTML 交给浏览器，当变成前端渲染的时候，保存和管理状态的职责就转移到了前端，所以说路由才是 SPA 最核心的部分，也是 SPA 框架区别于传统前端开发的最典型特征。

从这个角度来说，SPA 框架管理 HTTP 的状态这件事情从“状态表征”这个角度来说（State Representation）主要体现在两点，一是 URLs，二就是视图（写代码的时候对应的是模版，渲染的时候就是 HTML 了）。

所以这就是个习惯性说法。

#4 楼 @boyishwei ES6 多数东西都很简单，我建议你一边学一边把这个过了：http://es6katas.org/

这就够了，真正难的也就是 Generator 及其所代表的异步编程范式了，这个是要靠理解能力的。我曾经看过很多文章和视频，然而唯一一部印象深刻很容易让我理解的是这个：https://www.youtube.com/watch?v=lil4YCCXRYc，也包括 Async Function。

#24 楼 @rei 你这又是偷换概念了，还在用 jQuery 和只会用 jQuery 并不是一样的。我自己也还在用，只是用的非常少了，然而不用它我也能找出替代品。所以你举的例子并不成立。

我也能明确地说所谓“死抱着 jQuery 不放”绝对不是指 luikore 或者你，因为我知道你们对别的东西都很有研究。我说的是哪些人群我不信你们心里没数。

我指的是整体提升水平有点跟不上业界发展水平，这一点调查里有数据可以作证。而且包括前端的测试也是如此，多角度的佐证。

而你们反驳我的是什么呢？“我认为使用 jQuery 的水平低。”

扪心自问，有吗？

#21 楼 @rei

我说那是现象，这个现象存不存在？如果是现象，哪里来的反驳不反驳这么一回事？而且我说过”个人不能反驳“吗？

#19 楼 @rei

总体水平提升还是有点赶不上，这句话哪里暗示了初始水平低这个条件了？

所谓总体水平提升，指的是从范围（前文的这两年是范围）开始到结束，在这个区间内的增长程度；我原话是拿这个程度与同时间段内前端业界总体的发展程度做对比，才得出“有点赶不上”的结论。这怎么就是暗示初始水平低了呢？

再说了，就算两年前你的 jQuery 用的出神入化，但是两年后你还只是 jQuery 出神入化，那说“水平提升跟不上”又有什么错误呢？

我就问一句，水平提升跟不上 和 用 jQuery 水平低可以划等号？一个说的是相对幅度的增长，一个说的是绝对水平的高低，能作为等价的概念？而且我的沮丧还包括对于测试的调查结果，又不单单说是 jQuery，那是不是同理可证我还认为用 QUnit 的人水平低呢？

扯管理员进来是我越界了，只不过别人说我给我扣帽子的时候并没有看到你说什么，我觉得很不公平罢了，对不对？

#17 楼 @rei 奇怪，你了解前因后果了吗？“死抱着 jQuery 不放手”并不是我提出来的，而是人家给我安在头上的。我说：

话说回来，看到 jQuery 和测试工具的结果还是令人挺沮丧的啊，尽管这两年前端发展日新月异，可是总体水平提升还是有点赶不上。

然后就有人拿 jQuery 说事，认为我看不起现在还在用 jQuery 的人，说 jQuery 水平低——我有这个意思？而且“死抱着 jQuery 不放手”并不是一个观点，而是一个现象，我指出这个现象是客观事实，但并不能因此而说明我看不起使用 jQuery 的人——这是明显的置换概念！

我的观点已经一再反复的表明了：如果你现在离不开 jQuery，那你就用好了，这没有关系。然而作为专职前端的工程师，希望大家能更多的开拓自己的眼界。Clear Enough？

至于你后面说的什么“独立群体”的问题，我很怀疑你看了正文没有？我还特意引用了你说的话：把前端后端分开是不对的”。所以我不知道你的评价从何而来。

说到 make peace 的问题，我表达了自己的意愿，然而我看不到对面的意愿，这种事情是相对的，你不否认吧？

有人还觉得我们是“前后分离信仰”，说被我们“夹击”，这样的言论就不可怕了？这样的态度来讨论就没有问题了？此时此刻作为管理员的你们又在哪里？

要么请保持绝对的独立客观，要么就把道理一五一十讲个清楚，我只看到了反反复复顾左右而言他，我在回帖里一个一个明确的问题有多少明确的应答的？

#60 楼 @ericguo 其实我很不理解一群工程师干嘛要考虑招聘难度？这又不是我们的责任，而且这种事情你考虑了也解决不了，从自身出发来看：凭啥因为市场上没有足够多好的开发者，我就要迁就剩下的人？非常古怪的思路。如果你的队友跟不上，那就淘汰他们，你做好自己的事情就对了，如果你的领导看不出这种差距，看不到你的努力和价值，那就说明你跟错了人上错了车。拿钱给人干活的，想那么些有的没的干啥？如果是创业的，那眼下重点也不在于技术选型上，现在找不到人以后有钱了还怕找不到人吗？总是抓不住思路的重点。

#15 楼 @fresh_fish 完事皆有源头，并非无事生非。

#12 楼 @dxcqcv SPA 不能防未登录访问？怎么可能？有条件禁止路由访问就好了呀！

JSONP 的问题我说过了，应用场景太过局限，也就适合 GET 一些信息，搞个 POST 还得弄 iframe hack。这玩意儿也就做个 widget 小应用能用一下，一般的 CRUD 应用都不适合只依靠 JSONP 的。

#11 楼 @luikore 咱们可以 make peace 的，好吗？之前我对你有任何言辞过激的不敬之处，在此我向你表示歉意，因为本质上我们没有任何利益冲突，我写这篇东西相信你也能看到读懂前端工程师的心声，“用不用 jQuery”根本就不是什么核心问题，核心问题是过去的一些开发方式对专职前端的工程师束缚太大，并不利于健康发展。

“分离”对不对？我说了不算，我起初折腾这个也压根没有考虑过对不对的问题。很多人做“重复发明”其实也压根不是考虑对不对的问题，而是在当时值不值得的问题，没有人是上知五百年后晓五百年的神佛，当时有问题就要想办法解决，不用总是计较这是不是“重复造轮子”。现在的人类社会，能做出“纯粹创造”的条件非常苛刻了，像我们这样的普通人能有多少空间？

别人觉得我们是瞎折腾，那好吧，也许我们水平太差，也许我们见识浅薄，但是我们面对的问题还是存在的，就好比 JSP 套模版那种痛苦落后的工作方式，总得想办法改善吧？OK，也许会有更聪明更牛叉更有创造力的方式，问题是谁来做？

meteor 我早就在关注，他们不停的搞各种 webinar 我几乎都一起不落的追看，那样的前后合一说不定会是更好的选择，说不定会成为未来主流的趋势，但现在的问题是远水解不了近渴啊对不对？或者你觉得现在去搞 meteor 时机足够成熟？

我发现你对“解决眼下问题”的努力通常是不怎么看得上眼的，这我也不说啥，各人有各人的追求，然而我能理解你，你却未必能理解我和其他的前端工程师，我觉得这就是根本的矛盾所在。把这一点说开了也就没啥了，对我来说你看不上就看不上吧，我还得解决眼下的问题，正如同那些死抱着 jQuery 不放手的，爱用就用吧，也没觉得有什么问题，能抓耗子的就是好猫。

#57 楼 @feitian124 你举的那个例子其实挺有代表性的，我其实吧并没有特别想要大力普及 ember，这都是缘分。当初在我自己的公司里评估的时候的确大家会觉得当时的 Ember 有很多问题没有明确的回答，而且那个时候大家对 Promise 的理解（比如你之前提到的，为了重用 promises 返回的对象，该怎么办）都不到位，相比较而言觉得 angular 抽象的 $http 更容易理解一些，所以我们选了 Angular，一直到今天。

所以我使用 Angular 其实比 Ember 厉害多了（笑），真要大力普及的话，前者对我的压力也肯定会小的多，后者我普及它的时候别人问我问题有时候我还得犯傻，还得现查资料，还得去求助别人……如果只是为了当传教士，这个代价也太大了。

那么为什么在这里我总是喜欢谈 Ember 呢？第一，Ember 和 Rails 有着不解之缘，Ember 的很多机制和理念都和 Rails 如出一辙，因为 Java 带给我的影响（我在另外一篇里谈到过），我对 Rails 是有着深深的“爱恋”的，有时候我也郁闷为啥我不去做后端……然而 Ember 给了我很多 Rails 当初给我的感觉。第二，Ember 虽然还有这样那样的不完善之处，但是我对 Ember 的社区和核心开发团队很有信心（这来自于很多细节，版本更迭与发布流程，先后兼容政策，RFC 策略等等）

然而我也承认以前的 Ember 的确有很多缺陷（所以让你痛苦了好一阵子），不过类似的问题放在别的地方也不是没有啊，Angular 处理 current user 很轻松吗？市面上有的 modules 基本上都是针对 token based authentication 的，而我们以前的项目基于很多原因都还是 session 那一套，我们为了 current user 这样的问题在 Angular 里面前后尝试了 n 套方案，最后才封装了一个适合自己的 module 来复用，折腾起来也不一定会比 Ember 轻松多少。

有些东西就是这样，场景需求变化太细致，太复杂，以致于很难搞出特别通用化的 solution。我对这样的问题的看法是：不怕有问题，总会有好的解决方案，我们是程序员，程序员就是 problem solver。有了这个信心，用什么都一样，但总会有更好的。

前后端分离算是我进入前端之后折腾的最大的事情（架构级别），它是不是未来的方向？其实我在我的总结里已经分析过了，至于 Ember 的前景……我未必会有那么乐观——然而这不妨碍我去用它，我用什么东西，市场占有率和前景从来都不是主要的考量指标。

#9 楼 @dxcqcv Jsonp 的适用范围比较窄，至于你说的那个情况我还真不清楚，我们从一开始就是搞标准的 rest API，不存在你说的 jsonp 那个情况

#4 楼 @dxcqcv https

#51 楼 @wppurking 我刚才有个想法，我看到你已经梳理的问题与解决方案都很完整详细了，所以我在想我们是不是可以搞一个 project issue tracker

比方说用 trello 那样的东西，把我们大家遇到的问题、思路、解决方案统一整理到那里面去？这样群策群力应该比个人独立维护一个 demo 项目要更有价值。

甚至于实验用的 demo 项目都可以统一起来，遇到新问题之后可以自己开个分支折腾，或者干脆 fork 一份。但是 issues 统一管理？

反正自己琢磨也是要记录的，大家一起记录可以资源集中共享，遇到想不明白的事情也有个商量的地方，如果你觉得好的话，还可以多拉些人参与，比如 @darkbaby123

以前我用 Angular 的时候就搞过，但是国内 Angular 社区的人都特别浮躁，少有能沉下心研究点实务的人，后来就不了了之了。我的想法是能够最终写出一些开源的 addon 之类的东西，也做做造福大众的事情。

#51 楼 @wppurking 呵呵，无独有偶，我自己写了一个项目叫 fagie（Filling all gaps in ember），也是用来填坑的。工作中遇到的问题我就在这里做实验，然后写文分享出来。

支持你，加油，我会保持关注的。

我不怎么写 todo list，我是把每一个具体功能用梳理好的 git log 来记录，大的东西分成分支来做，回头查阅的时候 checkout 就好了

#49 楼 @seaify React 大神这里有的，我知道，不过他貌似是个纯技术宅，钻的很深很广，这样的讨论我从来没见他参与过。我是一个没什么天赋的人，更热衷于让更多的人开拓视野，所以才会唠叨个没完没了，我也知道会让很多人烦。可是你烦归你烦，世界还是要转的，路还是往前走的。

对了，你看到本站右边的友情链接没有？React China 那个，管理员就是我说的大神，可以去找他单独探讨。

#46 楼 @roclv 其实我根本就没有争论的意思，原本就是一个分享而已，活在梦里的又不是我。

而且你拿 BAT 举例其实很不恰当，这里有多少人天天做的是那么个庞然大物的？更多的是能做到 Skylight，Strikngly，Teambition 等等的就好了吧，BAT 为什么离不开 jQuery 那是有历史和市场包袱的好吗？而且人家的核心技术团队在推动前端发展上面也是不遗余力的好吧？现在 BAT 做些新东西还不是一样会与时俱进？

现实的例子我就知道有阿里云，因为我的前同事小兄弟就去那里高就的，阿里云用的啥？Angular，做的好不好咱另说，至少人家往前走了吧？我那小兄弟也很高兴当初在我们这个小小公司可以尽早接触到这些东西，对未来的成长也是有利无弊啊。如果我当初就跟他说你就用 jQuery 别折腾，这剧本会按现在走？