虛擬研討會——真實世界的 JavaScript MVC 框架

自 HTML5 大行其道，Web 平臺也發生了很大變化，開發者開始在 JavaScript 語言中尋求建立複雜應用的解決方案。許多新的 API 應運而生，在眾多合適的場景下，瀏覽器該如何利用好這一切。

這一系列的文章 將更進一步聚焦於如何將這些強大的技術應用於實踐當中，不會建立炫酷的示例和原型，而是幫助開發者如何在專案實踐它。在 HTML5 系列文章中，我們將帶著這些流行語在專家哪裡獲得如何在實踐中應用它們的方式。我們也會更進一步討論相關的技術（比如 AngularJS），並且探索未來的標準和 web 開發的趨勢。

這篇 InfoQ 文章是“Next Generation HTML5 and JavaScript”系列的一部分。你可以透過 RSS 訂閱。

隨著越來越多的邏輯在瀏覽器中執行，JavaScript 前端程式碼庫變得更大也更加難維護。開發者發現了一個解決該問題的方式，即前端 MVC 框架，提高了開發效率並且更容易維護程式碼。

早在 2013 年，InfoQ 已經發起了社群內 關於 JavaScript MVC 框架排行 的調查，依據它們的特點以及它們的完成度：

現在 InfoQ 向專家級實踐者發起了一次訪談，關於他們如何使用這些框架以及在開發 JavaScript 應用時使用這些框架的最佳實踐。

InfoQ：你最喜歡哪個 JavaScript MVC 框架，已經使用了多久，以及它幫你解決了那些最基本的問題？

Matteo Pagliazzi：

作為當下的框架，Angular 實至名歸，這不僅僅因為 GitHub 上獲得的贊同：它具備龐大的類庫，模組……並且正在被很多開發者討論和使用。很明顯我們開發者很喜歡它。我覺得這和它很容易上手有關：僅僅需要 5 分鐘就能輕易地完成一個完整並且功能強大的任務。不過，由基礎到框架的核心，學習曲線變得陡峭，你會發現它非常複雜。

Julien Knebel：

在過去 2 年多的時間內，我已經使用 Ember。js 開發了 5 個 web 應用。不得不說，它給我帶來了靈活、高效還有自信，因為我可以更多的聚焦在使用者體驗，而不是在複雜的特性上投入大量的時間，比如一個強大的非同步路由。

Brad Dunbar：

我最喜歡 Backbone。它提供了其他類庫都不具備的簡潔和靈活。同樣，或許更重要的是，程式碼的簡單易讀。

John Munsch：

我最喜歡的框架是 AngularJS，我已經使用它超過了一年，並且依舊在蜜月期一樣。

我所選擇的前端框架會解決一個最基本的問題，給我以足夠的骨骼、 肌肉和結締組織，幫助我建立複雜的 UI 的前端，而不僅僅是比較。不過，相比過去的使用 JSP、PHP、Rails 等後端框架建立請求/響應的方式，這種做法更優美。

Julio Cesar Ody：

我使用 Backbone 更多一些，現在逐步使用 ReactJS 替換 Backbone 作為檢視層。

我建立的所有 web 應用完全執行在瀏覽器中，並使用 API 和/或 Websocket 與伺服器通訊。這意味著很多邏輯最終都使用 JavaScript 編寫，所以 Backbone 可以協助我保證程式碼整潔並且可維護。

Thomas Davis：

我的第一個正式的 JavaScript MVC 專案在 2010 年末，那次我決定使用 Backbone。js 和 Sproutcore。我寫了一篇比較二者的文章，上了 Hacker News 的頭條並且獲得了超過 100，000 次點選。基於那次反饋，我決定使用 Backbone。js。因為它的體積小，而且無須侷限大規模框架的約定也不會妨礙我實現複雜的功能。在學習 Backbone。js 時，我為自己寫了一個教程幫我理解這個框架。這些文章獲得了上百萬的點選，並且仍在增長。目前歸檔在 backbonetutorials。com。

現在建立一個應用，使用者體驗設計和保證網站正常執行一樣至關重要。單頁應用准許你建立那些傳統頁面只能透過重新整理頁面無法企及的使用者體驗。比如，想象一下在你使用 Facebook 時每次評論都要重新整理整個頁面的情景。

InfoQ：既然有很多的替代品，你所選用的框架和其他的相比又如何？

Julien Knebel：

