#10 楼 @hooopo 我正想接着吐槽 Sprockets.

Sprockets 的出现是为了解决什么问题？

• 连接 ( 其他都是附带的。

前端开发到底需要的是什么？

难道真的需要一个打包工具？据我所知，在荒蛮的开发大地上，我们的前端朋友们用 Ant 也打了不少年的包了，这东西真不稀奇，打包不是他们的痛点。

前端开发的痛点是组织代码，怎么写都不爽才是问题。因为没有标准的模块化。所以大家折腾各种 CMD/AMD 的标准。这下写的爽了.. 也没 Sprockets 什么事了。因为 module 天然有 require 的属性，所以必然是通过 module 来判断哪些文件被引用了，然后一起打包。Sprockets 帮不上什么忙。

而 SASS 则更是没 Sprockets 什么事，因为 SASS 天然的支持 partials, 默认就是这样 build 在一起的。

所以 Sprockets 在现在的开发模式下，有用的功能几乎为 0 . ( 不过在当时这些 模块定义 AMD/CMD 还没有被大家广泛接受的时候是有用的，不过仅限于 Javascript.

Sprockets 希望你将 Javascript lib 打包成 Gem 来做管理，本来就是一个 Anti Pattern. 因为这与开发阶段完全脱离，非常依赖第三方人员升级 Gem. lib 与 作者结合的发布方式才是对的。例如 bower ( 方向对了，但是实现的不好。

推荐 Web Languages and VMs: Fast Code is Always in Fashion. (V8, Dart) - Google I/O 2013 可以了解很多 V8 内部，以及 Dart 已经何等出色了..

更新 Note 地址：http://saito.im/note/Turbolinks-sucks/

唱个反调：Turbolinks 并不好。

Turbolinks 的出现是为了解决什么问题？

• 减少 HTTP 连接数。
• 减少 Javascript 与 CSS 的编译时间

解决的同时送给你了什么新的礼物？

• 潜在的内存泄露 ( Chrome 的 DOM 与 JS Object 之间很容易泄露内存，变相提高了程序员素质。

• 额外的适配原有后端逻辑的代码。( 例如 适配 redirect_to 301, 在 turbolinks 代码内部。cache 以及 cookie

• 前端代码的 ready 事件改写。( page:load 可以用 jquery.turbolinks 继续监听 $.ready

• 前端监听事件的复杂化，本来就一个 DOM ready, 现在变成了 5 个事件。你可以小心翼翼的来处理这 5 个事件，来保证程序的正常运行。

• $(document).on 以及老版本 jQuery 的 $(".class").live 要特别小心。尽量使用 BackBone 之类的框架，不要面向 DOM 编程。因为事件绑定之类的会随着 View 对象的消失而被清理，不然需要处理很多 on, off, 以及潜在的多次事件绑定。

怎么样的 Turbolinks 才是对的？

Turbolinks 站在 Server Render 跟 Client Render 的十字路口，决定适配这个世界。我不认为这是未来的开发方向..

Turbolinks 里面有用的功能，不用几行就实现了，而多余的很多行以及后端的代码，都是为了适配写的，解决了一些纯前端框架根本不会遇到的问题。而且顺利的提高了使用 Turbolinks 的学习曲线。

我个人很喜欢 yehuda 的 Ember.js 的宣传语，Ambitious Web Applications. 我觉得未来的体验需要有野心的前端框架来解决。而不是 Turbolinks.

#3 楼 @knwang Product designer

[15] pry(main)> str = "xyz yzx zxy".encode("UTF-16LE")
=> "xyz yzx zxy"
[16] pry(main)> str.encoding
=> #<Encoding:UTF-16LE>
[17] pry(main)> require "base64"
=> false
[18] pry(main)> Base64.urlsafe_encode64(str)
=> "eAB5AHoAIAB5AHoAeAAgAHoAeAB5AA=="
[19] pry(main)> base64_str = _
=> "eAB5AHoAIAB5AHoAeAAgAHoAeAB5AA=="
[20] pry(main)> base64_str.unpack("m*")
=> ["x\x00y\x00z\x00 \x00y\x00z\x00x\x00 \x00z\x00x\x00y\x00"]
[21] pry(main)> base64_str.unpack("m*").first.force_encoding("UTF-16LE").encode("UTF-8")
=> "xyz yzx zxy"

http://guides.rubyonrails.org/rails_on_rack.html#configuring-middleware-stack

@lgn21st 恭喜！

右侧的菜单很难点到。

#9 楼 @jiyinyiyong 没有，倒不是这个.. 你会尝试用 JS 去做所有的事情吗？

其实 JS 可以做到不止写 HTML.. 还可以写 CSS. 还能写 HTML .. 为什么大家不这么干呢？

#7 楼 @jiyinyiyong 用 JS 写 HTML 代码..

看起来好像是在 JS 里面可以直接写 HTML.. 而已。

#5 楼 @jiyinyiyong <div>{'Hello ' + this.props.name}</div>

JSX 是邪道啊...

printf("%I64d\n", _sum);

#13 楼 @BreeStealth brew cask alfred

#15 楼 @_samqiu Got it!.. 这种方式挺好的。

#16 楼 @ywencn Liquid 的方式就是写很多套模板的节奏... 我觉得 partial 组织的好的话可能需要写多套 layout.erb .. 每套 layout.erb 对应 layout.css... 剩下的不用动。

#10 楼 @_samqiu 装修的时候是用户自己写 Liquid 脚本吗？还是拖拉性质的...

#8 楼 @ywencn shopify 用户能装修吗？我没用过。

#4 楼 @ywencn

CSS 不就是控制页面布局的嘛..

HTML 结构写得好怎么控制都行这种话我会乱说吗？要不然 media-query 不就没有根基了么。

phantomjs. 挺好实现的，算是它的基本功能了...

var page = require('webpage').create();
page.open('http://ruby-china.org/topics/11426', function() {
  page.render('ruby-china.png');
  phantom.exit();
});

!

多种页面布局的模板难道不是只改 layout.css 就可以了？

没有这样的 hook, 现在的 hook 都是从 post-receive hook 里面过来的。

#13 楼 @bhuztez 这个问题还是挺复杂的，毕竟自处理补偿机制之类的很难做到完美..

#10 楼 @fredwu 哈哈，好吧。

前厂因为有分布式事务的问题，所以每天都要对账...

#8 楼 @nightire 我的问题，已经重置密码了... 在 Twitter 上声明了。Orz..

#43 楼 @jasl #45 楼 @changwu 你们的方案我在前面都提过了... 不认真看帖就回帖的银...

prefix 是 pure 确实比较难受，不过他是为了跟 bootstrap 兼容，也难为他了。

#39 楼 @leopku 很早就有人搞过了，后来因为更新太快.. 打包的人跟不上就烂尾了...

#36 楼 @zgm 嗯，不过还得几个月。