为什么我们不用 Angular, Ember 或者 Backbone！

Muut 是一个特殊的论坛平台，它也有着巨大的梦想！ 当后端的性能已经极大优化的同时，前端也有着自己的目标：简单API，小体积，快速迭代。写代码就像在纸上先起个草稿，然后写入到许多文件中即可（猜 译）。任何一个前端框架，比如，Angular 或者 Ember 都没问题！

下面是我们自己实现，而不用它们的原因。

首先是 API 方面的因素

开发 Muut 客户端时，我们基本的要求是简单的 API。它必须易用，没有额外的属性方法，不应该提供新的编程习惯（即不要制造另类的代码语法）。它应该易上手。不仅最终用户用它，而且个人也要用它，因为所有的网页界面都建立在它之上。

开始设计API之前，通常要先打好草稿。一个干净的桌子、一支笔、一张纸。我开始站在使用者角度构思API。从没有一切框架开始。

API 在 MVC 中是一个模块，要用 POJO（Plain Old JavaScript Object） 的形式。因为框架提倡API的设计必须"single source of truth“。API不仅能跑在浏览器上，也能在后端（node.js）执行。它必须完全独立且易单元测试。

我不喜欢交差相关的方法及属性把API搞杂乱。Backbone.Model.extend 和 Em.Object.extend 都添加了大量的方法，给用户使用增加了复杂度。违背简单的目标，它不被我们接受！

小体积

更小的文件会更快加载，节省带宽。这是看得见的利益。更大的优势就是代码维护。小代码更容易把握，更快学会，更少的条条框框。

目前 Muut 客户端压缩后是 89kb，gzipped压缩后是 32kb。这比其它的论坛平台要小10 倍。体积明显很重要，当一半的网络访问来自于移动设备，开发人员就会寻找小工具来完成他们的工作。

下面的表会让你知道，我们使用的具有独立功能的工具应该是多大的体积。下面列的是我也在使用的，我正好做一下对比，以下均是minified后的大小：

在实际的项目开始之前，这些大概就已经有150kb了。

当前，Muut的包含界面视图、控制器（api与视图之间的结合代码）等合并后再minified，仅40kb。一个框架应该是多大呢？框架的目标是更小的工作量去达到目标，所以它应该很小。40 kb是容易管理并继续在之上进行开发。在事情复杂化之前，我还可以增加大量功能。

全面掌控

Muut 使用原生的 pushState 方法来控制URLs,John Resig‘s "微模版" (6) 来显示视图，内部的模型与视图的交互使用自定义事件。而不使用路由及自动数据绑定的功能。

每个事情都完全按照我们预期的执行，出现bug也容易找到。这里没有不可知的，不明道理的代码。这里没有秘密，并且调用堆栈也很浅。我们可以针对特殊需要而去组织代码，而这里没有固定的框架来控制必须如何做。

不混合编程样式

没有外部包更新

没有这依赖hell

每周都能愉快发布新版本！

特殊需求

Muut客户端只是一个包含全部HTML代码的JavaScript文件。当文件加载后它会在一个单独的anchor(A)标签中渲染自己。项目的打包与启动与传统的单页面程序有很大不同。

Muut服务端必须能够随时通知客户端。客户端与服务端以一种点对点的双向模式进行通信。

我们通过WebSocket发送JSON-RPC消息，而不会考滤使用REST：像Muut这种实时程序不能构建在REST之上，因为REST所采用的是一种请求-响应模式并且它不能理解push事件等东西。

现在的框架，例如ember数据，是面向REST的，并且它们的示例和文档也是基于REST的。WebSocket示例有遗漏，或只是试验性的。Muut所面临的挑战是很独特的。

技术锁定

如果你查看了任何编程语言的框架史你会发现它也是一部失败史。框架来了又走了。今天的JavaScript框架都很年轻。Backbone, Angular和Ember现在可能很流行，但几年后就不一定了。

我们来看下Angular (蓝), Backbone (黄) 和 Ember (红)的Goole Trends（谷歌公司的一项搜索产品） (2):

JavaScript是世界上最流行的编程语言，并且提供了多种编程风格。但事物也在以一种不可思议的速度变化着。因此使愤怒的框架社区不断推翻曾经最好的应用构建方式。

没有最好的方式.

