#23 楼 @wildchilderic 不一定。

首先，客户端性能不是可忽视的，特别是移动端。https://medium.com/dev-channel/javascript-start-up-performance-69200f43b201#.5o2nxx2gw

其次 从 HTML 页面转 JSON API 不一定能降低服务器负担。像 Ruby China 的 API 优化得没有 Web 好，你可以调试顶楼的 demo，首页 Web 一个 30 毫秒请求，换成 API 需要两个 80 毫秒请求，服务器负担变大了。即使优化很好我觉得差别也不会大，因为数据库耗时是一定的，渲染部分都缓存住。

React 推广之初，性能是一大卖点，最有名的是 dbmon 的测试（https://www.youtube.com/watch?v=z5e7kWSHWTg），凭此测试让 React 引起了广泛关注。不过接着就被发现之前 Angular 的测试版本写错了（http://blog.500tech.com/is-reactjs-fast/），实际上 Angular 和 React 不相上下。用来做性能评比的是一个很极端的例子——一个高频刷新的表格，并且每个单元格都有自己的逻辑（弹出框）。如果要做一个股票交易工具也许很适合，不过一般的 Web 应用不需要这么高频刷新。

但是信息传播很容易走样，“高频刷新下 React 性能很好”经过传播后就只剩下了“React 性能很好”。接着，遇到服务端渲染慢的时候就会想，用 React 重写前端是不是更好。有的团队真的这样做了，花了几个月前后端分离，用 React 重写前端，结果还更慢了。接着为了渲染速度和 SEO 又去做 React 的服务端渲染……

我早前也有疑问，用 JavaScript 渲染页面真的比浏览器直接替换 body 快吗？如果说 Virtual DOM 可以减少绘制提高性能，那么 JavaScript 本身的计算消耗如何呢？但是很少有团队会把一个产品用服务端渲染实现一次，再用客户端渲染实现一次，一直到了最近有人利用 Ruby China API 重写前端，我才有机会做一个公平测试。

数据表明，对于整页替换的网站，前端渲染没有性能优势。所以如果你做的项目比较像一个网站，那么大可不必用前端渲染，从性能和 SEO 角度来看服务端渲染更好。对于大多数网站来说，以 Rails MVC 为主，少量 JavaScript 做调料，复杂组件用前端渲染，是最简单高效的。

我的意思不是说前端渲染无用，让大家不要学，前端渲染有它适用的地方，应该更多从功能上判断。如果你的网站有很多客户端状态，有很多拖拽、弹层、动画效果，需要提供离线功能，或者其他不适合用服务端处理的地方，那么就应该考虑前端渲染。

“Fat Model, Thin Controller”我一直没找到 Rails 官方资料或者核心开发的分享有推荐这个准则，为什么说是 Rails 的指导呢？

相反我找到一篇 DHH 的文章指出不要为了代码重用而把代码都塞进 Model http://david.heinemeierhansson.com/2012/emails-are-views.html

我觉得逐条转换没问题，不过 update! 用错了，每次调用都会保存一次数据库。

CoffeeScript 默认用闭包包裹，assets pipeline require 可以处理依赖。

https://cloud.google.com/datalab/

如果只是顶楼的三个需求，在管理后台自己加个图就好了 http://www.chartjs.org/

甚至不需要可视化，输出表格。

Kibana 可以随着运营人员的需求变更灵活调整。

Elastic 全家桶 https://www.elastic.co/products/kibana

#8 楼 @luft 之前没看过这个工具，看了几节文档。

我赞同副标题的内容“book is a program”，书有源码、编译、发布，跟程序差不多。不过这个工具跟 latex 的问题一样：难用。我是不知道怎么向一般作者介绍这个工具，写作之前要学习这套 Lisp 系 DSL，门槛太高。

在我构想中，制作一本书的可以分开三个环节。

