虚拟座谈会：实际应用中的JavaScript MVC框架

Matteo Pagliazzi ： Angular是时下最火爆的框架，这不仅仅是因为它在GitHub上所获得的星的数目，而在于它的库与模块的数量是最多的……许多开发者都在谈论它（同时也在使用它）。很显然，我们开发者都非常喜爱它。我想，这是因为它非常容易上手，只需5分钟时间就能够完成一些复杂的功能，同时它也非常强大。而当你从基础知识开始一路学到框架的核心时，整个学习曲线逐渐开始变得陡峭，最终会发现它是非常复杂的。

Julien Knebel ： 我使用Ember.js进行开发已经超过两年了，并且已应用在五个生产环境中的web app中。我认为它为我带来了灵活性、速度以及信心，因此我可以专注于改善整个用户体验，而不是将大把时间用于研究一些非常复杂的特性，例如一个健壮的异步路由功能。

Brad Dunbar ： 我最喜爱的是Backbone，它所提供的简易性和灵活性是独一无二的。此外，或许更重要的一点在于，它的代码通常是十分简单易读的。

John Munsch ： 我最喜爱的框架是AngularJS，我使用它刚刚超过一年，可以说我们还处在蜜月期之中。

我所需要的前端框架能够帮助我解决的最根本问题在于，它能够为我提供足够的基本元素，就像是人体的骨骼与精气，并将它们融合在一起，帮助我打造出一个复杂的前端UI。它不仅能够实现过去我们使用后端的基于请求/响应的框架，例如JSP、PHP、Rails等等所能够完成的功能，并且还要更胜一筹。

Julio Cesar Ody ： 我最常用的是Backbone，不过现在也越来越多地使用React.js以代替Backbone中的视图功能。

我所创建的所有web应用都是完全运行在浏览器上，并通过API或WebSocket与服务端进行交互的。这意味着有大量的逻辑最终是由JavaScript编写的，因此Backbone使我能够让整个工作更有序、可维护性更好。

Thomas Davis ： 我首次接触到正规的JavaScript MVC框架还是在2010年下半年，当时我决定使用Backbone.js和Sproutcore。随后我写了一篇关于这些框架的比较的帖子，结果它上了Hacker News的头版，并且获得了超过10万条点击量。根据当时的反馈，我决定使用Backbone.js，因为它是最小型的框架，而且在实现复杂的功能时也不会受限于大型框架中所规定的条条框框。在我学习Backbone.js的过程中，我也编写了一些教程，通过这种方式让自己对这个框架的理解更扎实。这些帖子已经有了过百万的点击量，现在还在继续增长。目前可以在 backbonetutorials.com 上找到这些帖子的存档。

对于当下的产品来说，用户体验及设计的重要性不亚于保持网站的始终可用。单一页面应用能够实现传统的页面无法带来的优秀用户体验，因为后者强迫页面刷新，举例来说，想象一下在使用Facebook的时候，每次点赞和留言都迫使你刷新页面会是一种什么样的体验？

Julien Knebel ： Ember.js的功能十分出色！我完全没想到，它能够让我几乎以一己之力完成整个网站的编码。当然Angular也非常优秀，我特别中意的一点在于它能够让我很快上手并运行代码，但我相信，随着代码量的增长，会出现代码越来越冗长的问题。相比之下，Ember在上手时遇到的困难更多一些，但通过在学习过程中不断地领悟，这些困难就如积雪在日照之下逐渐融化了。它的另一个重点（至少对我而言）在于“组件化”，我不喜欢Angular directive处理这一点的方式，而我明显感觉到Ember组件的实现方式是正确的。

Brad Dunbar ： 我很难找到其它任何一个JavaScript库能够像Backbone一样精准地符合我的应用的所有需求，因此我总是倾向于使用Backbone编写应用。Backbone功能是小型化的，它所提供的功能能够让我方便地进行组合，而没有提供那些我实际并不需要的大型功能。

John Munsch ： 这个问题有点难以回答，我的经验仅限于Backbone.js（也只有不到两年的经验）以及AngularJS（刚刚超过一年）。不过在这两者之间做出一个选择对我来说完全没有困难。

