#44 楼 @seaify 对的，你已经想到了鉴权信息返回 JSON 了，那么 SPA 框架就是再做一步类似 cancancan 的事情，写一个 service，封装获取的鉴权信息数据，提供一些类似你说的 if can? 这样的 helper，然后就可以在模板里用了。原理上并没有什么区别，就是一个单例对象，应用程序初始化的时候实例化，里面封装了当前用户以及整体的鉴权信息，然后有一些 API 可以操作。你在 Angular 里可以依赖注入这个 service 到需要的 controller，然后视图里直接用就是了（Angular 没有 View 层，controller 维护一个 view model 对象供模版使用）。其他的框架都有类似的机制，React 的话应该是干脆统一保存在 Store 里吧，没写过大型的 React 应用，照原理猜测的。

只是我不知道有什么 3rd party API 特别像 cancancan 的第三方 service，如同我说的，我都是自己写的，我觉得不难。

#42 楼 @seaify 我问你一个问题，假设你用 Rails 做了一个 API，认证用了 devise，鉴权用了 cancancan，那么这个 API 如果给 iOS 或是 Android 用了，他们和你的 API 也是前后分离体系，那么他们又是怎么处理的？（这是等价的概念）

由于我工作中公司里用的是 Java Spring 做的后端 API，我很难针对 devise 以及 cancancan 说什么特定的解决方案。但是认证这块，不就是要么 session，要么 JWT，要么某种开发协议（比如 OAuth）嘛，说到底就是和 HTTP 打交道。这种类型的现成解决方案不要太多啊，React 我不了解生态环境，Angular 一大把，Ember 也有 simpleAuth，Torii 等库来做。

至于另外一块鉴权，我没用过任何第三方的组件，做了四年 Angular 都是自己写的 service，这东西没有想象中那么难，当然也可能是我没碰到足够复杂的应用场景。正好我新工作开始换用 Ember 了，有关心得体验也在连载中，等到了这一块我单独开贴写好了。

#4 楼 @wppurking

bower 和 npm 的问题

其实现在整个前端都倾向于只要一个 npm 就好，但是当初 npm 自身有一些问题一直没有得到很好的解决，所以 bower 等就有了生存空间。现在已经是这个现状了，大家也很无奈，只好一点点的迁移吧，相信有一天包管理器会统一，ember cli 也只是顺势而为罢了。

bourbon 的问题

我不推荐沿用 bourbon 的 vender prefix，因为相比 autoprefixer（每次 build 的时候即时更新），bourbon 的更新毕竟是慢的，而且它的前缀写成什么样就什么样，错了漏了多余了你这个使用者也无可奈何（除非提交 pr 改它）。然而这也没办法，当初 bourbon 诞生的时候还没有 post-css，它也没料到会有 autoprefixer 这样的东西，而且也没法保证大家都知道用 autoprefixer。

至于 autoprefixer 的优势……难道你只用 bourbon 啊？你自己也要写啊，你还用其他的库啊，你没法保证大家都乖乖写好吧？autoprefixer 是针对最终 css 产生作用的，它的好处就是让你无脑写样式，从此不用考虑前缀写不写写多少的问题。

不过！它不能替代页面测试，因为供应商前缀不是万能的，不是说用了它所有的 css 在所有浏览器里都没有问题了，最终的测试还是必要的，它只是帮你省去了开发时的痛苦而已。

#38 楼 @feitian124

1. model 看起来是写两遍，但实际上是把一部分以前在后端的 model 逻辑移交给了前端，减少后端的代码量和处理负担。比如说数据库有 firstName lastName 俩字段，前端定义 model 不是为了单取这俩字段，而是为了合成另外一个 virtual attribute，fullname。这就是个例子，具体能怎么用要看大家的群策群力。现在的确还不算特别成熟，但是不努力就不会有未来，你也可以观望到成熟再用。

2. 验证逻辑也要重复那说明前后的职责不太明确，一般来说分离之后前端验证的是“有没有，全不全”这样的逻辑，后端验证的是“对不对，危险不危险”这样的逻辑。虽说不能保证完全不重叠，但是你要明白前后分离的真正目的不是一对一的服务，而是一对多的服务（一个 API 端可以服务于多个/种客户端），所以时间紧的时候可以优先只考虑后端验证，返回出错信息也是可以接受的。

3. SEO 问题已是昨日黄花，处理和解决办法有很多，不能说它不存在，但真没有人们想象的那么夸张。当初 Ajax 大量用来替换页面内容的时候和现在的 SPA 在这方面又有什么本质区别？多跟一下 Google 的 Youtube 频道，有很多讲这方面优化的。

