Turbolinks 并不糟糕

Turbolinks 是 Rails 4.0 的默认组件，我用上的时间大概比 Rails 4.0 的发布提前了半年，所以我写了一些文章介绍 Turbolinks 的用法和要避免的陷阱，这样后来用上的人就可以不掉到这些陷阱里。

我并不意外看到这样的评论：

Turbolinks 不好

我是不会用的，简直就是鸡肋

我不打算成为 Turbolinks 的鼓吹者，不止一种方法去做一件事，每个开发者都可以根据自己的情况进行选择。但是我不希望见到一项技术不能解决所有问题，就完全否定它的价值。对我来说，我有充足的理由使用 Turbolinks，并基于它改进我的网站的体验。这些理由也许对其他人也有用。

轻量级

到 2.0 版本为止，它的代码是 282 行 CoffeeScript 和 66 行 Ruby 代码，一个下午可以将它的代码全部读懂。

这也意味着它不会承担过多的工作，它的作用就是加速站内链接的加载，避免 js 和 css 的重复编译。所以不要把它和客户端 MVC 框架直接对比，客户端 MVC 只有路由部分是和 Turbolinks 冲突的：Turbolinks 将路由保持在 Server，而客户端 MVC 将路由放置在 Client。

路由放在 Server 的好处是，我可以在单独某个复杂的页面引入 MVC，其他页面不使用过多客户端代码却有类似体验。

改良而非颠覆

Turbolinks 可以提高网页载入速度，减少网页闪烁，但不用改变现有后端，不用整站重写、将 html 模板全部改为 JSON API。

为了达到这个目的，也可以用客户端 MVC 进行客户端渲染。客户端 MVC 很好很强大，除了这两个好处，还带来了数据绑定、系统解耦等大量的好处。但是这不是没有代价的，系统解藕需要更多的学习成本、开发成本。

对于现有项目，除了用客户端  MVC 重写和完全不改动这两个选择外，还有中间的选择：用 Turbolinks 改良现有网站体验。

JS 陷阱是单页应用共有的

进入单页应用的环境，就要考虑更多的 JS 陷阱：内存泄漏、学习曲线增高、事件绑定。

这些陷阱，在开发单页应用中都存在，无论使用什么框架。有时框架能自动处理这些问题，这是要求开发代码完全按照框架规范来写作为前提的。比如带有数据绑定的框架就要求不要程序操作 DOM，而完全依赖 MVC。

换到 Turbolinks 环境中，一样是要遵守注意事项，理解 Turbolinks 开启状态下的 JS 运行周期。持久运行的网页客户端是目前的趋势，从现在开始了解单页 JS 的陷阱对个人发展是有益的。

不要过度追求纯洁性

“把前端的事留在前端”，我能理解这种情怀，我自己也有这种洁癖。但这就像”面向对象语言代码一定要面向对象”一样，过于执着而拒绝会错过一些好事情，现在面向对象语言也会引入函数式编程。

Twitter 是重客户端应用和 API 的典范，很多人都期待以后写网站可以跟 Twitter 一样，服务端只提供 API，网页和移动设备都调用同一套 API。但是 Twitter 去年5月做了一件事：

To improve the twitter.com experience for everyone, we’ve been working to take back control of our front-end performance by moving the rendering to the server.

现在用浏览器调试工具去看，会发现 Twitter 请求的数据是 JSON 包裹的 HTML。 

为了提升网站/应用的体验，应该试着用不同的方案处理，不止一种方法去做一件事。Turbolinks 是个新想法，不妨保持开放心态去看待，它至少有一个成功的应用：Basecamp。

结语

最后要说的是，我不拒绝客户端 MVC。我已经计划在下一个网站功能开发里用到客户端 MVC，这个功能需要比较多的客户端交互。到时 writings.io 会是一个混合的前端方案，换页用 Turbolinks，特定功能用客户端 MVC 做组件。

未来我还可能用纯客户端 MVC 做一个离线应用，但这比较遥远。

如果有一天 Turbolinks 无法承受新的挑战了，那么我希望自己已经摸到了它的边界，这对开发更好的 Web 应用是有帮助的。

原文地址：http://blog.chloerei.com/articles/35-turbolinks-is-not-bad