Backbone.js还算不错，但在我们目前的一个大型项目中使用它的过程中，最多时足足投入了六个人进行开发。我们所遇到的问题在于Backbone.js中所缺少的功能必须由其它软件进行填补（双向绑定、校验、模板、AMD等等）。如果在编码启动之前没有找到适合自己的方案以填补这些功能缺失，那么小组中的每个成员最终不得不自己想办法实现它们。如果你的开发时间很紧因而必须快速地编写代码，那么就很难找到所有的分歧，并在某种程度上强制实施一致性。

我们最终开发出了一个可以运行的项目，它的速度比旧的方案快得多。但它看上去就像是一个喀迈拉女怪（狮头羊身蛇尾），每一部分单独看上去都是一种不同的动物。而AngularJS的框架本身就实现了这些功能中的很大部分，因此产生这种问题的可能性就小了很多。

Julio Cesar Ody ： 我认为Backbone是最小的框架，但这一点并不是最实用的关注点。最终，能够对你产生最强烈共鸣，并且以某种方式让你觉得用起来很满意的一点在于哪一个框架能够为你带来最高的生产力。

因此，在Backbone、Angular以及Ember之间，无论你选择哪一个都一定不会错。我在这里去掉了React.js，因为它实际上只是一个UI组件库，因此不应将它作为一种应用框架放在这里。

Thomas Davis ： 自从2010年以来有许多事情发生了变化，虽然我总是希望能够打破自己的旧习惯，但我目前还在使用Backbone.js。它仍然保持着最小化，并且它的核心理念与方法完全没有改变。但在我看来，它确实已处在被其它竞争者所取代的边缘了。像Angular这样的库进行了很多努力，它为开发者实现了对于DOM更直观的控制，这使Backbone.js在页面输出功能上显得很落伍。随着新的模块化JavaScript趋势的演变，也有可能以一体化的方式调用Backbone.js。没有理由要将模型、集合、路由以及视图等功能全部打包在一个单一的库中，像Components.js等方案会将这些元素作为单独的模块进行使用。模块化JavaScript目前还没有完全实现，我会考虑在下一个项目中使用它。

Igor Minar ： 我认为web开发领域对于移动设备的支持做得还不够，需要对此投入更多的精力。Angular的2.0版本将确定重新专注于移动设备。

Julien Knebel ： Ember比起其它框架更庞大，这是事实，即使对它进行压缩与gzip也改变不了这一点。因此对这一点需要认真考虑，尤其是你打算创建移动web应用的时候。而不论你使用Ember或是其它框架，要想达到平滑的60 FPS指标都很困难。我想说的是，你必须了解如何处理 常见的渲染性能问题 ，否则，无论你选用何种框架都会遇到麻烦。

Brad Dunbar ： 与其它框架相比，Backbone性能更出色，体积也更小。我在移动设备上使用它时还没有遇到过任何问题，不过我很少会为超过一代的老设备编写应用。

John Munsch ： 我目前的网站还没有真正地专注于移动设备，不过我在之前的工作中确实有关注过。当时的雇主需要在仓库与机库的二维码扫描枪中运行一个额外的web界面，因此我们特别制作了一个二级界面，它为扫描枪加入了一些页面。这些页面使用的技术与桌面版浏览器UI是相同的，并且调用了相同的后端API，但这些页面体积更小、更简单，以适用于扫描枪上的小型触摸屏。

在当时的环境中，这个方案看起来比创建一个现有页面的响应式版本更优秀，因为后者的功能有80%在移动设备上都要被砍掉。附注：我们非常幸运，当时刚刚出现了能够运行HTML5浏览器的高质量二维码扫描枪，正好赶上项目准备交付之前。而之前的工作都是针对只能够运行IE 5.5的扫描枪而做的（想想也让人不寒而栗）。

如果我今天再做一次这个项目，首先要做的第一件事就是加入Grunt，实现JavaScript的合并、压缩以及版本修订，以进一步提高移动与桌面版本的速度。随后打开expires头信息，让浏览器能够将内容缓存一个月或更长。