4. session 保持……这个很难吗？我做了好几年的前后分离，没觉得这有什么技术难度啊？或许我没理解你说的意思，不妨单独讨论。

#33 楼 @luikore

哈？难道你就是这么理解的？今天真心见识了！

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

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

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

而且我也强调了，对于偏重后端的全栈型工程师，出于各种因素考虑必须还得和 jQuery 对付着的，这是可以理解的，我也没说不能用啊？！

但是这个调查面对的是纯前端工程师或偏重前端的全栈型工程师好吗？我针对这个前提说“总体水平提升有点赶不上”又有什么错？

如果你现在是一个只会做前端的工程师，你跟人家说我就会 jQuery，测试？不会！自动构建？不会！ES2015？没听说过！这样的，就算说你水平低，有异议？今年是 2015 年，不是 2005 年好吗？

我还能说什么？语死早吗？算了算了，我真不想和你就此问题争执下去了，我作为偏重前端的工程师一向都特别尊重后端工程师，但是在这篇帖子的众多回复里，我看到的却是众多后端工程师对前端这块发展所抱持的怀疑和否定，总觉得在你们眼里大家就停留在 jQuery 就好了，前端也不要瞎折腾了。

我不知道历史上是不是也有同行这样看待过力求进步的后端工程师们，如果你们觉得这没什么那就没什么吧。

我们他妈的求进步就等同于认定你们水平低？这什么逻辑！

顺便借回帖多说一句，前后分离并没有说要用在所有类型的项目上，什么需要什么不需要这是需要您们自己判断的，而且众多新技术也不只是为前后分离而诞生的。不想用也可以不用，没人逼你们，何必总是一副受迫害者的样子？

真累。

#26 楼 @luikore 我有这么说么？我觉得你只是把你的怨念强加在我身上而已，你所说的一切，比如：

1. 你觉得 Vanilla JS 优于 jQuery
2. 觉得自己工具和理念比 jQuery 优越

我没有这样说过吧？我对“沮丧”的解释在前面已经说得很清楚了，不知道你为什么总是认为我们在排挤 jQuery？

另外，elm clojure 等等要用在浏览器里就不需要编译了？

只靠 React 就能写大型应用程序了？

没有哪一种工具是万能的，但偏偏很多人却觉得 jQuery 是万能的，别人连说它都不能说了？更何况也没有强求大家不要用它，只是希望能有更多人往前迈一步，有错？难道不用 jQuery 就只剩下 DOM 着一种选择？难道你用 React Ember Angular 的时候还要天天写 getElementById 这样的 API？

我和你的根本分歧就在于：

1. 我说不用 jQuery（其实也没说不用，只是少用，但偏偏都觉得我是说不用），不是不让用，而是鼓励去尝试更多的选择。
2. 你说不用 jQuery，然后就只剩下 DOM 这一个选择了……这样一对比你自然是稳居不败之地。

现在的趋势就是想推动前端继续进步的人却被一群自恃全栈工程师却死抱 jQuery 还不许人家撒手人拖着后腿

很讨厌像这样乱开地图炮，模仿一下而已，不会生气吧？

#24 楼 @feitian124 前端变化快是不假，但是 ember 和 react 不是一个概念呀，一个是全功能的框架，一个只是视图层的库，不用都学啊。webpack 就只是一个模块加载打包器罢了，周边工具而已，学起来也没有什么负担。而且 ember 有 ember cli，webpack gulp 之类的都不需要用的，而 react 本身只是解决了视图层的问题，你要做大规模的应用还得解决其他环节，比如路由，数据映射，事件分派等等，最终你等于用各种库拼出一个 ember 来——当然还是有区别的。但是 react 的优势其他框架又不是没有，DDAU ember 也可以实现啊，virtual DOM ember 的 glimmer 引擎也毫不逊色啊。

#13 楼 @seaify 我给你加了一个新项目在原来的回复里，这个新项目不是很知名但是它很新，你可以看到基本上都在用最新的版本，而且代码更新也比较勤快（应该是正在开发中的项目）

#12 楼 @seaify 当我们说到“前后端分离”的时候，我不知道诸位后端工程师是怎么理解的，但是在我们前端看来所谓“分离”就是所有和前端相关的代码：HTML＋CSS＋JavaScript，它们都是可以在完全没有后端的环境下进行开发的。我们不需要把源代码混合在一起，我们不需要把运行环境混合在一起，我们不需要把部署混合在一起，从开始敲下第一个字母直到最终上线，前端工程师都完全不需要知道后端到底用了什么，放在哪里，如何运行。唯一联系彼此的纽带就是 API 的通信和线下的设计、业务沟通等等。