它表現的非常棒！我從沒想過它會讓我自己完整地編寫整個應用，儘管 Angular 也非常棒，我更在意一個框架是否能快速搭建並執行。然而我相信隨著程式碼庫的增長，它可能變得更加枯燥。另一方面，在我著手學習 Ember 時遇到了很多困難，但是經過幾次“哈哈哈哈”，它們就像冬日裡的積雪在陽光下慢慢融化。另外一個重點（至少對我）是“元件化“”，我不喜歡 Angular 用指令解決這個問題，Ember Component 似乎才是正確的方式。

Brad Dunbar：

我發現幾乎沒有那個 JavaScript 框架可以恰好滿足應用中的所有需求。這意味著我總會圍繞它們寫一些東西。Backbone 設計的功能很少並且提供了可以相互組合的工具類，而不是增加那些幾乎用不到的功能。

John Munsch：

這個問題很難回答，我的開發經驗只在 Backbone。js（大約兩年）和 AngularJS（僅僅一年）。不過，這二者我很難取捨。

Backbone。js 不錯，但是在我們共同開發一個大的專案時，最多有六個人。我們遇到了很多問題，我們使用其他類庫（雙向繫結、驗證、模板、AMD 等等）填補了 Backbone。js 在這些方面的空白。如果沒有在開始前找到填補這些空白的解決方案，那麼你的同事只能選擇自己的方式。如果時間很趕並且編碼很快的話，很難找到所有的區別並且強制統一。

我們最終完成了一個專案，並且和原來的解決方案相比更快速，不過它是一個雜交體；它的每部分都想是一個不同的動物。使用 AngularJS，這些部分大多數還是來自於框架自身並且出現這類問題的可能性也會變小。

Julio Cesar Ody：

不得不說 Backbone 非常的輕量，不過這已經不是我們需要十分在意的點。一個類庫優於其他最主要的以及原因，在某些情況下開發者更喜歡使用並且在更加高產的一個。

所以在 Backbone、Angular 以及 Ember 之間，你不能選錯。我沒有把 ReactJS 包含在內，主要是因為它僅僅是一個 UI 元件庫，所以不應該把它和其他應用框架相混淆。

Thomas Davis：

自 2010 年發生了很多變化。儘管我總是嘗試打破自己的舊習慣，但是目前我依舊在用 Backbone。js。它仍然是最小的並且它的理念和方法幾乎沒有改變。在我看來，它正逐步被其他競爭者所取代。Angular 這種類庫做出的努力讓開發者更加容易控制 DOM，在渲染時 Backbone。js 看起來更加的古老。與全新的模組花 JavaScript 相比，也可以成 Backbone。js 在體積上更大。沒有任何理由將模組、資料集、路由和檢視打包放在同一個類庫中， 相反類似 Components。js 將這些部分寫成獨立的模組。此時還沒有真正的使用，我將在另外一個專案中考慮它。

InfoQ：建立更快、更健壯的前端很贊，但是效能如何？尤其在移動端。你們有哪些經驗？

Igor Minar：

我覺得移動端依舊是 web 開發中需要考慮到的。需要給予更多的關注，Angular 很明顯在 2。0 版本中重新聚焦移動。

Julien Knebel：

Ember 相比其他類庫更重，這是事實。儘管可以壓縮它，如果你打算在移動端 web 應用中使用它，一定要慎重考慮。流暢地處理 60 FPS 的動畫會很困難，你可以用 Ember 或者其他類庫實現它們。你需要了解如何處理常見的渲染上的效能問題，否則無論你選擇哪個框架都會陷入困難之中。

Brad Dunbar：

相比其他類庫 Backbone 更加高效和輕量。在移動端我沒有遇到任何問題，不過我沒有為老舊的裝置編寫適配。

John Munsch：

我現在的站點還沒有關注移動端，但是之前的崗位確實在移動端做了很多。因為他們需要在倉庫和棚廠區為掃碼槍執行一個額外的 web 介面。我們建立了一個附屬的 UI，僅僅是掃碼槍的一個幫助頁面。他們在桌面瀏覽器 UI 下使用相同的技術，並且頁面會呼叫同一個後端 API，不過掃碼槍觸屏上的頁面會更小更簡單。

在那種環境下，嘗試為已經存在的頁面建立一個響應式版本並不是一個好想法，因為在移動端可能要丟掉 80% 的功能。注意：我們非常幸運，在該專案發起前已經在 HTML5 瀏覽器下存在高質量的掃碼槍。更早之前，這種掃碼槍功能僅僅訊在與 IE5。5。