Julio Cesar Ody ： JavaScript本身运行很快，而且如今的浏览器性能十分优秀，并且还在不断提高。如果最终结果确实很慢，那肯定是在哪些地方出现了严重的错误。

即便如此，但对于优秀的用户体验来说，性能就是一切。不过JavaScript只是性能的一部分，如何应用CSS（包括过渡与动画），HTML标签写得是否足够好、足够简易，这些都对性能有着巨大的影响。你需要留意以上每个方面。

如果有哪一位曾经做过C语言中的微控制器编程，大概会了解所谓在受限设备中编程程序是怎么回事。虽然移动电话属于功能更强的电脑，但比起常规的膝上型电脑还是要慢得多。在这种情况下你无法承受犯下过多错误的代价，对于我在之前所提到的规则需要加倍留意。

对于可能产生问题的部分进行分析能够起到很大作用，这方面可以使用Chrome开发工具。

Thomas Davis ： 目前，要在移动与桌面开发的前端开发方式之间进行选择时并没有所谓的银弹存在。有些情况下原生的应用更好，而有时JavaScript应用或服务端生成页面的方式更合适。不过通常性能方面的问题都与DOM有关，我基本可以大胆地将赌注押在React身上。React实现了一种虚拟DOM，不同于浏览器中的DOM，只有在必要的时候才会改变DOM，以实现高性能的渲染。由于它使用了虚拟DOM，因此你也可以在服务端生成DOM，并且通过编程的方式进行访问。

Igor Minar ： WebStorm、Karma和Chrome。

Julien Knebel ： 我使用Grunt作为构建工具进行预处理、预编译、事后处理、合并、压缩等等。我最近几年最常用的IDE是TextMate2。我也在使用Chrome开发工具进行断点调试方面花了很多时间。当然，Git是不可或缺的。

Brad Dunbar ： 我倾向于使用最简单的配置，包括一个命令行界面和vim/node/npm。最近我也习惯使用browserify进行合并。至于工作流方面，我就是应用传统的编码、刷新和调试步骤。我从来都不是测试优先或是类似技术的支持者。

John Munsch ： 多数前端开发者在Mac机上都会使用WebStorm或Sublime，整个项目使用Maven进行构建，因为后端采用的是Java。我们最近开始在Maven构建中使用了Grunt，以实现前端代码的优化。我们还使用了Jenkins用于构建以及运行单元测试，并将代码部署至多个测试环境以及生产环境。

本地开发者通过Karma在后台运行我们目前所有的AngularJS单元测试（很遗憾目前只有30%的代码覆盖率）。

Julio Cesar Ody ： 我们会尽量多做一些前期设计工作（我是负责人）。根据对页面效果的观察能够帮助我们在脑海中将所要编写的组件进行分解。

我自己编写了一个构建工具，名为 Hopla ，并在最近的项目中大量地用到了这个工具。它使用Sprockets用于编译CoffeeScript和SASS，并将应用编译为静态的HTML/CSS/JS。它对于部署非常方便，甚至还能够构建Phonegap应用。

我在开始实现设计时首先会编写一个静态的HTML页面，用SCSS设计样式，之后再对页面中的每个部分用JavaScript组件进行替换。

Thomas Davis ： 老实说，我对其他人进行开发与调试的方式并不关心，我自己在不同的项目中也会采用不同的方法。我唯一能够给出的建议就是开发者应当使用异步模块定义（AMD），Require.js提供了一个非常出色的AMD实现，从我的经验看来，它能够使在所有语言及环境中的调试最简化。它不仅能够智能地对你的代码进行结构化调整，并且使得切入你代码的门槛变得很低，因为所有东西都必须成为在某个文件路径中所引用的依赖。

Igor Minar ： 代码重用、减少样板代码、风格指南以及约定，这些规则对于减少大型代码库的复杂度来说十分重要。但在实际应用的经验中，我观察到的是高质量的测试集的影响更大，它能够让我们在进行重大重构时保持低风险，而重构正是保持代码库整洁的关键。