1. 作者写作，这个过程作者只需要考虑内容，不需要考虑样式和构建。工具可以是标记语言，或者其他标准化文档的编辑器。
2. 制作样式，这个过程由技术或设计师进行，工具是 HTML/CSS/JavaScript。
3. 构建发布，这个过程是自动化进行，把内容和样式编译成各种格式。可以是命令行工具，也可以是 SaaS。

所以在我看来现在最接近理想的工具是 GitBook。

#3 楼 @markluo 复杂情况用 clock process，更好的调度和扩展，不用 crontab。

1. crontab 手写不难，whenever 可以减少重复代码，但不是必须，web 更没必要。
2. 如果只是需要载入 rails 环境并执行脚本，rails runner 比 task 合适。
3. 如果需要经常修改运行时间，提供 web 界面，推荐 clock process 模式，例如 sidekiq-cron。

#7 楼 @kai209209 coffee 支持 import export，但是不解析模块，需要再加一个 babel 之类的编译器。

ES6 在浏览器环境算不上原生。

#16 楼 @u1452261116 我觉得是的，不确定有没有其他方法。

密钥暴露到客户端是有问题的，被别人盗用作恶被禁用的时候连带自己的应用也被禁用。

mock 是单元测试用的吧，应该放在客户端的测试代码里，怎么会让后端解析 mock 规则呢？

如果是为了开发联调，应该部署一个全功能的 test 环境。

如果一定要用 mock 模拟服务端，让他们自己搭。

热闹驱动开发 http://www.luanxiang.org/blog/archives/2291.html

#5 楼 @lulalala

Asciidoctor PDF

使用 Prawn 绘制 PDF，Prawn 不支持 CJK 文字环绕和 OTF 字体，需要打断字补丁，字体选择很少，样式设置很不方便。

以前处理的问题汇总在这里 https://github.com/asciidoctor/asciidoctor-pdf/issues/82

不过修了一个 bug 又引出新的 bug（https://github.com/chloerei/asciidoctor-pdf-cjk/pull/3），我不想再在这个方向投入。

我打算用 http://wkhtmltopdf.org/ 生成 PDF，借助 webkit，使用者可以基于 HTML/CSS 设置样式，字体也可以使用任意系统字体。

Asciidoctor EPUB3

这个包基本可用，就是有些小问题，但问题虽小却不好修。另外也是难于定制样式。

Asciidoctor 本身

代码很复杂，我想加个 rouge 代码高亮都无从下手，理解 Asciidoctor 的内部数据结构不如 HTML 方便。

综合这些问题，我觉得用 HTMLBook 作为中间格式会更好处理，不跟 Asciidoctor 耦合。

多谢楼主的工作，我终于可以拿两个几乎一样的页面比较 Turbolinks 和前端渲染的速度。

首屏速度（主题列表）

Turbolinks

React

分析

减去空白时间，Turbolinks 耗时 281ms，React 耗时 474ms，Turbolinks 是 React 的 59%，前者大幅领先。

换页速度（从主题列表进入主题页）

Turbolinks

React

分析

减去空白时间，Turbolinks 耗时 219ms，React 耗时 251ms，Turbolinks 是 React 的 87%，前者小幅领先。

总结

渲染同样的页面，Turbolinks 总是比 React 实现的快。数据不说谎，认为客户端渲染比较快的，要不是错觉，要不是只关注服务端耗时忽略总体耗时。要注意的是，这次评比 React 实现是访问 Ruby China 的 API，服务端响应更快数据量更小，但内容展现到用户面前的时间，还是服务端渲染耗时更少。

事实上，这也不是完全对等的对比，我相信还有很多功能 React 版本是没实现的，我特意用未登录状态测试，避免受影响。同为 js 打包成一个包，Turbolinks 执行 js 的时间更少，秘诀是把 AJAX 响应逻辑隐藏在服务端，只有调用的时候才需要浏览器解析；客户端渲染则在初始化时就解析了这些逻辑，因而花在 js 的时间更多。功能越多，客户端方案会越重。