如果我現在想要回到這個專案，我要做的第一件事就是藉助 Grunt 為 JavaScript 拼接、壓縮、版本等，這可以近一步加速移動端和桌面端。開啟頭部的 expires，這樣瀏覽器快取就可以存在一個月或者更多。

Julio Cesar Ody：

JavaScript 很快，現代的瀏覽器也是非常的高效並且在持續最佳化。

也就是說，當提到好的使用者體驗效能就是一切。不過 JavaScript 層面的事情只是一部分。如何使用 CSS（以及 transition、animation），小而美的標籤是怎樣的，這些也會影響效能。你必須關注整體。

如果你們中有人做過 C 語言中的微控制器程式設計，就會了解在受限的裝置上編寫程式。儘管手機已經像電腦一樣強大，但它們依舊普遍上比手提電腦要慢。你承受不起過多的錯誤，並且你最好按照我前面提到的規則，加倍小心。

檢測有問題的東西會有很大幫助。首推 Chrome 開發者工具。

Thomas Davis：

目前來說，在選擇移動端和桌面端之間的前端開發方式上並不存在一個通用方法。有時，原生應用更好，有時前端 JavaScript 應用，有時服務端生成的頁面。儘管，效能問題通常與 DOM 操作相關，我敢打賭 React 將大行其道。React 實現的虛擬 DOM與瀏覽器中 DOM 相比較，僅僅在有必要時更新 DOM，達到了高效能渲染。正因為它的虛擬 DOM，你也可以在服務端渲染，在程式中訪問它們。

InfoQ：使用你所選擇的框架最有哪些獨有的工作流程？使用什麼用具開發和除錯？

Igor Minar：

Webstorm、Karma、Chrome。

Julien Knebel：

我使用 Grunt 作為構建工具預處理、預編譯、後處理、連線、壓縮等等。TextMate2 是我一直選用的 IDE。我同樣花費了大量的時間在 Chrome 開發工具上使用斷點和偵錯程式來進行除錯。當然，我離不開 Git。

Brad Dunbar：

我傾向於使用那些極簡的設定，包括一個 CLI 和 vim/node/npm。最近，我正在享受 browserify 的 bundling。對於工作流程，我是很典型的編碼、重新整理、除錯迴圈往復。我從不是測試優先或同類事情的倡導者。

John Munsch：

很多前端團隊的開發者在 Mac 上使用 WebStorm 或者 Sublime。整個專案透過 Maven 構建和執行，因為後端是 Java，我們最近開始在 Maven 內部使用 Grunt 來最佳化前端程式碼。Jsnkins 用於建立和執行單元測試，以及部署到各種測試環境和生產。

現在，有些開發者在後臺執行 Karma 跑 AngularJS 單元測試（不過目前僅僅覆蓋了 30% 的程式碼）。

Julio Cesar Ody：

我做了很多自己能預見到（在我參與它時）的設計。觀察一個頁面的樣子協助我對將要編寫的元件做一次內在的分析。

我用過自己編寫的Hopla，在很長一段時間內，將其作為一個構建工具。我使用 Sprockets 預處理 CoffeeScript 和 SASS，以及將應用便以為靜態 HTML/CSS/JS。這樣會很方便部署，甚至在建立 Phonegap 應用時。

然後，我經常透過使用 SCSS 編寫一個靜態 HTML 頁面開始實現一個設計，然後檢查每一部分將它們替換成 JavaScript 元件。

Thomas Davis：

誠然，我一點也不關心別人喜歡如何開發和除錯，並且我的方法也會在不同的專案上發生變化。我對開發者最直截了當的建議就是使用 非同步模組定義（AMD）。Require。js 非常準確地實現了 AMD，並且在我的經驗中它使得除錯所有的語言和環境都更加簡單。它不僅僅幫助你結構化你的程式碼，而且減少整個程式碼庫的障礙，因為一切都透過一個檔案路徑作為依賴引用。

InfoQ：隨著應用變大，保持架構的健壯以及維護龐大的程式碼庫是一個挑戰。你喜歡的 JavaScript 框架有多大規模？當開發團隊膨脹並且不同的開發者需要負責不同的功能時，它的擴充套件性如何？

Igor Minar：

程式碼重用，簡化示例程式碼、樣式指南以及一些慣例用法對於壓縮龐大程式碼庫的複雜性都很重要。但是在我們的日常經驗中，我們發現高質量的測試測試用例會有更大的好處，因為它們允許在低風險的情況下進行重大的重構。程式碼重構是保持程式碼庫整潔的關鍵之一。

