有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。
这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。
Real-World Realtime with Backbone by Henrik Joreteg
Links
Notes
这是一个非常酷的Talk，节奏紧张，华丽。
Backbone makes doing that (build complex stuff with javascript) cleaner and more fun!
Single-page app && Realtime app?
如果你是一个Javascript developer，你早晚会接到这样一份工作的。
作者的公司叫做&yet，他们做了很多实时应用。他们当然走过很多弯路，罄竹难书呀~
那么如何定义实时应用呢？他们的定义就是”Push not poll”……这虽然比较tricky，不过在http模型下这是接近realtime的关键。
那么，他们不使用Backbone.sync支持的这些被动的fetch（因为这样是pull，模型就会是polling）。
他们使用了socket.io，所以可以socket.on(‘someEvent’, do something)了。
不过没有了sync，Backbone还剩啥？
一般实时应用的流程是：
- Auth / Connect
- 获取初始化数据
- subscribe一些事件的更新
- 调用服务器上面的一些 RPC或者script
他们的例子是一个实时的地图应用：https://go.recondynamics.com
然后，他提出了一个被众人热烈鼓掌的Slogan：
“State duplication is EVIL”
Henrik（@henrikjoreteg）曾经推过：
“In a big single-page JS app, how far should I go to store all state in outside of the DOM? For example, checkboxes are stateful by design.”
Jeremy Ashkenas（@jashkenas）回复：
“In my opinion, precisely zero state should be stored in the DOM. What if you have more than a single checkbox for the option?”
Backbone正是在这种思想下产生的，Model是single truth of page。
实时应用的传输的方式有很多选择，传输过来的东西都是修改Model状态的就好。也就是说Backbone.js的应用如果写的好，转到实时会是很简单的事情。因为大家都围绕Model进行操作（传输Model，用户交互，服务器事件修改Model），所有的其它组件监听Model的event消费Model的数据就可以了。
所以，作者推荐要早一点重构、经常重构、更好的重构。
不过，这样说做实时应用就太没有挑战了。实际上主要的挑战是timing的控制、Event相关性（前端后端、各个系统）、UI组件复杂，系统的Event和Model之间没有关联…… 所以实际上实时应用的挑战还是很大的。
那么为什么不去用一个实时Web应用框架呢？如：SocketStream、Derby.js、Meteor.js、Capsule.js
这些框架都承诺了很多：
- 共享前后端代码
- 前后端无缝的状态控制
- 自动更新的模板
- 自动的冲突解决
- 热部署
听起来很Cool，不是真的有那么 Practicool（实际上有那么酷）？
作者解释了他们尝试在Node.js上面通过Socket.io共享Backbone.js Model的尝试，结果是失败的：
- It’s hard to manage data (Backbone Model)
- Very little structure (Backbone Model)
- It makes partial sync state hard
- Very good for prototyping
- Backbone isn’t a great way to define your data schema
- Benefits from code sharing were minimal (On server/client model sharing, that’s so true)
然后作者介绍了他们尝试Backbone.js（前端）配合Capsule和Thoonk的实时应用架构。Backbone.js在后端完全不存在了，前后端没有任何共享代码。
因为服务器端和客户端处理的问题其实是不同的，所以应该使用不同的解决方案，不共享Code。
最重要的原因是 Security！！！
然后整个会议上面最重要的一个Slogan出现：
Sharing code is cool.
Sharing underwear?
Not so much.
也就是著名的在服务器端和客户端共享代码就好比共享内裤一样……
因为数据和传输（接口，或者按照REST的说法，那叫视图）是应该独立的。否则，当你需要不同的视图的时候，会更加灵活。
作者提出了在Backbone.js实现实时应用时候遇到的一些问题，希望大家帮忙找到更好的解决方案，wishlist：
- 清晰区分传输的app状态，和View端的app状态
- unbind view，也就是view destroy，也就是View生命周期的那个问题