Matteo Pagliazzi ： Angular的复杂性偏高（例如Service、Factory以及Provider的概念就让人非常困惑），因而在 v2 中将简易性作为目标之一。除此之外，我个人并不喜欢Angular中使用的脏检查机制，它用于判断哪些属性产生了变化，并相应地对视图进行更新（但随着Object.observe成为原生实现，就能够在属性变化时发出通知，而不必对每个属性的变化都进行检查，因此这一机制也将消失）。

总的来说：Angular十分出色，它的背后有一个非常优秀的社区，大量的外部库基本能够满足各种需求。即使在其中找不到符合需求的库，也能够编写自己的directive。但它本身带有许多复杂的概念，需要点时间才能充分理解。

Julien Knebel ： Ember能够很好地处理不断增长的代码库，因为它“强制使用良好的实践”，并且它的强约定能够让你通过一行代码完成许多功能（即约定胜于配置），这一点能够帮助团队中的每个成员更快地对其他人的代码进行调试。我也看到一些开发者因为Ember对他们的编码方式进行约束而感到愤怒，但我认为真正令人感到受挫的地方在于你必须首先理解并学习Ember，才能够用它实现一些酷炫的功能。只是我也相信，这些额外的学习时间从长远来看是值得投入的。此外，我很相信由Yehuda Katz 和 Tom Dale所创建的Ember（不过我想这一点就没那么客观了 J）。

Brad Dunbar ： 我认为无论对于哪一种框架来说，维护大型JavaScript代码库都是一个挑战。克服这一点需要通过团队维护一系列指南，并始终坚持其规范。但在某种程度上对模块（我提到过，我很喜爱npm与browserify）的使用能够起到很大作用。

John Munsch ： 目前为止，我们对于大规模的体验还是很好的，前端的JS可以进行大量的静态文件优化、缓存甚至应用CDN，因此可以充分地扩大规模。唯一的不良体验是由于在页面中尝试渲染过多的数据项所造成的。我们也尝试着鼓励使用分页或其它临时方案，但对于它们的使用并不能总是保持一致。而在旧版本浏览器上通过渲染几千个DOM元素以显示数据的方式也是性能问题的主要成因。

至于其它问题都已不复存在了。举例来说， AngularJS在切换视图时会自动消除视图与控制器，这就使另一个视图的内存占用不会影响到当前视图。当开发者向一个单一页面应用中加入越来越多的功能时，这个简单的方案能够帮助他避免许多问题的出现。 （注： John 似乎对问题中的大规模一词有所误解，这里指的规模是针对代码管理，而不是针对网站的性能问题。）

Julio Cesar Ody ： 我认为没有哪个流行的框架定义了任何大规模化的实现途径，要由开发者想出一套健全的方案，并坚决执行。

我一直很推崇组件与模块的概念。它让我感觉编写程序就像打造一块手笔，每个部分（或组件）都有它的意义，并且要尽可能地独立运行，但又提供一个很小的表层区域，让其它组件能够与其交互。

Thomas Davis ： 正如我之前所说的，只要你使用了一个模块化的JavaScript框架，例如Require.js，那么对你的代码库扩大规模及进行维护就是一件轻而易举的事，剩下的就取决于你的编码实践。按照这一点来说，Backbone.js也应当将自身划分为多个模块，因此你不必将Backbone整体作为依赖，而只需引用Backbone.Model就够了。

Matteo Pagliazzi ： 在我看来，在一些以Angular作为客户端框架的大型开源项目中，如果有一些经验不足的开发者加入，那么在继承方面往往会产生问题，或是以大量的对象污染了$scope与$rootScope。当这种情况达到某种程度之后，就会开始让应用变得缓慢，并增加浏览器的内存占用（它很容易就会达到300多MB的占用，而即使只出现了一个很小的内存泄漏，也会轻易地达到1GB内存的占用）。Angular使数据绑定变得如此“简单”，这一点当然很棒。但你也要了解，正是通过这些“魔法”，它才能够总是满足你想要的功能。

