從javascript發展說到vue

Vue是基於javascript的一套MVVC前端框架，在介紹vue以前有必要先大致介紹下javascript產生背景及發展的歷史痕跡、前端MVVC模式等，以便於你們更好的理解爲何會有vue/react等框架的出現。

1.1 javascript發展概要及MVVC模式

【Web剛起步階段】

那會，只有可憐的HTML（超文本標記語言（HyerText Markup Language）），瀏覽器請求某個URL時，web服務器就把對應的html文件返回給瀏覽器，瀏覽器作解析後展現給用戶。隨着時間推移，爲了給能不一樣用戶展現不一樣的頁面信息，就慢慢發展出來基於服務器的可動態生成html的語言，好比asp、php、jsp等。

可是，當瀏覽器接收到一個html後，若是要更新頁面的內容，就只能從新向服務器請求獲取一份新的html文件，即刷新頁面。在那古老的2G的流量珍貴的年代，這種體驗是很容易讓人奔潰的，並且還浪費流量。

【進入javascript階段】

還好，聰明的前輩們在1995年末，在瀏覽器中引入了javascript。Javascript是一種腳本語言，瀏覽器中帶有javascript引擎，用於解析並執行javascript代碼，而後就能夠在客戶端操做到html頁面中的DOM，這樣就解決了不刷新頁面狀況，動態的改變用戶html頁面的內容。再後來，你們發現編寫原生的javascript代碼太繁瑣了，還須要記住各類晦澀難懂的API，最重要還須要考慮各類瀏覽器的兼容性，實際上是由於「懶」，就出現了一個救世主jQuery，並很快的佔領了javascript世界，幾乎成爲前端開發標配。

例如 獲取某個元素節點內容

原生寫法：document.getElementById(‘name’).innerHTML();

jQuery寫法：$(‘name’).html();

【學習後端MVC模式】

事間萬物每每都很難抵抗時間的洗禮，javascript也不例外，她也漸漸顯現出各類不和諧：組織代碼混亂、業務與操做DOM雜合，因此爲她引入並改造了後端的MVC模式。

javascript前端MVC模式，須要服務器端配合，JavaScript能夠在前端修改服務器渲染後的數據，簡單來講即提交一次反饋一次。

例如：提交表單 填寫內容 → 點擊提交 →業務邏輯處理 →存入數據庫 → 刷新頁面→服務器取數據庫數據→渲染到客戶端頁面→ 展現上一次你提交的內容。

MVC概念釋疑：

視圖（View）：用戶界面。
控制器（Controller）：業務邏輯
模型（Model）：數據保存

View 傳送指令到 Controller；Controller 完成業務邏輯後，要求 Model 改變狀態；Model 將新的數據發送到 View，用戶獲得反饋。數據流，如圖：

但惋惜，他並不沒想象那麼美，那麼這種模式有哪些缺點？（注：如下缺點網上總結的，說的挺對，引用）

缺點一：

    它必須等待服務器端的指示，並且若是是異步模式的話，全部html節點、數據、頁面結構都是後端請求過來。

瀏覽器只做爲一個解析顯示容器，Model 做用幾乎是廢x，Model 層面作的不多幾乎前端沒法控制，你前端幾乎是切圖仔和作輪播圖的工做

缺點二：

    由於你前端渲染的頁面結構，幾乎是後端服務器包紮一堆數據一塊兒發送過來，前端的你只須要用拼接字符串 或者字符串拼接引擎

   好比Mustache、Jade、artTemplate、tmpl、kissyTemplate、ejs等來作事，說白了純苦力和重複工做居多，這也致使了，若是不少人認爲前端並不重要，只負責美工 和 動做體驗就行了。

缺點三：

    一發而動全身。數據、顯示不分離！爲何這麼說，由於若是業務邏輯要變，好比很簡單的需求，你用jsp或者php 拼接出來的ajax數據頁面，年齡這個字段我不須要了，把性別字段 區分開，男的單獨顯示，女的單獨顯示，之前是一塊兒顯示到一個表的

【MVVC階段】