我的确看到一些 Rails 项目使用了 Angular／Ember 等 SPA 框架，但是代码却是混合在 Rails 框架里的，如果你仔细审视他们的写法你会发现他们根本就没有分离，他们还是用着老一套的思想去做 UI 编程，唯一不同的是他们利用了那些 SPA 框架里的一些特性而已，比如说数据双向绑定，模版系统等等。然而这和我们前端所说的分离还相差很远。

如果在架构体系上做到了我所说的那种分离，也就意味着你之前所用到的任何 gems 都不再需要了，因为我们根本就不需要依赖 Ruby 环境好吗？所以你不用舍不得的，任何涉及到前端开发的 gems，前端的生态系统里（主要是 node＋npm）都一定会有一样的或类似的，只可能更好不可能更糟。从另外一个角度说，现有的项目并不建议彻底的分离，因为的确如你所说有很多东西需要替换。

#18 楼 @yanguango 如果你觉得 fine 那就 fine，我不觉得我这句话有什么问题。作为前端工程师，我知道有比 jQuery 更好的方法和思想去做我的工作，但是非专业的前端工程师却要对我说：jQuery 没什么不好的，你不能指责用 jQuery 的人。问题是我有说 jQuery 不好吗？我有认为还在用 jQuery 的人羞耻吗？我只是觉得到了今时今日，还有这么多的前端工程师（请注意，这个调查的对象都是前端工程师，不是偶尔做一些前端的后端工程师）还如此依赖 jQuery，舍不得迈开探索的一步，这个现象让我觉得沮丧而已——这么多人看不懂吗？

既然你们觉得停留在 jQuery 的 comfort zone 就足够了，那我的确没什么好说的，觉得 fine 就觉得 fine，有错？

至于后面那句话，其实是我回错人了，所以我删了，向你道歉。

#15 楼 @luikore 咱们不说这个了好吗？我觉得你也是一个高手，我很不好意思和你争论这个话题。

这就好比我也懂一些 Rails，其实我写过的 Rails 项目虽然简单但自认为写得还是比很多后端工程师好的，然而我不会评价 Rails 哪里不好，或者还有什么更好的。因为我有自知之明，我知道以自己在后端开发上的见识还不足以对这个生态系统评头论足，先学会用好就是了。

所以你看看你说的话，懂行的人一眼就看出来和我说的不是一回事好吗？是否要用 jQuery 来操作 DOM，和是否以 DOM 为中心来进行客户端 UI 开发，这是一个性质的事情吗？如果用了 Angular／Ember／React，还成天净研究怎么操作 DOM 的那只能说明他白用了好吗？

实在没啥可说的，我就此打住了，如果觉得扫了大家的面子那我道歉，我只是想分享一个调查而已。我说 jQuery 和测试框架的现状让我沮丧这是事实，而且我自己沮丧不代表不让大家用啊，搞不懂怎么就触碰到一堆敏感的神经了？说句真心话，比起调查结果里的 jQuery，这里的一些回复才真的是更让我觉得沮丧呀……我一点都不觉得 jQuery 有什么不好的，真正不好的是它对很多人所产生的影响。

Someone said: jQuery is good, no judgement. But we do have more better way to do client side application development, we do need to think about some other way to get rid of the ugly DOM manipulation, we do need to move forward, to embrace the changes, to make UI development more and more better.

Then there always others responded: go away! jQuery is the best tool, don't try to ignore it, we like it.

OK, if you are back-end guy who do some font-end works, or if you are full-stack engineers who not require to do complex UI development, then you think jQuery is enough, that's fine to us, just go ahead. But we, as professional font-end developers, we deserve to move forward, to create better solutions. You don't need to join us, you can still stick to yesterdays, but plz do not drag on us, just sit back, we do respect to each others, don't we?

#8 楼 @pynix 我非常希望用视频的方式来分享我的所学所感，但后来我发现录制视频实在是需要花费大量的时间（除非你不在乎质量）。写文的质量比较好把控，而且容易修改，但视频就不同了，录制一份质量过硬的视频，前期的准备时间会是实际录制时间的 3-4 倍。鉴于目前我还是得把大量时间用于工作和学习上，视频计划只好搁浅，等到实现一定程度上的财务自由会重启。

不过这不代表我不录了，我现在还是有时间会录些东西，但由于没什么系统性，都是小范围传播一下不怎么公开罢了。我的个人理想是传播技术，特别是给国内的广大渴望知识的同行，所以以后还是会有的。