Matteo Pagliazzi：

除了複雜性之外（比如服務，廠商以及供應商呈現出的混亂），Angular2 所要解決的問題，也是我最不喜歡的髒檢測機制，它用於在屬性改變時響應地更新檢視（而且這可以透過 Object。observe原生地實現，允許改變後發出通知，而不是在每次屬性變化時去檢測）。

To wrap up：

Angular 非常棒，它有很了不起的社群作為後盾，有大量的外部庫可滿足每個日常需求。即便沒有找到，你也可以寫出自己的指令。不過，需要花上一定的時間去理解那些複雜的概念。

Julien Knebel：

Ember 確實能處理好日漸增多的程式碼庫，因為它的“強制最佳實踐”以及它的強約定，使得你需要處理很多單行程式碼（也就是透過配置進行約定）。它有助於團隊的每個成員都可以快速地 debug 其他人的程式碼。我看到一些開發者因為感覺到自己程式碼要受到 Ember 限制而憤怒。不過我猜真正的沮喪來自於在你想要用它嘗試一些炫酷的東西之前，必須去理解或者學習 Ember。並且我真的覺得這個額外的學習時間在長遠上看真的很值得。此外，我非常相信 Yehuda Katz 和 Tom Dale 的工作（但我想這有點主觀了）。

Brad Dunbar：

我認為大型 JavaScript 程式碼庫真的是一個挑戰，這和用了哪些框架無關。它需要團隊來維護一套方案，並堅持下去。藉助一些模組化方案（像我提過的 npm 和 browserify）是極好的方案。

John Munsch：

目前為止，我們在程式碼規模增長上有足夠的經驗，前端 JS 規模透過最佳化、快取甚至是 CDN 處理的很好。最壞的一次是嘗試在頁面上渲染上千條資料。我們也嘗試使用翻頁和其他方案解決，不過在使用翻頁以及在舊版本瀏覽器上透過大量資料生成數千個 DOM 元素的方案上我們還沒有達成一致。

其他問題實際上已經不是問題。比如，AngularJS 在切換檢視時，一個檢視保持記憶體佔用會影響當前的檢視，它的預設行為是丟棄檢視和控制器。這是一個簡單的解決方案，可以幫助很多開發者在一個 SPA 中新增愈來愈多的功能時避免很多問題。

Julio Cesar Ody：

我認為所有的流行框架都沒有一個既定的擴充套件路線。它需要開發者理性地選擇。

我一直很喜歡元件或者模組的概念。它讓我覺得寫程式就像是建立一個。每部分（或者說元件）都有它的目的，並且需要儘可能地獨立執行，暴露可以和其他元件進行互動的一小塊。

Thomas Davis：

就像我前面所提到的，只要你使用了一個模組化 JavaScript 框架比如 Require。js，規模和維護程式碼庫猶如閒庭信步，僅僅取決於程式碼規範。在這點上，儘管 Backbone。js 不需要被拆分成模組。你僅僅需要想示例那樣引入 Backbone。Model，而不用單獨地將 Backbone 作為依賴引入。

InfoQ：對你那些剛剛考慮使用一個 JavaScript 框架的團隊，有哪些常見的陷阱需要注意的麼？

Matteo Pagliazzi：

曾在一個很大的開源專案中使用 Angular 作為客戶端框架，我發現經驗不夠豐富的開發者很容易陷入繼承的問題中或者使用很多物件汙染了 和rootScope，這會讓應用變得很慢並且增加了瀏覽器的 RAM 佔用（我們一般使用 300+ MB，一個很小的記憶體洩露都可能輕易地佔用 1GB）。如此簡單的資料繫結確實很棒，不過你必須理解它才能更好地使用，因為它是很“神奇的”。

Julien Knebel：

所都的 MV* 框架都在前端進行比較重的 JavaScript 計算，因而應用需要為使用者輸出大量的資料，可能很快就超出了你的效能預算（假設 60 FPS 的預算）。你必須處理好翻頁、智慧地滾動、明智的 CSS 宣告、細微的順序差別、下拉選單的顯示位置等等。最終，將這些放在一起就會有非常大的影響。

Brad Dunbar：

我認為最常見的問題來自於框架中的 bug。你的客戶端需要需要測試、模組、包管理器以及持續地整合就像伺服器一樣。如果你做到了這些，應該就夠了。

John Munsch：