除了速度外客户端渲染还有一个问题，就是内容闪烁。从主题列表进入主题页的时候，虽然页面框架保留，但是需要等待 api 数据，造成一小段时间内内容部分空白，给用户的感受就是内容闪烁。当然，可以用一些动画效果优化更新方式，不过在网络本身足够快的时候显得有些多余。而 Turbolinks 则是整页替换，网络理想的情况下给用户的感觉是切换瞬间完成，体验更好。

我理解为什么现在客户端渲染方案大行其道，根源还是前后端开发者间的语言差异。在传统 Web 开发中，前端是整体项目的附属品，前端的每次修改都需要服务端配合，服务端可能是 Java，.net，PHP 模版，框架也缺乏对前端代码管理的支持，前端改起来很吃力，于是 JavaScript 前端琢磨出了不需要服务端配合的纯 JavaScript 前端方案。在大公司环境下，分工不同、各司其职的思想下，前后端分离很合适部门划分。很多时候架构设计不是出于技术考虑，而是在适应人员结构。

但是 Rails 提倡的是另一种思路，Rails 项目是高内聚的，各个开发者之间没有明确的界限，前端应该了解后端，后端也应该了解前端，重视整合系统，这样可以从项目整体作出最优判断。Rails 项目和别的项目集成又可以实现低耦合，通过 api 和消息队列和别的项目进行通信，别的项目用 Rails、PHP、Node.js 都不成问题。

最后，我希望 Rails 开发者不要放弃钻研前端，把 Web 项目甜美的部分拱手让出，Rails 本身已经不仅是 Ruby 框架，也依赖 Node.js。对于 Web 项目来说，能到达用户为人所用，解决用户的问题，提供好的体验才是一个好的项目。另外也希望参与 Rails 项目的 JavaScript 前端多了解 Rails，Rails 对前端提供了良好支持——虽然跟 JavaScript 的主流不太一样。但顶尖的 JavaScript 程序员也在向 Ruby 社区取经，举个最近的例子，Facebook 的 Yarn 就是借鉴 Ruby 的 Bundler。了解 Rails 会让你成为更好的前端。

PS：上面的文字并不是针对楼主，楼主做的工作是有意义的，继续加油！

PS：有点难

我猜需要先安装字体到这些目录 https://github.com/metaskills/pdf-writer/blob/7f5bc6c9ce69c26574bbfde36ebdb9ecf06709d0/lib/pdf/writer.rb#L111

指定日文字体，我在这个库的源码里看到有 demo。

#21 楼 @sefier 楼主问 csrf，那么 web app 和 mobile app 都有可能啊，所以我问楼主有没有用 cookie 验证，因为 web app 可用也不用 cookie。是你先入为主。

补充：Ruby China 的安卓 APP 基于 turbolinks 实现，其实是 webview，需要防 csrf。

#19 楼 @sefier https://en.m.wikipedia.org/wiki/App

App, apps or APP may refer to:

• Mobile app, software designed to run on smartphones and other mobile devices
• Application software that causes a computer to perform tasks for computer users
• Web application or web app, software designed to run inside a web browser

#16 楼 @sefier 技术讨论干嘛搞得像批斗会一样，最后一段话对解决问题没有帮助，提问者不就是因为不懂所以提问。如果你知道问题所在，可以提供参考资料。

现在前后端分离这么流行，也许楼主说的 APP 就是网页前端，放在同一域名，通过 cookie 验证，这样就需要防 csrf。

#2 楼 @timlen 你不能只是把 Turbolinks 加上，还要看它的文档，不然就会遇到各种问题。

我觉得电商网站挺有必要实现这套，随时会新增运营人员但限定不同权限。

核心需求我通常会自己实现。

Ajax 操作之后用 history.replaceState 更新历史记录。 RubyChina 用 Turbolinks 已经自动处理了。

https://ruby-china.org/topics/31858

哦，发现楼主已经回帖了。