Web 前端開發需要使用 MVVM 框架嗎？
MVVM框架一堆，大同小異，但我想思考的是，真的有這個必要嗎？從哪個層面來思考的呢？
我覺得jquery+template沒什麼問題啊。歡迎大家一起來探討。-------------------補充：我一直在看backbone，並非排斥mvvm，只是提出疑問，希望更多朋友參與討論
多好的問題。如果你覺得 jQuery + Template 夠用，那就說明對於你目前的業務場景真的夠用，那麼完全沒問題。這讓我想起今年 9 月份 Dan 親手寫的 You Might Not Need Redux [1]：
MVVM 也是這樣，每當我無意看到 「我們的新網站用了 vue/ng，MVVM 真棒！」 然後點進去發現是個沒什麼交互的網站，有的甚至還是多頁網站時……People often choose Redux before they need it. 「What if our app doesn』t scale without it?」 Later, developers frown at the indirection Redux introduced to their code.
其實無論是 jQuery-like 的 MVC， 還是 Vue/ng 這樣的 MVVM，View 都是很薄的一層 Template，首要目的都是把 Model 與 View 解耦開來。但是在傳統 jQuery-like MVC 中，比如作者提到的 Backbone，對於 Model =&> View 這個過程該如何去實現並沒有太多主意，大量操作還是要自己干，所以 ViewController 很容易變得臃腫且難以維護。而在 MVVM 中，ViewModel 相當於一個 Model =&> View 的 Converter，你把數據從 Model 給到 ViewModel 就可以了，View 的更新通過 View 與 ViewModel 間的 Data-binding 自動完成。為了得到這樣的好處，MVVM 要求你抽象出 ViewModel，並且只能以一種 「更不簡單粗暴」 的方式來書寫你的代碼，是的，這是一種妥協：The tradeoff that MVVM offers is to add indirection to decouple 「how data convert to view」 from 「how view update」.咳，這句是我照著 You Might Not Need Redux [1] 里的話編的。但是這句是真的：frameworks themselves can also introduce complexity of their own.
The Progressive Framework - @尤雨溪
以上。---[1]: medium.com 的頁面[2]: google.com 的頁面But if you trade something off, make sure you get something in return.
如果你需要妥協掉一些東西，請務必換回點好處來。
1. 談談jquery + template
在來看看jquery + template 是什麼？一看就主要dom操作，和UI交互。而處理數據是弱項網路大型應用程序主要是以下流程
1） 你要獲取界面上的數據 2）後台交換數據3）獲取數據後，對界面重新進行渲染
這個過程中，你和後台數據交換怎麼實現？jquery的ajax吧，如果數據交換的API假設20多個，那麼$.get或者$.ajax你要寫多少個才能全部包含進去？而且所有API鏈接都不在一個地方，管理起來相當麻煩。而backbone只要配置一下route就行了。
獲取了數據後，你有如何管理這些數據，如何把數據渲染到界面上去？
如何管理各種事件?
jquery本身特性，也就是事件觸發，很多時候，就是你在編寫 觸發事件-&>處理數據 的流程很顯然，功能一多，代碼就會和麵條一樣，交織在一起了。然後你要麼崩潰，要麼自然而然的開始寫你自己的框架來管理代碼了
總結一下：
1. 重複代碼2. 混亂代碼4. 更多精力用在UI的交換細節和渲染細節處理5. 不宜擴充
6. 用戶交互觸發事件7. 數據處理不在框架之內8. 面向網頁元素編程小項目合適使用。或者只是編寫庫，而不是系統編寫（不涉及數據處理），那純用jquery還行。
jquery+template思路: 面向網頁元素編程，把精力更多的放在對網頁界面的元素進行定位和操作
2.談談MVC（MV*）
對於超過一定數量功能的網頁應用程序，最困難的如何高效的組織代碼，如果能合理的架構出一個合理高效的應用程序，這個是作為程序員在思考的問題。然
而有很多功能的一個大項目，有很多頁面，也有很多代碼，那麼那麼多代碼一定會出現重複的，也一定有重複的工作流程在裡面，「don『t repeat
yourself」
不要重複自己，那麼如果能把所有重複的地方都抽象出來，漸漸的你會發現，你自己就在做一個自己的程序框架。而這個框架可能就和現有的MVC相似
編程水平一般的人喜歡看代碼是如何實現的，編程水平高的人一般看的的代碼的抽象架構
backbone的依賴是jquery和underscore，它是建立在這兩個庫之上的，jquery操控界面，underscore處理數據，ajax進行前台和後台的數據交換，如果加上handlebar，可以減少對節目的代碼量。
backbone本身就只是把一些重複的流程和代碼抽象出來，可以你就可以不必一直重複一些不必要的工作了，（基本上所有的庫都是這樣）。還有一些簡單的規範，迫使你遵循規範來寫。
另外編程最好的狀態是集中精神些業務邏輯，而不是一些實現的細節。優秀的庫，就是應該幫助程序員更加集中精力放在業務邏輯上，也更加註重數據和最終的界面關係
另外MVC更加合適解耦，模塊化，這樣十分便於擴充，加個功能，加個API，模型和它的視圖會容易很多。
MVC還有個感覺，就是更多的配置，更少的編程。或者說，編好各種模塊後，通過配置，將他們鏈接起來(框架通過自己的機制去處理這些配置)。 配置好處有：1）結構化結構清晰一致 2）一個類型的東西在一起 3）可讀性高。
而事件管理上面，MVC更加註重模型的數據改變而觸發各種事件，就是將數據和事件聯繫起來，數據變動，界面變化。
總結一下：
1. 簡化代碼2. 減少重複3. 強制規範4. 集中精神編寫業務邏輯
5. 易於擴充6. 數據觸發事件7. 面向數據編程大項目一定要使用框架，不然到後期要不寫不下去，要麼回頭還是要自己寫一個框架來整理代碼的。
mvc編程思路: 面向數據編程，把所有精力放在數據處理，儘可能減少對網頁元素的處理。
* 其他
有些人會認為，庫越多，越消耗性能，但是當應用網站功能達到一個量級，你的代碼開始需要以更好方式組合的時候，你又開始重構為自己網站些框架了，那麼使用優秀的庫和框架，反而不會減少你應用網站的性能。=====
2014年8月22日更新：在談一些MVC的面向數據編程，和jquery面向網頁元素編程做個比較。
以前看別人寫的演算法可視化，覺得很神奇。然而我今天有了個靈感，覺得如果用angularjs的面向數據編程的理念做演算法可視化，是會大大簡化編程難度。所以想了一個思路，用angularjs做了一個冒泡排序的可視化編程。
如果你用jquery如何如何去實現？
思路大致如下：1. 對網頁元素進行定位，2. 把網頁元素數據化形成數組，3. 對數組進行排序，4. 重新對網路元素進行定位，5. 對把數組對應的兩個網頁元素進行操作（注意，jquery把重點放在網頁元素和定位和操作上，對定位和操作上花了太多精力了。）angularjs如何實現？簡單的思路:
1. 數組和網路元素進行數據綁定2. 對數組進行排序.（注意，angularjs，讓你把所有重點放在數據處理上，沒有網頁元素的定位和操作）如果你感興趣，可以看看我寫的代碼：
冒泡排序演算法的可視化簡單的幾句代碼，就實現了複雜的演算法可視化的處理。這正是體現了MVC數據綁定後，面向數據編程的思路。思考以下幾個問題：
- 當你意識到你用 jQuery 寫出的代碼難以維護時，你再改方案已經晚了。
- 對於持續集成項目，你不光要考慮到初次開發，還要考慮功能演進和可交接性。
- 很多人會忽略一件事——不使用框架編寫 js 程序是非常考驗技術能力的。沒有框架的輔助，普通人編寫 1000 行業務邏輯代碼，基本上已經一鍋粥了。
mvvm讓開發者宮注於業務邏輯， 把開發從平凡的dom操作中解放了出來， 非常有必要。
mvvm都比較耗內存，耗性能，移動端謹慎使用。pc端不存在這個問題，開發複雜的應用還是很爽的
像MVC這種框架體現了很多設計模式，什麼是設計模式，就是前人總結的一些方法，他們的經驗之談，必然有他們的優點。
MVC重點還是解耦，數據和展現的解耦，你的jquery和template怎麼做到，jquery+template可以做到模塊之間的解耦，但是無法做到數據和展現的解耦，數據和展現密切相關，修改數據的時候要改展現，修改展現的時候要修改數據，這顯然是極其不合理的。
而且，MVC框架通常提供模塊之間的通信，這就可以實現幾個人之間的並行開發，各做各的模塊，數據通過介面從別人那裡獲取，這提高了開發效率，避免了幾個人同時開發一個項目解決衝突和溝通的時間。
一個項目越大，開發人員越多，MVC的優勢體現的越明顯還是得看項目，小一點的簡單應用都是怎麼快怎麼來，大型一點的項目，交互複雜了，數據量也多，就需要考慮使用工具簡化步驟
使用angular 或其他MVVM代碼少一半,開發效率提高一倍
很有必要,不用就是和錢過不去我認為很有必要，尤其是大項目，增長中的項目，一個好的MVVM框架可以把你從業務邏輯和視圖更新的代碼中解救出來。即使是小項目，handy的binding也可以讓你快速的搭建demo，提高開發效率。
跟會不會用有關係，knockout還是很快的。用選擇器選出節點之後對其進行各種操作的代碼，在大型應用中也是看醉了。對照著HTML代碼看選擇器的對應腳本邏輯，維護的哥哥哭過幾回…
MVC的合理抽象，能把你從代碼中視圖、數據及邏輯的強耦合的困擾中解放出來，可維護和可復用會大大提高。
我認為jQuery + template只應該是一種很底層的工具組合。
在寫代碼的時候沒必要去操作任何選擇器。如果控制足夠細，把所有的功能視圖封裝成一個個模塊，每個模塊有自己的邏輯，只提供交互介面給外部調用，這樣你的業務邏輯絕對夠清晰，可維護性和靈活性絕對高。
當然，做到這些本身就需要框架內部去幫你處理一些事情，就是現在市面上流行的框架所存在的意義，它們致力於幫你把無意義的事情給解決了。
選擇什麼樣的框架要看自己的喜好和功力。我覺得jquery+template沒什麼問題啊。嚴重同意題主，mvvm框架都是犧牲前端性能來提高開發效率的，大部分項目頁面jquery和模板引擎足夠了。mvvm為什麼火，就是因為現在很多前端都是非專業的，後台開發的程序員坐前端非常喜歡。---再補充一下我的觀點：MVVM框架都是以大變數存儲DOM和數據的綁定關係，很耗內存。但是在PC上，這些其實不是瓶頸，所以我認為在PC端的複雜應用，用MVVM是可以的，但是如果不複雜，jquery+template也可以了。而在移動端，沒有必要用這些。我一直都是用John Resig(jQuery作者)（John Resig - JavaScript Programmer）的小型模板引擎John Resig - JavaScript Micro-Templating （10幾行代碼），完全夠用了。本人一直在做移動端的html5開發，所以真心不習慣以開發效率換性能。
你要是發現什麼語言,什麼語言的"書寫方式"流行起來了,那其實本質只說明了一件事:這個東西能節省時間,提高開發效率,碼農的單位時間產出率增加,公司效益增加...
如果你用的順手，就不需要mvvm
如果重複的套路太多，可以考慮mvvm1.數據綁定比方講你要做一個天貓那樣的購物車。頁面里的「加入購物車按鈕」，底部購物車裡的「增」「減」按鈕，底部購物車裡的輸入框，都可以修改商品的數量。修改的時候，頂欄的購物車也要跟著變。如果你是用點擊事件+callback的方法寫，思路繞，代碼丑。如果你是用mv*的方法，所有的用戶操作都可以變成對購物車裡數據的修改。mv*框架的數據綁定幫你為數據加上事件。不管是思路，還是寫出來的代碼，都清爽太多。2.SPA要做單頁面網頁，必須得有 1.前端template 2.路由功能不用框架，自己搞定這些東西不現實。
在你想做一個gmail那樣的應用時，只用jq+template 我確信你是會瘋掉的。
不用MVVM就是拿有限的生命在無情地揮霍罷了~