我之前提到過 Backbone。js 存在的問題，不過還可能會遇見一些常見的問題。比如全部在前端使用 JavaScript 生成整個頁面在 SEO 方面存在問題。很幸運，我的絕大部分工作使用了 SaaS，所以基本不用關心 SEO 的問題。不過如果你正在建立需要支援 web 爬蟲的專案，你可以去參考一下

http：//

Prerender。io

、BromBone 等的解決方案，決定你該如何解決。Google Analytics 也有同樣的問題。這些問題沒有不能解決的，不過最好知道有哪些問題，需要找一個解決方案。

對我們而言，毫無疑問 IE8 是最大的問題之一。它也是唯一各個佔據著大量瀏覽器市場並且沒有內建的 JavaScript 實時編譯器。結果導致了重度 JavaScript 依賴的前端應用有時會很慢。在需要展示很多資料等情況下可能導致“unresponsive script”錯誤。IE8 越早離開，對我們來說越好。

Julio Cesar Ody：

我所看到的最大的問題應該是學習曲線。很多人已經開發 web 應用程式好多年，包括服務端元件接收、處理請求以及將 HTML 返回給瀏覽器端。

這是一個完全不同的範例，和網路程式設計（客戶端/伺服器）有些像，並且和以前做的的那些都有些不同。它有很多和網路程式設計一樣的問題，具備這方面的背景一定會有幫助的。

Thomas Davis：

我所擔心的唯一一個問題是 URL 上不存在服務端生成的內容。這理所應當就阻礙了搜尋引擎抓取站點的能力，在分享頁面上也會遇到了問題。現在很多社交網路在使用者分享功能中都會對站點進行解析以便讀取到其他的資訊。如果沒有在服務端生成內容，這些嘗試都會失敗。儘管有很多方式可以解決這個問題，不過我還是推薦

http：//

prerender。io

這個開源方案，我還寫了 SEO 服務起類庫來環節這個問題。搜尋引擎巨頭們真的應該將它內建以便渲染出單頁應用的內容。有些人猜測 Google 的 Chromium 專案正在做嘗試以便可以載入和執行整個頁面。這樣就可以把它變成 Google 機器人並且識別出所有由 JavaScript 渲染出的內容。

InfoQ：如果想要開始使用一個框架，你覺得最快並且最有效的學習路徑是什麼？有哪些推薦的資源麼？

Igor Minar：

在

http：//

ng-newsletter。com

上有不少 Angular 方面的好書和諮詢，而且這裡還有很多播客。

Julien Knebel：

http：//

emberjs。com

官方文件很棒，對該框架的每個特性進行了詳細解釋。另外，我在 Smashing Magazine 上寫了一個詳細的介紹（Ember 1。0 問世的時候）。非常謙虛地說，這個教程仍有很大的意義。

Brad Dunbar：

這可能不是最酷的事，不過我總會推薦閱讀原始碼。這才是關鍵所在，你會知道是否它很爛。

John Munsch：

如果提問者已經很熟悉 JavaScript 了，我會推薦去完成一個小專案（四個或者更少的獨立的檢視構成一個 web 應用）並且使用剛剛討論的框架完成整個專案。建立一些東西，即便很簡單，完成的方式以及實際部署和單純“學習”一個框架還是有很大區別的。你會被強制解決一些具體的問題並且會真正的理解一些事情，否則你可能很自然的跳過一些事情，應為學習起來它可能不那麼有趣。

Julio Cesar Ody：

在喜歡的專案中可以犯很多錯誤，不過需要記下它們。我是想說，試錯和抓狂可能是個好方式，不過它不會幫助你很快地達到目的。

然後反覆修改你的程式碼，注意你要找到一個場景用來將很多個元件放到一起構成一個完整的應用，然後保證每一個都儘可能的獨立。

我曾經寫了一個免費的手冊，包括了 Backbone。js 的重要性，同樣是我比較推薦的教程。

Thomas Davis：

取決於你的學習方式，我通常比較喜歡跳進去然後開始鑽研。我上傳到 youtube 上的關於 Backbone。js 是影片教程總會收到很驚奇的反饋。

InfoQ：現在 MVC 框架已經成為主流，你覺得他們需要如何演變才能夠滿足開發者的需求？比如你覺得他們還缺少那些特性？

Igor Minar：

移動端、可測試性等。

Julien Knebel：

後臺和多個客戶端之間的實時資料同步可能是下一趨勢。Meteor。js 似乎正在這麼做，所以我一定要儘快試一試。

Brad Dunbar：