沒錯，說那麼多缺點，就爲了最後的MVVC模式，爲什麼MVVC模式？

MVVC模式是基於數據驅動，她把Model用純javascript對象來表示，View負責顯示，達到二者分離：

一、它採用雙向綁定（data-binding）：View的變更，自動反映在 ViewModel，反之亦然,model數據的變更，也自動展現給頁面顯示
二、把Model和View關聯起來的就是ViewModel。ViewModel負責把Model的數據同步到View顯示出來，還負責把View的修改同步回Model。

數據流向變爲，如圖：

與以前MVC的主要差異點在於，MVC你須要操做DOM及javascript對象來改變前端數據，MVVC你只需操做javascript對象便可改變前端數據。這也是MVVM的核心思想：關注Model的變化，讓MVVM框架利用本身的機制去自動更新DOM，從而把開發者從操做DOM的繁瑣中解脫出來！也就是數據-視圖分離，數據驅動視圖，視圖不影響數據。

當今世上常見的MVVC框架有：vuejs、Angularjs、reactjs等等（想了解更多，見教程後面的對比分析）

【那麼vue來了】

好了，你們應該對javascript發展及MVVM模式有一個大致的瞭解，如今轉到vue，說下vue是一個什麼東西？

    官方文檔介紹：是一套構建用戶界面的漸進式框架，Vue 採用自底向上增量開發的設計，Vue 的核心庫只關注視圖層，它不只易於上手，還便於與第三方庫或既有項目整合。另外一方面，當與單文件組件和 Vue 生態系統支持的庫結合使用時，Vue 也徹底可以爲複雜的單頁應用程序提供驅動。

    我的實踐後對vue的理解：vue是一套構建前端的MVVM框架，它集合了衆多優秀主流框架設計及思想，輕量、數據驅動（默認單向數據綁定，但也提供支持雙向數據綁定）、學習成本低，且可與webpack/gulp構建工具結合實現web組件化開發、構建部署等；很慶幸，咱們生在開源遍地的時代，vue自己就擁有一套較爲成熟的生態系統：vue+vue-router+vuex+webpack+sass/less，不只知足小的前端項目開發，也徹底勝任開發大型的前端應用，包括單頁面應用和多頁面應用等，它可實現前端頁面先後端業務分離、快速開發（由於不少組件供調用）、單元測試、構建優化（結合webpack自動打包構建、優化）、部署等。瞬間提高前端開發人員的逼格，當後端開發再鄙視前端簡單時，你就可讓他來試試了。

1.2 主流前端框架比較

1.2.1 jquery

    嚴格說不能算是一個框架，只是一個javascript代碼核心庫，封裝了javascript繁瑣的操做，提供DOM操做、事件處理、動畫設計、AJAX交互、高效靈活的css選擇器等js常見功能，支持插件擴展，目前已積累豐富的插件，同時jquery兼容各類主流的瀏覽器，包括IE6+、FF 1.5+、Safari 2.0+、Opera 9.0+等。另外，目前很大一部分的網站仍是基於jquery庫進行前端開發實用，易用和便捷性使得不少初學者喜歡使用，但隨着各大瀏覽器對HTML5規範統一遵循及ES6的支持、前端MVVM模式發展，優秀的前端框架出現，jquery使用狀況正在逐年降低（但使用比例仍是很高的，存在即合理，你們不要太排斥），下圖爲國外對js各類框架使用狀況的投票：

    對於剛接觸web或js的開發者，jquery無疑是最容易上手的，在html頁面引入jquery文件，就能夠隨意操做DOM及動畫，可是隨着項目不斷擴展及需求不斷新增修改，你會發現js代碼愈來愈難以控制，jquery的複雜度也隨之遞增，維護性也愈來愈差，特別對於接手別人代碼的，複雜的js很容易會讓人狂躁。這裏並非說jquery很差，只是在新技術及新框架模式衝擊下，jquery慢慢顯示出他的缺點：

一、簡單粗暴，用戶行爲驅動的編碼方式

二、經過豐富的DOM操做去組合業務邏輯，當業務邏輯複雜的時候，就會發現js代碼複雜度也會飆升，由於業務邏輯與UI混一塊兒。