Julien Knebel ： 所有这些MV*框架都要在前端进行繁重的JavaScript运算，因此如果你的应用需要为用户展现大量数据，你会很快触及你的性能底线（这里指的是60 FPS的渲染）。你需要处理分页、智能滚动、CSS修饰、微妙的排序、以及通过网络调用获取数据时，在特意选择的地方显示旋转器等等。最终，这些特性会带来很大的性能影响。

Brad Dunbar ： 我认为最常见的问题其实在你开始投入研究框架之前就产生了，你的客户端与服务端同样需要进行测试、模块、包管理器以及持续集成。如果你能够忠实地完成这些工作，那就应当没什么问题了。

John Munsch ： 我之前已提到了在使用Backbone.js时遇到的问题，但还有些常见的问题总是会发生的。比方说，对于完全由前端JavaScript生成的页面来说，SEO就是一个要顾及的因素。比较幸运的是，我所参与的项目大部分都是SaaS服务，因此对于SEO并不十分关注。但如果你的网站受众是整个web，那么你就需要研究一下Prerender.io、BromBone等方案，以确定如何应对这些问题。Google Analytics也有类似的问题。这些问题都不是无法解决的，但能够事先了解这些问题总是好的，你需要为此选择一个解决方案。

对于我们来说，毫无疑问，IE8是我们最大的问题之一。它的市场份额仍然很高，但又没有一个内置的JavaScript即时编译器，这样的浏览器仅此一家。其结果是一些具有大量JavaScript代码的前端页面有些会表现得非常缓慢，并且在显示大量数据的时候会触发“脚本无响应”错误等等。IE8这个恐惧越早消失，我们的日子就能好过一点。

Julio Cesar Ody ： 在我看来，学习曲线是最大的问题。大多数人都已经经历了多年的web应用开发，其流程包括用服务端组件发送内容、处理请求、并请HTML发送回浏览器。

而MVC框架是一种完全不同的范式，它将网络编程（客户端/服务端）的方式进行了大幅度的重组，而并非所有人都有这种经验。它所面对的问题与网络编程是同样的，而在这方面的背景会对你有所帮助。

Thomas Davis ： 唯一的一个需要关注的主要陷阱在于，服务端生成的内容无法通过URL进行获取。这显然会阻止搜索引擎对你的网站进行索引，并且在分享页面时也会遇到问题。如今有许多社交网络会在用户分析内容时尝试解析你的网站，这样它们就能够获取更多的信息。而如果你的内容不是由服务端生成的，在试图进行分享时就会失败。不过这个问题已经被多次解决，我推荐 prerender.io 这个优秀的开源解决方案。我还编写了一个SEO服务端库用于缓解这一问题。而搜索引擎的巨头们也应当找到如何渲染你的单一页面应用以找到内容的方案。有人推测，整个Chromium项目就是Google的一次尝试，它能够加载并执行全部页面，从而将页面推送至Google Bot，并对JavaScript所生成的内容进行索引。

Igor Minar ： 关于Angular有一些优秀的书籍，还有例如ng-newsletter.com这样的newsletter，还可以在 这里 找到许多优秀的播客内容。

Julien Knebel ： Ember.js 网站上的官方指南内容非常详尽，每一篇指南都会对一个特定的框架特性进行讲解。此外，我在Smashing杂志上撰写了一篇《 对初学者的深入介绍 》文章（当时Ember 1.0刚刚问世），依我拙见，其有效性还是很高的。

Brad Dunbar ： 虽然这种方式也许不是最酷的，但我总是推荐开发者阅读其代码。这才是它的价值所在，而如果它确实不能满足你，你也能够因此了解。通过这种方式，你将对你选择的MVC框架非常熟悉，如果你无法忍受其源代码，那么你可能就会因此将其束之高阁。

John Munsch ： 如果提出问题的人本身已经对JavaScript非常熟悉，那么我会推荐他选择开发一个小型项目（以四个或更少的视图组成的web应用），并使用他选择的框架实现整个项目。亲手创建一些东西，哪怕它非常简单，也要将其全部完成并实际投入部署使用。这与“试用”一个框架是完全不同的概念，它会迫使你解决一些特定的问题，并真正地理解某些东西。如若不然，这些内容很有可能会被忽略，因为对于学习来说，它们或许并不那么有趣。

