Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

这一个 Post 是所有 Talk 所做的笔记的索引。

第一日的话题

每个 Talk 我都做了比较详细笔记，下面是链接，请点开查看：

• #BackboneConf2012 Keynote for BackboneConf by Jeremy Ashkenas
• #BackboneConf2012 Ember.js by Yehuda Katz
• #BackboneConf2012 How to Argue about Javascript by Andrew Dupont
• #BackboneConf2012 MVC Module Magic (through require.js) by Alex Sexton-
• #BackboneConf2012 Testability in Mind by Vojta Jina
• #BackboneConf2012 New Dog, Old Tricks by Rebecca Murphey

第一日话题后的酒会

第一天的内容就结束了，当天的酒会很成功。很多前端程序员都是Beer geek或者Scotch geek。

就会上逮到了 Jeremy 本人，我记得趁着酒劲我问了几个问题：

• 您这代码都怎么写出来的？您有没有TDD呀？ Jeremy 说我一般不写测试，不过为了保证质量，他会补充一些测试。他说我就是 write codes which make sense ……好的，Make sense是对直觉型程序员常说的。彪悍是不需要解释的。
• 您平常也看别人的开源项目获取灵感么？您如何平衡写自己的东西和看别人的东西？ Jeremy说，啥？我写代码那是为了糊口，看别人的代码那不挣钱呀。所以我一般不怎么看别人的东西，我就写我自己的东西，我觉得 make sense 的东西，当然要写的 make sense ……
• 我还问了一些问题，酒劲比较大，我忘记了

第二日的话题

每个 Talk 我都做了比较详细笔记，下面是链接，请点开查看：

• #BackboneConf2012 Lumbar Support by Brad Dunbar
• #BackboneConf2012 Migrating a Large Project to Backbone.js by Sam Clay
• #BackboneConf2012 Real-World Realtime with Backbone by Henrik Joreteg
• #BackboneConf2012 Airbnb’s Journey Into Mobile Web by Harrison Shoff
• #BackboneConf2012 Y.App: Coordinating URL Navigation, Routing, and Managing Views by Eric Ferraiuolo
• #BackboneConf2012 The Plight of Pinocchio: JavaScript’s quest to become a real language by Brandon Keepers

第二日话题后的论坛

我去，第二天最重要的是一个Panel，不过非常倒霉，我的飞机不允许我听完全部。

参与Panel的有：Jeremy Ashkanas、Yehuda Katz、Vojta Jina、Eric Ferraiuolo、Andrew Dupont
主题是Javascript’s Future

主持（@BoazSender）很弱，问了一堆很弱的问题。

我记得的一些点是：

• 所有人都同意框架不是作者凭空想出来的，都是他们把实际交付的项目的代码中可以复用的部分抽出的结果。也就是说成功的框架都不是为了写一个框架而写出来的，而是为了解决某一种实际问题的解决方案。所以停止根据某个灵感而发明一种框架这种想法了。
• Yehuda Katz 很擅长吵架，死磕 Jeremy ……（@wycats says he agrees with @jashkenas in principle, but he thinks it’s been taken to a place that neither of them like）
• Jeremy 强调了 Node.js 社区烦的一个错误。Javascript 是为浏览器而生，并且繁荣的。所以 Node.js 的 Javascript 应该尽量兼容在浏览器里面可以运行，尤其是一些通用的工具库最好不要忘记浏览器。
• Jeremy 承认 CoffeeScript 是有人喜欢有人恨，但是它最杰出的地方就是真正影响了 Javascript 下一版本的语法。开发者有权决定自己用什么，只要他觉得自己的工具 make sense 就可以了。
• Jeremy 认为 HTML 并非为application设计，所以HTML的元模型并不完全匹配application，这是个未解决的问题
• 我们应该如何选择框架呢？研究所有的框架找到你要的，还是学好一个框架并使用下去。因为框架是作者的美学取舍的结果，这是不好评价的。Yehuda说应该看api的数量和它能做的事情的比率，api数量大做不了事情的东西是不好的。Jeremy说傻X才写那样的框架呢。
• 如何区分框架和库呢？”a framework calls you, you call a library” 这是 Jeremy 和 Vojta 的答案。

大家可以看 @knowtheory 的 twitter ，在5月31和6月1两天有很多tweets报道 #backboneconf

BTW: Beer

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