有许多不同的替代方式,目前Angular正处于巨大的增长之中. "AngularJS允许你的应用程序拓展HTML." 这是最好的方式吗? Backbone和Ember是否正处于危险的境地?2012年在X框架中有所投入的公司,可能马上会意识到,他们的开发团队已经在谈论下一个新技术了.作为使用这些框架其中之一的开发者,我担心他们的生命周期.

另一方面,让我们来比较一下jQuery和Angular (3):

上面的图告诉了你jQuery的普及程度.它正在全世界57.2%的网站中使用,其中92.7%的网站的JavaScript库是公开的. (4) 这里没有技术限制.但是作为一个嵌入式应用程序,我们不能期望人们,在已经使用jQuery的网站中,加载其他的框架.

Muut使用了jQuery的全部内容,在设计API的时候,我甚至偷师jQuery.它很简洁好用.我(依旧)喜欢这点.

为什么不用 Angular？

Angular 看起来是很有前途的。表面上，我可以用原生的js写我的模型，让Angular去渲染到视图上，且不需要任何胶水代码，这看起来非常棒！但有一系列原因让我不喜欢这个框架。

首先，它和Muut一样的大小（91kb).但我只想要双向数据绑定而已，我被迫加载整个框架。它为我提供过多东西。我希望他们单独做一个数据绑定的模块，让它更简单即可。人们也不需要关心内在的实现机制，比如$watch, $apply 及$digest。

尽管它标榜自己是很简单，但它的API是非常大的。目前它们的文档中边栏竟有147节内容。那需要麻烦的理解认识过程。我只需要一张空桌子来构建我的工作。

另外，我真的不喜欢把这么多的逻辑放到视图中或把我的代码包装后，放到"directives" or "filters"中去.Muut的逻辑只有适当的复杂度，最好用原生的JavaScript就能表达。

为什么不用 Ember.js?

Ember 是庞大的，恩，就是非常大！minified后的库大小也是240kb.不用说，它们的API也是庞大的。我从它们的文档的第一节（Modules > Ember）看，只这一节便有80个二级节点。

我最不能接受的是，我必须把我写的对象用Ember.Object来包装才能引入API中的方法。

一个大框架使用大量的特有语法是一个冒险的选择，想想 Enterprise Java Beans吧！

为什么不用 Backbone.js?

Backbone 在三个中，最小最简单的框架，minified后大小是33.9kb。它必须依赖 underscore.js库，这样它就大于Muut一半的大小了。

我用Backbone的问题是：我不喜欢Backbone组织代码的方式。它有太多的样版，但我喜欢更喜欢写出简洁紧凑的代码。我完全认同它把API代码与UI代码分离的观点，但 Kim Joar Bekkelund的关于把jQuery代码转到Backbone的文章对我毫无意义。对我而言，很难去用它的代码。

与Ember一样，Backbone不能用POJO‘s，所以你必须用Backbone.Model.extend来包装你的对象，引入也不必要的框架定义的方法。

在以上面个框架中，Backbone最最保守选择，它不给你做什么看不见的工作（Magic），甚至即使它停止开发，你还可以用自己的代码去打补丁或替换掉它的代码。

最后，作为一个RESTful的框架，它并不能完美地适于于实时通讯的地方。

但jQuery正在变成意大利面,是吗?

通常的论题是,在应用程序中堆叠了成千上万行代码后,jQuery地狱将会爆发.这个应用程序没有结构,代码也是一团糟.这并不正确.当API完全从其他代码中剥离出来的时候,利用jQuery很容易构建控制器.

通常,我的控制器代码像下面这样:

这就是我个人组织代码的方式.Web应用程序的目标不应该必须限定在DOM,或者面向对象的实践,或者纯MVC模式.一个成功的应用程序应该保持简单,而不要陷入学术化的怪圈.

总结

正是我们结合了完美主义和极简主义， Muut是一个极轻量，易管理，和独立的Web应用集合。 与“从头构建”的方式一致，它适用于我们的服务器侧代码和UX，如果不是在几年前，能力高超的团队和许多的人有相同的想法，你就不会看到类似讨论平台的出现。

下一个博客条目: Riot.js – the "1kb MVP library" Muut客户端的背后.

相关链接

[1] Mobile usage vs PC usage

[2] Google trends for Angular, Ember and Backbone

[3] Google trends for Angular and jQuery

[4] 57.2% of all websites use jQuery

[5] Step by step from jQuery to Backbone

[6] Micro Templating

[转载]JavaScript 的轻框架开发