顶楼上，最新版本已经到 1.9 了啊

#10 楼 @quakewang 我发的嘛，当然一下就能找到了，而且我很少发帖，第一页就有

#8 楼 @quakewang 你果然出现了，哈哈 一年前你也是这么回复我的 http://ruby-china.org/topics/2649

#6 楼 @huacnlee 说的也是。。。求个心理安慰吧。。。

我的经验是这两个起码没啥作用，你可以去掉 Rack::Runtime ActionDispatch::BestStandardsSupport

小城市招人不容易啊。。。顶一个

#15 楼 @sliuqin 确实是只有一个“环境”，所以其实会存在冲突的问题 只是大家普遍的写法是给所有的 class 外层都加上一个 module 作为 namespace，所以一般你很少碰到冲突

关于变量冲突的这个问题很好，其实我觉得这个方面 nodejs 比 ruby 做的要好，当然有个缺点就是写起来比较麻烦 另外 npm 的包管理比 gem 貌似也要好一点，用了段时间 nodejs 的粗浅感受，大家轻拍

应该没那么高 http://tongji.baidu.com/data/browser 百度的数据参考性应该还是不错的

@quakewang 太牛了。。。

Backbone 难？我倒是觉得大部分 MVVM 的框架才难呢 另外 Backbone 也不是 MVC 哦

呵呵，其实只要用 underscore 的 throttle 函数就行了 http://underscorejs.org/#throttle 另外只监听了 key 的三个事件是不够的，还有很多边缘情况需要处理，所以最简单的做法是用 setInterval + focus/blur 去处理

rubymine 的格式化不错

恩，LS 说得对，我那个记错了，应该是 data-type="json"

你可以在 Chrome 里面抓个包看一下 HTTP 的返回是什么 另外我好像记得还要加个 data-json=true 才能是用 JSON 格式交互

你要看一下 HTML 的源码，确定有 data-remote=true 属性

Servlet 跟 Rails 是一个层面上的东西嘛。。。。

第一点一下没看明白，琢磨了几下，你是不是想说的是防范 CSRF 攻击？

#35 楼 @Saito RequireJS 领先，我觉得一方面是因为人家行动的早所以影响大，另一方面是他到处跑到人家的 repo 去提 issue 让人家支持 AMD 规范。。。 SeaJS 嘛本来就不打算让人家原生支持，提倡自己封装，所以感觉上会弱一点，不过其实不要紧啦，一个支持 AMD 的模块，基本上不要怎么修改，就能变成 SeaJS 的 CMD 规范

#32 楼 @Saito 纯 CommonJS 的方案肯定要后端支持，所以很难获得纯前端的喜爱，后端人员也会觉得麻烦 sync load 确实是个伪命题，所以 SeaJS 说自己主要是模块加载器，其次才是脚本加载器

module 确实是缺乏，但是就我这一年来使用 SeaJS 的经验，基本上不是问题，一来著名的模块官方基本都有提供封装好的版本，二来熟悉了 SeaJS 原理以后，遇到不提供的，自己封装一下也非常简单，除非你想用某些 jQuery 插件，那确实麻烦一些。。。 不过我想 jQuery 插件不是一种好的前端代码组织形式已经是前端界的共识了吧？

#25 楼 @nightire #27 楼 @Rei 哈哈，25 楼这个回复好，点醒了我 是我对 SeaJS 的喜爱让我执着了 另外 rei，这两个还是有很大差别的，我说的不是表面，是内在，有空把代码全改为用 SeaJS 感受下？你的那个笔记开源嘛？

#22 楼 @nightire 唉，说白了两者还是没法很好的并存，我现在的用法就是 spm 处理 js，assets pipeline 处理 scss+img，分离开来做，同样是静态资源，这样很奇怪对不？ 你说的我都赞同，我只是觉得，Rails 现在管的太多了（侵入到了前端领域），虽然目前看来还挺好，但是这未必是件好事 想想看以前 Rails 还支持 ejs（好像是叫这个名字？）呢，那时候是不是也觉得挺方便的？

#19 楼 @edokeh 我对 SeaJS 比较熟，拿 SeaJS 举例，SeaJS 的模块合并并不是简单将文件拼合就完了，还得去转换 模块的格式（其实是通过静态语法分析给 JS 加一些源信息），这个工作 assets pipeline 是完成不了的，那么如果我既想要 SeaJS 的这种合并工作、又想要 assets pipeline 的 md5 重命名该怎么办呢？

#18 楼 @nightire 你说的对，两者实际上确实不是一个层面的东西，但是他们解决的问题有些部分是有重合的（或者说很大部分？） 不过现在问题是，我还没找到非常好的办法，让两者并存，其实最主要问题就是最终的合并部分，你提到的利用 grunt 让两者并存具体是怎么做呢？能否分享一下？

#18 楼 @ywjno play 也不是那么好上手的啊，实际上目前 java 社区的这些框架都不是那么好上手的 所谓用 java 以后好招人这种说法我觉得在现在已经不现实了

视觉上确实不太舒服，下次弄个契合点的图片 不过社区放广告这件事，我觉得完全没问题，看看这里 http://book.douban.com/review/1577242/

#16 楼 @Rei 恩，不过这种方式还是适合小网站，大网站真要合并估计都能上 M，那就不太合适了 ——当然现在我的想法变了，为什么我们非要做大网站？小而美也很好嘛！

#8 楼 @Rei 那个打包成一个 JS 文件的默认做法我最初觉得实在太奇葩，当时还特地去看了 basecamp，发现人家居然还真就是这么做的，有一个 gzip 之后 200k+ 的 JS。。。 仔细想想，这个策略某种程度上还是不错的，平衡了连接数与缓存两个方面，不过最大缺点是发新版的时候就。。。

一直在琢磨着要写一篇《为什么我不喜欢 Assets Pipeline》，看到你这篇文章，看来我得抓紧了 先整理一些观点列举一下：

1. 依赖管理、合并、精简之外，应该还有个冲突隔离（命名空间），这是 Assets Pipeline 做不到（也不可能做到）的而 RequireJS 能提供的
2. 但是这也是 RequireJS 的缺点，因为这样需要改变 JS 的书写方式，而 Assets Pipeline 不需要，反而对新手更加友好，尤其是纯 Rails 开发者
3. RequireJS 系的方案属于纯前端的解决方案，对纯前端人员来说更友好，而且要做到自动化的合并精简也不难，当然在 Rails 范畴内相比 Assets Pipeline 肯定不那么方便，但是放广义一点来说，纯前端的解决方案适用性广阔的多
4. 使用 RequireJS 会强迫你用面向对象、模块化的方式去解决问题，悄然提高了代码的可维护性，但是 Assets Pipeline 不会，现在前端交互越来越复杂，没有这些东西支撑很难想象代码会成什么样
5. 可以关注一下 SeaJS，相比 RequireJS 我更喜欢它，国内搞前端应该都知道它的吧，我写过一篇介绍文 http://chaoskeh.com/blog/why-seajs.html 上面的部分观点在里面

你在 view 层显示的时候改一下就行了嘛 kaminari 修改展示还是非常方便的，参考 http://chaoskeh.com/blog/intro-to-kaminari.html