The Plight of Pinocchio: JavaScript’s quest to become a real language by Brandon Keepers

Links

• Slides

Notes

这为是 Github 的前端工程师。

不好意思，这个话题的时候我实在坚持不住，一直在打瞌睡和惊醒间切换。

If we are going to use JavaScript to do real work, then we have to do the things that we do with real languages.

这就包括这些Buzz word：抽象、TDD、关注点分离、DRY、重构、解耦、设计模式、封装……

目的是可维护和容易扩展。

然后作者开始演示哪些设计模式有意义（着重介绍 MVC ），重构，DDD，并且 TDD 这个过程。

Test driven development is a design process. （我深表同意，不过最近连 Dan North 也就是 BDD 作者都来拆台）

整个 Slides 还是很好的，充满了各种重构的例子，使用 jasmine 写的测试。

不过真正有趣的部分出现在 Q&A 阶段：

某人站起来问 @bkeepers 请问 Github 是如何测试（人家没问如何TDD）的呢？

然后 @bkeepers 说一线的代码不是我写的，然后叫了现场的一个 Github 同事回答这个问题。然后他的同事非常尴尬的站起来很不好意思的说：”大哥，咱 Github 不写测试的“……全场哄笑。

然后 @bkeepers 笑着说：“看我回去教这帮坏小子如何写测试去……”

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Y.App: Coordinating URL Navigation, Routing, and Managing Views by Eric Ferraiuolo

Links

• Slides

Notes

这个哥们是YUI团队的，推荐大家 Follow （@ericf），非常有见解。

他整个话题的核心问题是URLs，是很讲究的地方：

• http://example.com/foo/
• http://example.com/#/foo/
• http://example.com/#!/foo/

这是个争论的地方，也就是著名的 hash bang (ref Backbone.js: From Hashbangs to HTML5 PushState)。很多人都表示 #! 是很讨厌的东西，它让妨碍了对于数据（视图）的直接访问。因为 hash 的语义不是 path。

但是很多人会提出一个真正的问题，如果只做了一个 single-paged app，但是如果你部署在一个 Dumb server（只能服务静态文件的服务器）怎么办？这种情况下你只能使用 hash url 了。

Hash Bang 问题的另外一个核心是初始状态的问题，也就是第一次 http 传输给用户的内容。传统的 hash bang 只返回静态页面，ajax call 再去取 hash 对应的 data 进行渲染。也就是说初始化的数据是不完备的，需要更多的 http 请求才给用户传输了真正有意义的内容。

所以，最好预先把数据在服务器端渲染好，直接传输给用户。减少 http 请求对于 mobile 用户就更加重要了，因为 Radio (手机无线数据连接) 的省电算法，还有无线数据传输通道建立的延迟达到数秒，http 传输的额外开销（延迟）非常恐怖。这就显得更加重要。这也就是为什么最近 Twitter 写了一个博客说他们已经改为预先在服务器端渲染好 Twitter 而不使用客户端模板引擎去渲染了。Twitter 放弃 hash bang 以后第一次数据载入的快了5倍！

而且，用渐进增强的思路，使用传统的页面预先渲染（URL 转换页面）的模型很容易使用 pjax+pushState 增强。比如 github 就是用这种方式实现的，它结合了 ajax 的保持当前页面状态（减少 parse 和初始化事件，不需要重新载入整个页面）、局部更新等很多好处，给用户的感觉就是快。而且 URL 上面它保留了每个页面 path 的可访问性。

pjax就是截获了 <a> 元素的点击事件，这是完全渐进增强的。

还有一个好处就是你可以控制页面 cache，页面局部缓存，返回可以变得很快（没有 http 请求）。

但是，这里还有一个分裂：

/foo/ 和 /#/foo/

如何统一两种风格呢？（这样无论是否是 dumb server 都可以让你的 app 正常运行，在可以不用hash的场合使用更好的 path 取代 hash）

你需要一个更强的客户端 Route Handler，作者的 Y.App（包括 Y.PjaxBase、Y.Router、Y.View）是个例子……余下就是 Y.app 的一段 demo，也算广告。

这个话题非常好，因为它解决了 Hash bang 的争论，我们是应该让 Web 的最基本的 hypelink 不被破坏，应该正确的使用 URL 的语义。但是我们也应该用渐进增强的思想利用我们强大的前端的状态管理功能，让 Router 来处理初始状态的导航和组装。

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Airbnb’s Journey Into Mobile Web by Harrison Shoff