#9 楼 @seaify 另外，使用新技术的往往都是从内部项目或是非开放型项目开始的，所以公众平台上可能比较少也很正常。别的框架我不了解，Angular 的开源项目简直不要太多，问谷歌吧。Ember 的话可以看看这里：http://iheanyi.com/blog/a-list-of-open-source-emberjs-projects/ 都是质量很高的。

https://github.com/TryGhost/Ghost https://github.com/aptible/dashboard.aptible.com https://github.com/wordset/wordset-ui https://github.com/hummingbird-me/hummingbird https://github.com/discourse/discourse

这五个都是值得一看的，它们都符合你的要求：开源，Rails／Grape Backend API，大项目，有线上产品可以参考等等

https://github.com/kagemusha/crambear

#9 楼 @seaify 你前后分离，还关带 viewer 的 gem 什么事？恕我愚钝看不明白你在说什么。

#6 楼 @luikore 你可以不用所谓“臃肿的框架”，但作为前端工程师你也不能离开了 jQuery 就不会做任何事情，这是对于前端工程师的要求而已。

我们对 jQuery 的结果感到沮丧，不是因为 jQuery 不好，也不是鄙视还在用 jQuery 做项目的团队／个人——这些都很正常，比方说使用 Angular 或 Ember 等“臃肿框架的”，当面对 DOM 操作的时候多数人还是会操起 jQuery／Zepto。

但是作为前端工程师的我们必须知道 jQuery 的来由，知道它曾经如此红火的原因，同时也应该知道现在生态环境的逐渐成熟，有多少事情其实是不必依赖 jQuery 的。太多太多的人用各种理由来为自己“离不开 jQuery”做辩护，太多太多的人用这些理由束缚自己的脚步和视野。

更多的我不想说了，叫不醒的人永远都叫不醒，他们永远都会有数不清的理由，随便吧。

只说一点：离不开 jQuery 的，将永远把 UI 编程弄成“以 DOM 为中心”的编程，如果你觉得 fine，那就 fine。

#1 楼 @etnl 嗯，是的，我写完没检查……

#13 楼 @blacktulip 是啊是啊，灌个 Ubuntu 的话，我就不会在这里评论了。

#11 楼 @blacktulip 那身为程序员觉得有必要这么一比的话我也没话好说咯

#4 楼 @cdx_net 莫喊穷了好吗，现在 Mac 根本不贵，前几天休假的时候一个老家的朋友来上海玩，带他转 Apple Store 的时候愣是把人家吓到了：原来 Mac 这么便宜的？！

#2 楼 @darkbaby123 更要命的是自己屏幕上的代码也的确变化了，只是和自己想的不一样……

顶顶顶～～～

#9 楼 @chairy11 你应该使用了 rvm 来管理的，但是却没有用对，有些细节上的问题，翻翻文档吧。

ruby-2.2.3/ v.s. ruby-2.2.3@global/？

#8 楼 @wikimo 没什么特别的看法，想用就用咯，就是个工具罢了，用谁不是用啊。

#6 楼 @chenjiufu Grunt 和我上面用 gulp 的例子没有本质区别

#3 楼 @wppurking 其实自动补全我并不是很看重，因为我都是习惯手打的，上面的布置主要还是为了依赖关系之间相互跳转方便的，很多人都不会配置这个，找个源码看得我费劲儿啊。

其实不依赖 IDE 的补全机制的话，还是用更轻量的编辑器来得痛快。

#1 楼 @darkbaby123 嗯，有些轻微强迫症，如果要用 ; 我一定会倾向于所有 required 的地方一定加，所有 optional 的地方一定不加，这样一来总是把一点点的碎片时间浪费在代码格式化里……所以索性一概不用。回到 Ember 以后，Ember CLI generate 的 文件都有 ;，着实让我纠结了一阵，哈哈。

#5 楼 @pynix 这话说的就太没见识了，不解释，自己去纵观下 component 和几个前端框架的发展史，别总是因为 xxx 最近有点小火就动辄 xxx 化了，这叫“殊途同归”。

#10 楼 @cbdfocus 你所疑惑的这种现象叫做 Hoisting，可以看看这篇总结：http://segmentfault.com/a/1190000000348228

大学新生还要考虑就业问题？等你就业至少 4 年后了吧，谁知道届时世界是个什么样子呀～现在学东西别考虑什么就业问题，对于一个大学新生来说，最重要的是从兴趣入手，学那些对你有一点点难度但是又不会让你望而却步的东西。具体什么语言其实不重要，还是多学点 general 的知识更有助益。