Julio Cesar Ody ： 在你的个人小项目中尽可能地多犯错，但要对其 格外留意 。我的意思是没有必要一上来就试图在试用过程中让每一点都做到完美，它也不会帮助你更快地实现这一点。

然后对你的代码不断地进行重构，要记住你在寻找的这种场景：将一堆组件组合在一起，成为一个完整的应用，同时又要尽可能让这些组件保持独立。

我为此编写了一份 免费的小册子 ，特别专注于Backbone.js，当然这也是我所推荐的框架。

Thomas Davis ： 这取决于你的学习风格，我通常会倾向于深入代码并随意使用。我的 Backbone.js视频教程 在网上获得了大量反馈，你可以在YouTube上找到它们。

Igor Minar ： 移动、可测试性、还是移动。

Julien Knebel ： 下一步应当解决在后台与多个客户端之间的实时数据同步问题，Meteor.js貌似正走在这个方向上，我肯定会很快尝试一下的。

Brad Dunbar ： 对此我不太确定，我可能会为我认为Backbone所需的部分提交一些补丁，这些补丁并不都是很好的 J

John Munsch ： 最简单的回答是类似于在 ngmodules.org 上的使用数量，它能够告诉你哪些方案是开发者一直在不断寻找的。任何将前端框架与HTML/CSS框架（例如Bootstrap）、文件上传、国际化以及本地化相关的方案都是候选。如果有几百名开发者都在寻找某种方案，并指出某个他正在使用的方案的网站，那么你可以认为还有几千名用户同样也在使用它，只是懒得进行分享而已。这只是一种简单的回答，但我在这里想要提到两种功能，它们并没有得到应有的关注，即校验与去后端。

校验

客户端校验一直都有着很高的需求，对于某些页面来说可能会显得尤为复杂。我们有一些页面中包括了大量日期数据，需要对它们进行相互测试，以确保它们的时间顺序是正确的，还有许多变量也有着各位不同的限制。随后我们通过某个API调用传递到服务端，之后在后端还要进行同样严格的校验，因为你永远无法依赖于客户端的校验。我们的后端代码并非由JavaScript所编写，因此无法使用通用的代码库进行校验，这就迫使我们以不同的编程语言创建相同的代码集，这也使我们在某些极端情况下出错的可能性成倍地增长。

为什么不能够将数据描述为一种JSON架构，然后能够让我轻易地在API调用的双方同时使用它进行校验呢？我希望这一点能够得到简化。

去后端

作为一个术语，这是去年才出现的某种说法（例如 nobackend.org ），不过如今已经渐渐消失了。但它的理念似乎在Firebase、Hoodie、Backendless等技术上得以传递。我认为，对于那些只熟悉前端工作的开发者来说，能够以这种方式完成一个完整的应用，而无需他人帮助以完成后端工作，这是一种很好的方式。而即使对于我这样能够独立完成某个应用的前端与后端代码的人来说，这种方式也让我们能够轻易地实现某个想法的原型，或是最小化可行产品（MVP）。

Julio Cesar Ody ： 这一点很难说，我觉得许多思想都源自于对模块化的错误理解，举例来说，我之前一直反对增加更多特性的这种想法。

但我认为React.js的思路是正确的，它为你提供了一种以组件驱动的方式创建应用的思想，如果你遵循它的示例就不太可能错得很离谱。它也对某些复杂问题进行了抽象，例如DOM的性能，而使用这种抽象基本不需要付出任何代价。

没有人希望在创建某个应用的过程在这种问题上浪费时间，因此这就是向正确的方向迈出的一步。

Thomas Davis ： 客户端工具以及MVC框架正在向正确的方向快速前进，实际上我相信服务端API在这方面已经落后了。在开发RESTful API方面并没有真正的约定能够遵循，这也使客户端模型与集合难以有效地获取数据。在客户端进行错误记录也需要手动实现，但像 trackjs.com 这样的尝试也取得了一定进展。在客户端事件的处理方面也需要努力。