Links

• Slides

Notes

注意，作者不是所谓的前端工程师，而是前端设计师（作者自称doodler）！！！设计师也可以用好Backbone.js的。

Airbnb是个很酷的东西，团队也很酷。他们的基础设施几乎完全基于Amazon的云服务。
Server放EC2，负载均衡用ELB，Hadoop用EMR，存储用S3，数据库用RDS，监控用CloudWatch，Cache用Elasticache

他们的前端是CoffeeScript + SASS + Backbone.js

这个项目比较有趣，因为他们的mobile website很丑，所以他们决定在他们的主力前端休假的时候由作者这个半吊子前端重写这个很独立的mobile website。实际上他们有10%的流量到那个很丑陋的网站。

他们准备在6周内（新年前）完成这个项目。项目的两个人完全没有做Mobile website的经验。然后他们碰巧看到了Backbone.js和coffeescript，看起来不错就用了。你看……不较真的人多好，运气好就能选对东西。

然后，你就会惊讶到做好一个产品是在是很看人的，他们的设计过程非常棒……请参看slides

具体的技术内容都是大路货，就不赘述了。这个例子很好，首先是从无到有如何用好Backbone.js。其次是如何在秘密飞行模式再公司内部做一个Startup工程，还有如何画原型如何自己写代码做好一个产品。最重要的是，一个设计的靠谱的UX流程对于交付一个好的产品是多么重要。

Backbone Conf 2012

有幸去美国波士顿参加了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

• Slides

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生命周期的那个问题

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Migrating a Large Project to Backbone.js by Sam Clay

Links

• Slides

Notes

Sam Clay是Jeremy的同事，是DocumentCloud的前雇员。
他的项目叫NewsBlur，是一个开源的Web版RSS阅读器。他展示了一些不错的工具，展示了一个阅读器上面的UI Widget是如何映射到Backbone View的。他正在把这个“遗留”项目用Backbone.js重写。

他描述了如何在不Break原来代码的情况下渐进的讲一个非Backbone项目用Backbone重构。

迁移routers。将所有和url打交道的部分用router管理起来，可以有多个router。
迁移Model。可能需要对服务器api做versioning（就是?v2返回不同的结果）。迁移代码的时候可以将model.attributes未改写的方法，这样迁移比较平滑。使用{silent: yes}初始化，手动触发model的change方法。
迁移Views。主要的改变是讲event binding改为event delegating。作者比较喜欢将View拆成粒度比较细的sub views，里面比较有趣的是提到了View collections的概念。

作者提醒这个错误很常见：

TypeError: ‘undefined’ is not an object (evaluating ‘func.bind’)

这个东西是由于想要绑定一个不存在的方法……（如_.bindAll）

另外一个得到共鸣的问题是ghost view的问题，也就是绑定了方法的view的element被删除或者被复用后，原先绑定的方法会带来不可知的影响。这个也是Backbone.js目前正在努力解决的地方，增加View的生命周期管理能力（destroy method）。

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Lumbar Support by Brad Dunbar

Links

• Slides

Notes

这个标题是个隐喻。脊椎不爽需要腰部支撑！

作者来自pathable，他们的 github

Dos and Don’ts

• Don’t reference elements by class
• Do use data attributes
• Don’t replace elements
• Do use existing dom elements
• Don’t specify tagname
• Don’t reuse views
• Do reuse do elements (safely)
• Do be careful with innerhtml
• Don’t _.bindall
• Do use envent contexts
• Do destroy views
• Do wrap router#route
• Do keep route handlers simple
• Do wrap backbone.sync
• Don’t prevent consistent events
• Do use custom options
• Don’t use mutable attributes
• Do fire custom dom events
• Do whitelist

重点是SuperModel.js

• Track Unique Models
• Maintain Model Relationships
• pathable.github.com/supermodel

很不错的扩展

他推荐了HTML semantics and front end architecture这篇文章，作者是Nicolas Gallagher

还有kinetic.js（注意有一个同名的Canvas library，不是那个。这个库也是Pathable的，不过暂时还没有开源。）

• Testable (isolated) views
• HTML interface
• Render/Cleanup Conventions

看起来像Vaporware……