三、實現單頁面應用困難，並且操做體驗不太好

1.2.2 React

Vue不少設計參考了react思想，好比Virtual DOM、提供響應式（Reactive）和組件化（Composable）的視圖組件。但vue兼顧了平衡考量（性能、複雜度）。在3個主流框架中，只有react支持IE8，其餘都只支持IE9及以上，在這點上對國內的吸引力仍是很強的。

React優劣點：

1）相比vue，出生貴族（由fackbook開源），有更豐富且成熟的生態系統react （+ react-dom） + react-router + redux + webpack + sass/less

2）豐富的自定義渲染器

3）社區活躍，開源貢獻的組件多；vue不夠react火熱，但處於上升階段，仍是值得國人擁有

4）對於初級開發者和初學者有較大的學習難度，因爲react是基於js實現，秉承的是all in js，即在js中插入html和css，這不論對新手仍是老手學習期間就有不少痛點須要克服，要求有javascript高級編程知識和ES6的基礎知識。另外不少有價值的文檔資料、評論，相關新的技術文章等都是英文，沒有必定英文水平會有必定的痛苦，固然目前國內一些開源社區也都會比較及時翻譯一些優秀的文章。在學習曲線這方面vue2就低不少，它的官方中文文檔寫的真是詳細而易懂，讓人看了就深深愛上，非常複合國人的口味，但世間萬物老是存在矛盾，另外一方面，咱們在vue遇到問題時並無react那麼多網上資料能夠參考，不少時候須要求救於官方來解決。

1.2.3 Angular1/Angular2

Angular是元老級的前端框架，由google開源，一開始就顯得特別高大上，Angular1堪稱經典，獲得了javascript開發者的極大認同，幾乎成爲前端框架代名詞，讓人感受就是前端框架的將來。相比其餘框架，Angular絕對是最全面的框架，大而全一站到底的框架，因此也讓開發者感受比較重，在開發過程還須要嚴格遵循它定製的規則。

隨着其餘框架崛起，很快的吞噬了Angular份額，Angular1的一些缺點應該也有深入體會，因此他們在Angular2版本時直接就拋棄了Angular1，即1到2的升級基本不可能,1和2的生態是徹底割裂的。對開發者來說其餘它算2個框架。另外，Angular2壓縮後的大小大約500kb，在移動場景下仍是蠻可怕的。Angular2的社區，目前來看基本沒有，這點看有點可憐，單純靠着google來撐場面。

Angular1：使用數據雙向綁定，在組件多而複雜時，使得數據流不夠清晰，容易有莫名其妙問題發生。另一個被詬病的是髒檢查循環問題，使得性能變得不好，此問題在Angular2獲得解決

Angular2：它是一個全新框架，API也徹底改變了。可能仍是基因問題，仍是追求大而全的框架，在擁有一套優秀的組件系統同時也使得框架限制多，不夠靈活。另外，Angular2學習曲線也比較陡峭，包括TypeScript、ES2015標準的javascript、NPM依賴包等

1.2.4 其餘框架說明 

    其餘框架Ember、Knockout、Ploymer、Riot，沒接觸過，你們若是感興趣能夠在vue官網看到這些框架詳細對比，或者google來了解這些框架的一些特色

1.3 我要選什麼？

咱們不該該排斥任何框架，存在即合理，若是精力、能力充裕的小夥子，建議能夠接觸多個框架，這樣對不一樣框架間的特色及優點點會有更好的理解。對於實際項目中框架選型，咱們當前選擇的標準主要是：項目場景、團隊技術水平和偏好

1）項目場景，如：單/多頁面、輕量/大型應用、後臺系統/活動頁面等；

2）團結狀況，如：團隊總體技術水平、成員學習能力、是否有相關框架使用經驗、學習成本對項目進度影響等。

綜合下，加上前面對框架的一些特性瞭解，相信你們內心就有大致的傾向，注意下，這裏咱們只是給你們一些方法，要靈活應用纔是王道，不可生搬，以避免影響到實際的項目進度。