這一點不我太確定。我傾向於給 Backbone 不足的地方提交補丁，不過並不是每一個都被採納。

John Munsch：

最簡單的答案就是參閱

http：//

ngmodules。org

這一類站點，有很多開發者反覆地在這裡尋求答案。任何前端有關的框架都會涉及到 HTML/CSS 框架（像 Bootstrap），檔案上傳、國際化、本土化等等。如果成百上千的開發者都去探索它，在使用它上面花時間，你也就不用擔心社群分享的問題。這是簡單的答案，不過實際上還應該有這樣兩件事，校驗以及沒有後端。

校驗

總會出現客戶端校驗的情況，並且對某些頁面來說會很複雜。有很多頁面需要與其他頁面上的時間對比以確定它們是否在恰當的場景下出現，有些不可控因素也對其有很多限制。我們將資料透過 API 傳送到服務端，將嚴格驗證的資料返回，因為你不能依賴客戶端的驗證。我們的後算不是用 JavaScript 語言編寫的，所以我們沒辦法使用同一個程式碼庫來驗證，因而就需要用不同的語言寫相同的邏輯，對某些邊緣情況會出現犯同樣的錯誤的可能。

為什麼不讓我描述一下 JSON 模式的資料然後使得它在客戶端以及服務端驗證上變得都很容易呢？我期待看到它可以變得更簡單。

無後端

在去年，這是一個很火的話題（比如，

http：//

nobackend。org

），不過現在有些平息了。不過 觀點本身在 Firebase、Hoddie、Backendless 等技術下依舊很強勢。我認為這對僅僅熟悉前端的開發者來說是一件好事，可以不需要後端就完成一個完整的應用。這樣，很多開發者都可以輕易地建立一個應用的前後端，這提供了更簡潔的方式來實現一個想法的原型。

Julio Cesar Ody：

很難說。我認為很多想法源自於對模組化的誤解，所以很多特性的模式只是在和以前的想法爭辯。

不過我認為 ReactJS 在這一點上很正確，它提倡元件驅動的方式來建立應用，如果你僅僅跟著示例模仿就不會出現很糟糕的錯誤。它也改善了很多難題，比如 DOM 效能，這樣確實帶來了很多便利。

這也是在建立應用時很少有人願意花時間來解決的一類問題，所以這一步的方向很正確。

Thomas Davis：

客戶端 MVC 正沿正確的方向快速前進。我確信在這點上服務端 API 正在落後。目前，還沒有一個開發者共同遵循的既定的規範，當建立 RESTFul API 的時候客戶端資料模型和集合很難高效的獲取資料。客戶端的 Error 日誌同樣需要一定的工作量，不過嘗試使用

http：//

trackjs。com

會好些。如何處理好客戶端的事件同樣有很多工作要完成。

討論會成員

#FormatImgID_3##FormatImgID_4#Igor Minar

是一名來自 Google 的軟體工程師。他是 AngularJS 的帶頭人、測試驅動開發的實踐者、開源專案熱衷者、駭客。

#FormatImgID_5##FormatImgID_6#Matteo Pagliazzi

是一名熱情的軟體開發者和開源貢獻者。

#FormatImgID_7##FormatImgID_8#Julien Knebel

是一名自學的介面設計者和前端開發者，居住在巴黎。在是一個自由職業者，主要在法國的幾個最大的公司。

#FormatImgID_9##FormatImgID_10#Brad Dunbar

是一名 JavaScript 工程師，同時也是 Backbone 和 Underscore 專案的貢獻者。

#FormatImgID_11##FormatImgID_12#John Munsch

是一名具備 27 年開發經驗的專業軟體開發者。最近，他帶領團隊使用 AngularJS 建立新的 web 應用，在此之前的幾年內，他們使用過型別的 Backbone。js、Underscore。js 和 Handlebars。js。

#FormatImgID_13##FormatImgID_14#Julio Cesar Ody

是一名軟體開發者、設計師、主持人並且渴望成為作家，居住在澳大利亞·悉尼。他主要工作在移動 web 開發，並且開發了一個自己很得意的實用的工具。

Thomas Davis

是

http：//

backbonetutorials。com

的創始人、

http：//

cdnjs。com

聯合創始人以及 taskforce。is 的一名開發者。同樣，還是很多開源專案的每日貢獻者，可以在

http：//

github。com/thomasdavis

找到。

原文：Virtual Panel： Real-world JavaScript MVC Frameworks

關注微博：前端外刊評論