作者 @braddunbar ，他说话不太清楚，不过他的库显然挺不错的。

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

New Dog, Old Tricks (Or: Dojo Already Did That) ( Or: Integrating Dojo concepts into Backbone.js ) by Rebecca Murphey

Links

• Slides

Notes

演讲者是一位女性，我记得是那两天唯一的一位，非常值得尊敬。她是bocoup的JS dev，之前做过咨询工作。

作者是Dojo的一位资深用户（2年），使用Backbone.js几个月。

由于Dojo的沉重的口碑，所以看出大家都不怎么感兴趣。不过说实话这个Talk还是不错的。

作者举了Dojo的基于Widget的例子，可以看到模板和View的绑定还是比较厉害（虽然模板引擎比较容易替换）。但是Backbone.js讨好的地方就在于它强调了Model的核心作用（Single truth，Domain Driven Design），但是Backbone.js的模板是空的，这点让作者很怀念Dojo方便的widget。

主旨就是很多人都发现Backbone.js里面View没有生命周期管理，所以很多人都觉得View的依赖清理（unbind）工作非常头大。不过这些东西在dojo里面都很好的解决了，而且dojo还有widget框架dijit，解决了布局、View依赖、View声明周期等众多问题。

Rebecca讲了它觉得Dojo有，但是Backbone没有的东西，她的SuperView帮助解决了这几个问题（提供一些rails）

• rendering: serializing, template, placing
• binding: memory-safe setup & teardown
• lifecycle: react when things happen

Dojo在很久以前就有Module机制，这个是很超前的。

这个话题本身当然是Backbone.js相关的，基于Rebecca写的一个Demo项目：https://github.com/rmurphey/srchr-demo

这个小项目写的很好，展示了如何写一个Backbone.js应用，并且借鉴Dojo的一些已有的模式。其中她主要战士的是SuperView这部分，定义了一些声明周期，使用它来解决View的依赖关系。

SuperView的代码docco注视版本

这个Slides涉及到的一些链接

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

Angular.js – Testability in Mind by Vojta Jina

Links

• Slides

Notes

Vojta Jina 来自Google，所以这个框架也很有google风格。

Angular.js 是一个很有特点的框架，很不同。

提供双向数据绑定。

最有特点的是“依赖注入”，你没有听错，这个在Java社区几乎尽人皆知的东西。Angular.js使用的是编译期依赖注入来实现它的“黑魔法”。

依赖注入其实是一个不错的东西，因为双向数据绑定的时候代码需要做很多wiring的工作，进行编译期增强可以让源代码看起来可读、简单。它进行了默认的基于名字的wiring，也可以用其它方式wiring（待求证）。

目前双向数据绑定的MVWTF框架都在模板上下功夫，和ember.js类似，你可以在模板里面绑定model的属性和事件，模板本身声明了model和View的动态依赖。而且和ember.js类似，它都使用了dirty check的方法解决事件风暴带来的UI过于频繁的更新，作者说实现的思路几乎都是定时的dirty check然后更新stale的部分。

很有趣的是作者的Demo非常酷，完全的TDD，非常流畅。前面三个Talk让现场的很多人惊叹Live coding是目前好的会议的一个重要组成部分。

Backbone Conf 2012

有幸去美国波士顿参加了2012年的 Backbone.js Conference，见到了coffeescript、underscore.js 还有 backbone.js 的作者 Jeremy Ashkenas。会议内容围绕前端MVWTF和社区进行了很多有趣的讨论，有很多有价值的观点。我希望在这里面与大家分享我从里面学到的东西。

这系列博客其实是我整理的会议笔记的汇总，是我对每个话题中比较有印象或者比较重要的内容的摘抄，这些观点几乎都不是我的，我仅作为一个传声者。我是希望把所有的Credit交给演讲者自己，我最多只是一个翻译者，碰巧幸运的在现场。Backbone.js Conference和O’Reilly的Fluent Conference 碰巧同时进行，#BackboneConf 更加草根，但是也更有观点。

MVC Module Magic (through require.js) by Alex Sexton

副标题APP structurizer, build easifier, and middleware magician

Links

• Slides

Notes

Sexton这个姓很有趣吧？他在Slides里面提到了MVWTF这个叫法，满场大笑。这个说法就是Controller还是Router还是Whatever都没关系，大家都统一MV应该是大部分逻辑的所在就对了。

Module是很多语言内置的特性，实际上就是一个返回对象的函数。难点是如何设计一个nice和neat的api。Module可以帮助你整理/分解你的系统。因为大家认为把相关的内容放在一起可以帮助你的大脑在更小的上下文中工作，让你的大脑工作的更高效（但是上下文也可以理解为一个视图，也许有其它更好的方法解决它，如Kickstarter上面Chris Granger正在实现的Light Table。不过分开的文件起码在目前的Cmd+T支持下非常好用）。有个曾经流行过的词形容Module，那就是“关注点分离”。

由于MVWTF是关注点分离，Module系统可以说是为了代码复用和关注点分离而存在，所以两者简直就是天生的一对。

Alex举的例子是如何组织一个项目的Module结构，能否每个model或者每个view是一个单独的js文件？这样的好处是报错的时候可以直接跟踪到某个文件的某一行，而不会对package过的assets的行号搞晕。Module里面声明依赖的好处是可以按需下载，如果没有需要的时候不会去解析额外的内容。当然，你还可以给module加alias，这样就可以简单的替换掉一个库的依赖（如lodash替代underscore）。

template也是一种依赖，把他们作为dom元素夹带document里面不能cache。作为类似Module的依赖可以带来性能提升。所以有了text!的前缀（不会被eval，只作为string返回）。style也是一种依赖，它可以作为template的依赖，还有其它以文本形式存在的依赖。

Alex原话

“I prefer AMD and I specifically use RequireJS. I think it’s the best solution for modules on the web that we currently have.”

AMD嘛……Async，The web is ASYNC

AMD包会改变一个Module的声明语法，所以如果不愿意直接修改你的源文件，那么完全可以加入一个编译任务来生成AMD兼容的文件。当然，这只是可以……后面有更好的方法

当然，社区里面关于AMD有很多的FUD（绝对比分号之争要鲜明，很多人明确表示AMD的语法太二而不愿意改变），Alex尽力解释了其实它的语法挺简洁的（比Node.js的require）。

然后Alex介绍了重头的Use.js，它是一个帮助使用AMD的语法引用不兼容AMD的Module的工具。这样就不需要强制人家把自己的库修改为AMD兼容的方式（对于非AMD环境不可用），或者fork一个AMD版本的库一直跟着原来库的发布（这是非常非常二的做法，后患无穷！）。其实这个工具就是动态的注入了AMD需要的前面和后面的那一丁点wrapper js code。

Plugins是在return object之前动态修改的一个机制。

Plugins是一种很好的思路：可以动态修改不支持AMD的代码，可以动态增加依赖（如template依赖于handlebar，自动插入这个依赖），自动预先编译template（这个需要 build process帮助），注入检查点或者编译期优化什么的，可以自动分析template依赖的css，可以自动inline css和images，可以动态删除用不到的代码（根据某些runtime变量的状态决定，has.js）。最终的目的甚至包括直接把整个应用的依赖变成一个单一请求发出去（当然服务器也要支持对这个请求做响应）。

透明的预编译操作包括：

• templates
• i18n
• i18n in templates
• configurable apps
• multi-profile apps
• coffeescript
• less.js or sass or jade or what ever

这些预编译和运行时优化帮助提升编码者的体验，在预编译阶段可以为浏览器和其它环境做动态适配。

作者总结用Require.js的主要好处（这里其实主要指的是plugins机制）：Happiness, Speed, Modularity, Magic

作者后来被问到Require.js会增加http请求对于mobile web怎么办的问题。Alex说在最终部署的时候是要有真正的预编译阶段的。这和Rails的asset pipeline是类似的，在开发的时候方便看到到底是哪个文件的哪一行有问题，但是部署的时候可以通过预编译减少请求。

另外一个问题是Module切分的粒度的问题。Module如果划分的比较细的时候依赖的声明会非常长，比较靠谱的解决方法是通过plugins进行动态注入依赖。但是多个相关的文件被分在不同的Module并主动声明依赖的时候需要平衡这个粒度问题，这是个个人问题，不过由于粒度不容易掌握暂时还是一个没有定论的问题。现场很多大牛表示自己的项目切分的粒度比较粗，这样不需要在不同的文件中跳来跳去，而且强依赖的逻辑块放在一个文件暂时还是天经地义的。