“

　　框架是什么？為什么要有框架？在眾多的框架之中，Vue獨具魅力之處在哪里呢？其背后的核心思想是什么？Vue究竟火到什么程度？最近發(fā)布的Vue2.0又做了哪些改進呢？Vue和Weex又是怎樣的一種合作？

　　本文根據(jù)尤雨溪在2016 QCon 全球軟件開發(fā)大會（上海）上的講演整理而成。

　　Tips：今天文章頭圖來自于兩位迷妹的堅持，有顏有才，這樣的程序員請再來一打！

　　作者簡介

　　尤雨溪，Vue Technology LLC 創(chuàng)始人， Vue.js作者，設(shè)計師，開發(fā)者，開源愛好者，前端框架 Vue.js 的作者。

　　曾就職于 Google Creative Lab，參與多個實驗項目的界面原型研發(fā)，后加入 Meteor，參與 Meteor 框架本身的維護和 Meteor Galaxy 平臺的交互設(shè)計與前端開發(fā)。現(xiàn)全職投入 Vue.js 的開發(fā)與維護，立志將 Vue.js 打造成與 Angular/React 平起平坐的世界頂級框架。

為什么要有框架

　　1、框架的存在是為了幫助我們應(yīng)對復(fù)雜度

　　前端框架特別多，那么為什么要有框架呢？我個人的看法是，框架的存在是為了幫助我們應(yīng)對復(fù)雜度。當我們需要解決一些前端上工程問題的時候，這些問題會有不同的復(fù)雜度。

　　如果你用太簡陋的工具應(yīng)對非常復(fù)雜的需求，就會極大地影響你的生產(chǎn)力。所以，框架本身是幫我們把一些重復(fù)的并且已經(jīng)受過驗證的模式，抽象到一個已經(jīng)幫你設(shè)計好的API封裝當中，幫助我們?nèi)?yīng)對這些復(fù)雜的問題。

　　2、框架自身也有復(fù)雜度

　　但是，框架本身也會帶來復(fù)雜度。相信大家在調(diào)研各種框架或?qū)W習各種框架時，會遇到學習曲線問題——有些框架會讓人一時不知如何上手。這里就抽象出一個問題，就是要做的應(yīng)用的復(fù)雜度與所使用的框架的復(fù)雜度的對比。 進一步說，是所要解決的問題的內(nèi)在復(fù)雜度，與所使用的工具的復(fù)雜度進行對比。

　　3、工具復(fù)雜度是為了處理內(nèi)在復(fù)雜度所做的投資

　　工具的復(fù)雜度是可以理解為是我們?yōu)榱颂幚韱栴}內(nèi)在復(fù)雜度所做的投資。為什么叫投資？那是因為如果投的太少，就起不到規(guī)模的效應(yīng)，不會有合理的回報。這就像創(chuàng)業(yè)公司拿風投，投多少是很重要的問題。如果要解決的問題本身是非常復(fù)雜的，那么你用一個過于簡陋的工具應(yīng)付它，就會遇到工具太弱而使得生產(chǎn)力受影響的問題。

　　反之，是如果所要解決的問題并不復(fù)雜，但你卻用了很復(fù)雜的框架，那么就相當于殺雞用牛刀，會遇到工具復(fù)雜度所帶來的副作用，不僅會失去工具本身所帶來優(yōu)勢，還會增加各種問題，例如培訓(xùn)成本、上手成本，以及實際開發(fā)效率等。

　　4、Pick the right tool for the job

　　“Pick the right tool for the job”——在國外，跟開發(fā)者討論一些框架選型問題時，大家都會說這句話——一切都要看場景。因為，前端開發(fā)原生開發(fā)或者桌面開發(fā)模式相比，有自己的獨特之處，它跟其實并不那么固定。在Web上面，應(yīng)用可以有非常多的形態(tài)，不同形態(tài)的Web應(yīng)用可能有完全不同程度的復(fù)雜度。這也是為什么我要談工具復(fù)雜度和所要做的應(yīng)用復(fù)雜度的問題。

　　5、怎么看前端框架的復(fù)雜度

　　目前的前端開發(fā)已經(jīng)越來越工程化，而我們需要解決的實際問題也是不同的。如下圖所示，我們可能在任何情況下都需要聲明式的渲染功能，并希望盡可能避免手動操作，或者說是可變的命令式操作，希望盡可能地讓DOM的更新操作是自動的，狀態(tài)變化的時候它就應(yīng)該自動更新到正確的狀態(tài)；

　　我們需要組件系統(tǒng)，將一個大型的界面切分成一個一個更小的可控單元；客戶端路由——這是針對單頁應(yīng)用而言，不做就不需要，如果需要做單頁應(yīng)用，那么就需要有一個URL對應(yīng)到一個應(yīng)用的狀態(tài)，就需要有路由解決方案；

　　大規(guī)模的狀態(tài)管理——當應(yīng)用簡單的時候，可能一個很基礎(chǔ)的狀態(tài)和界面映射可以解決問題，但是當應(yīng)用變得很大，涉及多人協(xié)作的時候，就會涉及多個組件之間的共享、多個組件需要去改動同一份狀態(tài)，以及如何使得這樣大規(guī)模應(yīng)用依然能夠高效運行，這就涉及大規(guī)模狀態(tài)管理的問題，當然也涉及到可維護性，還有構(gòu)建工具。

　　現(xiàn)在，如果放眼前端的未來，當HTTP2普及后，可能會帶來構(gòu)建工具的一次革命。但就目前而言，尤其是在中國的網(wǎng)絡(luò)環(huán)境下，打包和工程構(gòu)建依然是非常重要且不可避免的一個環(huán)節(jié)。

主流框架分析

　　我們看一下現(xiàn)有的一些主流框架從少到多所解決的問題。這個多少并不是來評價框架的好壞，而是從設(shè)計的角度出發(fā)看它涵蓋多少內(nèi)容。

純模板引擎：最少的就是純模板引擎，只管狀態(tài)到界面的映射。

React和Vue：其實這兩者都是非常專注的只做狀態(tài)到界面映射，以及組件。

Backbone：它會給你多一些架構(gòu)上指導(dǎo)，比如它會讓你分層。

Angular：它做的事情就更多，它有自己的路由，這些都會包含在里面。

Ember：相比Angular，Ember做得就更加徹底，Ember信奉的是約定優(yōu)于配置，它會將一切都幫你設(shè)計好打包好，你就開箱用就可以了。

Meteor：Meteor只是一個極端，它是從前到后全都包含，從前端到數(shù)據(jù)層到數(shù)據(jù)庫，全都幫你打包好。

　　通過簡單的分析，我們可以感受到，做得少的框架不一定就不如做得多的框架，這體現(xiàn)出一種取舍。也就是說，做得少的框架可以給你更多的靈活性，但你需要做更多的選擇；做得多的框架有更強的侵入性，學習成本更高，靈活性更低。一旦選擇了一個侵入性強的框架，那么一些小的部分你就沒有機會去切換成其他你更想用的方案。

　　所以，React和Vue有一個共同特點，它們都有各自的配套工具，核心雖然只解決一個很小的問題，但它們有生態(tài)圈及配套的可選工具，當你把他們一個一個加進來的時候，就可以組合成非常強大的棧，就可以涵蓋其他的這些更完整的框架所涵蓋的問題。

　　這樣的一個配置方案，使得在你構(gòu)建技術(shù)棧的時候有可彈性伸縮的工具復(fù)雜度：當所要解決的問題內(nèi)在復(fù)雜度很低的時候，可以只用核心的這些很簡單的功能；當需要做一個更復(fù)雜的應(yīng)用時，再增添相應(yīng)的工具。

　　例如做一個單頁應(yīng)用的時候才需要用路由；做一個相當龐大的應(yīng)用，涉及到多組件狀態(tài)共享以及多個開發(fā)者共同協(xié)作時，才可能需要大規(guī)模狀態(tài)管理方案。

　　一個純粹的復(fù)雜的單頁應(yīng)用，和只是在后端渲染的靜態(tài)頁面上嵌入交互內(nèi)容所需要選擇的工程棧其實是有相當大區(qū)別的。這就是為什么我覺得，核心+生態(tài)的棧會是一個在整體選型更為靈活的棧。

　　React和Vue都選擇這個模式。Facebook團隊只是專注做React本身，但React社區(qū)非常活躍，貢獻了大量的第三方解決方案。不可否認，React社區(qū)是當前最活躍的社區(qū)，很多優(yōu)秀的想法和思路，包括狀態(tài)管理方案最早都是從React社區(qū)萌發(fā)出來。但是社區(qū)的這種活躍也帶來一定程度的副作用，那就是時代變化太快，三天出一個新版本，同一個問題曾經(jīng)存在幾十種不同的解決方案。

　　這就使得我們在去搭建自己的棧時，需要花很多的時間去鑒別所選擇的部件。同時，由于整個生態(tài)圈的這些庫并不是由一個統(tǒng)一的團隊去規(guī)劃和設(shè)計的，所以很難考慮到不同的庫之間的協(xié)作，這就會導(dǎo)致磨合問題。

　　同時，這也使得很多開發(fā)者抱怨有一個“Java Fatigue”，說JS生態(tài)圈東西太多了，為了跟上潮流，需要不停學習最新的東西，覺得很累。當然，有很多人覺得這是生態(tài)圈繁榮的表現(xiàn)，但它確實使得大家面臨了選擇困難癥的問題。

　　Dan Abramov 是之前React社區(qū)非常活躍的開發(fā)者，已經(jīng)加入了React團隊。有一天他在推特上說，極度的模塊化使得他非常難去構(gòu)建一個統(tǒng)一的體驗。這句話指的就是，React生態(tài)圈整個棧的每一個部分來自不同開發(fā)者，想全部整合到一起的時就有很多零碎的問題。

　　這是他剛開始做React現(xiàn)在的官方的CLI的時候發(fā)出的感慨，他在試圖整合社區(qū)的各種東西放到一個架子里面，于是遇到了很多這樣的問題。我這里完全沒有否認React生態(tài)圈繁榮的意思，我只是覺得可以有另外一種選擇，那就是我們可以做一個漸進式框架，這就是Vue選擇的方向。

漸進式框架Vue.js

　　1、Vue.js現(xiàn)狀

　　以下數(shù)據(jù)可以體現(xiàn)出Vue.js的現(xiàn)狀。

前一段時間突破了三萬星，總下載量過百萬。

官網(wǎng)上每個月的用戶量為26萬，這個應(yīng)該是不包含中國區(qū)數(shù)據(jù)。官方開發(fā)者插件的周活躍用戶數(shù)在5萬5左右。這個數(shù)據(jù)是我覺得最有說服力的數(shù)據(jù)。安裝并且使用開發(fā)者插件的Vue用戶，應(yīng)該會在實際生產(chǎn)中真正頻繁使用Vue。

　　Google搜索趨勢的相關(guān)數(shù)據(jù)如下圖所示。圖中，綠色的是Backbone的數(shù)據(jù)，黃色是Ember，紅色是React，藍色是Vue。可以看出React和Vue近兩年發(fā)展勢頭都比較迅猛。

　　可以看出，Vue的曲線開始的是很早，2013年已經(jīng)開始，但是有很長一段時間的增長是比較低的。因為在那一段時間我還在谷歌工作，Vue基本上是作為個人項目在運營。在過去一兩年中，Vue獲得了非常大的突破性發(fā)展。這個圖里沒有Angular，因為Angular的量還是非常大的，如果放進去就破表了。

　　這些數(shù)據(jù)并不能絕對地代表框架當前的熱度，但有一定的參考價值。可以看到React的勢頭很足。而由Vue的曲線還可以看出它的增長速度還在不停上揚。

　　2、Vue的定位

　　我在做Vue的過程中也在不停地思考它的定位，現(xiàn)在，我覺得它與其他框架的區(qū)別就是漸進式的想法，也就是“Progressive”——這個詞在英文中定義是漸進，一步一步，不是說你必須一竿子把所有的東西都用上。

　　3、Vue的設(shè)計

　　接下來我們回到之前看的圖：

　　Vue從設(shè)計角度來講，雖然能夠涵蓋這張圖上所有的東西，但是你并不需要一上手就把所有東西全用上，因為沒有必要。無論從學習角度，還是實際情況，這都是可選的。聲明式渲染和組建系統(tǒng)是Vue的核心庫所包含內(nèi)容，而客戶端路由、狀態(tài)管理、構(gòu)建工具都有專門解決方案。這些解決方案相互獨立，你可以在核心的基礎(chǔ)上任意選用其他的部件，不一定要全部整合在一起。

　　4、Vue的實現(xiàn)

　　接下來深入講一講這些具體的概念以及Vue在這些概念上具體是做怎樣的實現(xiàn)。

　　（1）聲明式渲染

　　現(xiàn)在基本所有的框架都已經(jīng)認同這個看法——DOM應(yīng)盡可能是一個函數(shù)式到狀態(tài)的映射。狀態(tài)即是唯一的真相，而DOM狀態(tài)只是數(shù)據(jù)狀態(tài)的一個映射。所有的邏輯盡可能在狀態(tài)的層面去進行，當狀態(tài)改變的時候，View應(yīng)該是在框架幫助下自動更新到合理的狀態(tài)，而不是說當你觀測到數(shù)據(jù)變化之后手動選擇一個元素，再命令式地去改動它的屬性。

　　下圖是Vue的一個模板示例，如果沒有用過Vue的話，可以大概感覺到這是一個怎樣的概念。

　　其實，在模板語法上，Vue跟Angular是比較相似。在Vue1.0里面，模板實現(xiàn)跟Angular類似，如下圖所示，把模板直接做成在瀏覽器里面parse成DOM樹，然后去遍歷這個樹，提取其中的各種綁定。

　　在Vue2.0中，渲染層的實現(xiàn)做了根本性改動，那就是引入了虛擬DOM。

　　從架構(gòu)來講，Vue2.0 依然是寫一樣的模板（Vue2.0于前段時間發(fā)布，具體報道參見

　　https://t.cn/RVC0foZ）。在最左邊，Vue2.0跟1.0的模板語法絕大部分是兼容的。Vue的編譯器在編譯模板之后，會把這些模板編譯成一個渲染函數(shù)。而函數(shù)被調(diào)用的時候就會渲染并且返回一個虛擬DOM的樹。這個樹非常輕量，它的職責就是描述當前界面所應(yīng)處的狀態(tài)。當我們有了這個虛擬的樹之后，再交給一個patch函數(shù)，負責把這些虛擬DOM真正施加到真實的DOM上。

　　在這個過程中，Vue有自身的響應(yīng)式系統(tǒng)來偵測在渲染過程中所依賴到的數(shù)據(jù)來源。在渲染過程中，偵測到的數(shù)據(jù)來源之后，之后就可以精確感知數(shù)據(jù)源的變動。到時候就可以根據(jù)需要重新進行渲染。當重新進行渲染之后，會生成一個新的樹，將新樹與舊樹進行對比，就可以最終得出應(yīng)施加到真實DOM上的改動。最后再通過patch函數(shù)施加改動。

　　這樣做的主要原因是，在瀏覽器當中，Java的運算在現(xiàn)代的引擎中非常快，但DOM本身是非常緩慢的東西。當你調(diào)用原生DOM API的時候，瀏覽器需要在Java引擎的語境下去接觸原生的DOM的實現(xiàn)，這個過程有相當?shù)男阅軗p耗。所以，本質(zhì)的考量是，要把耗費時間的操作盡量放在純粹的計算中去做，保證最后計算出來的需要實際接觸真實DOM的操作是最少的。

　　下面看渲染函數(shù)。用過React的開發(fā)者可能知道，React是沒有模板的，直接就是一個渲染函數(shù)，它中間返回的就是一個虛擬DOM樹。JSX實際就是一套用于讓我們更簡單地去描述樹狀結(jié)構(gòu)的語法糖。

　　如下圖所示，在Vue2.0當中，可以看到就是說當比如左側(cè)的模板，經(jīng)過Vue的編譯之后就會變成右側(cè)的東西。

　　這個函數(shù)類似于創(chuàng)建一個虛擬元素的函數(shù)，我們可以給它一個名字，給它描述應(yīng)該有的屬性特性和可能其他的數(shù)據(jù)。然后后面這個最后這個參數(shù)是個數(shù)組，包含了該虛擬元素的子元素。總的來說2.0的編譯器做的就是這個活。

　　同時，在Vue2.0里，用戶可以選擇直接跳過模板這一層去手寫渲染函數(shù)，同時也有可選JSX支持。從開發(fā)者的偏好以及開發(fā)者的效益的角度來考量，模板和JSX是各有利弊的東西。模板更貼近我們的HTML，可以讓我們更直觀地思考語義結(jié)構(gòu)，更好地結(jié)合CSS的書寫。

　　JSX和直接渲染函數(shù)，因為是真正的Java，擁有這個語言本身的所有的能力，可以進行復(fù)雜的邏輯判斷，進行選擇性的返回最終要返回的DOM結(jié)構(gòu)，能夠?qū)崿F(xiàn)一些在模板的語法限制下，很難做到的一些事情。

　　所以在Vue2.0里，兩個都是可以選擇的。在絕大部分情況下使用模板，但是在需要復(fù)雜邏輯的情況下，使用渲染函數(shù)。在Vue2.0的路由和內(nèi)部的一些實踐上，都大量地應(yīng)用渲染函數(shù)做復(fù)雜的抽象組件，比如過渡動畫組件以及路由里面的link組件，都是用渲染函數(shù)實現(xiàn)的，同時還保留了它本身的依賴追蹤系統(tǒng)。

　　如下圖所示，Vue的依賴追蹤通過ES5的 Object.defineProperty 方法實現(xiàn)。比如，我們給它一個原生對象，Vue會遍歷這個數(shù)據(jù)對象的屬性，然后進行屬性轉(zhuǎn)換。每一個屬性會被轉(zhuǎn)換為一個 getter 和一個 setter。同時每個組件會有一個對應(yīng)的 watcher 對象，這個對象的職責就是在當前組件被渲染的時候，記錄數(shù)據(jù)上面的哪些屬性被用到了。

　　例如，在渲染函數(shù)里面用到A.B的時候，這個就會觸發(fā)對應(yīng)的 getter。整個渲染流程具體要點如下：

當某個數(shù)據(jù)屬性被用到時，觸發(fā) getter，這個屬性就會被作為依賴被 watcher 記錄下來。

整個函數(shù)被渲染完的時候，每一個被用到的數(shù)據(jù)屬性都會被記錄。

相應(yīng)的數(shù)據(jù)變動時，例如給它一個新的值，就會觸發(fā) setter，通知數(shù)據(jù)對象對應(yīng)數(shù)據(jù)有變化。

此時會通知對應(yīng)的組件，其數(shù)據(jù)依賴有所改動，需要重新渲染。

對應(yīng)的組件再次調(diào)動渲染函數(shù)，生成 Virtual DOM，實現(xiàn) DOM 更新。

　　這樣一個流程跟主流的一些框架，例如React是有較大區(qū)別的。在React中，當組件復(fù)雜的時候需要用 shouldComponentUpdate 做優(yōu)化。但是，它也有自己的各種坑，比如要確保該組件下面的組件不依賴外部的狀態(tài)。雖說這在大部分情況下是夠用的，但遇到極大復(fù)雜度的應(yīng)用，遇到性能瓶頸的時候，這個流程優(yōu)化起來也是相當復(fù)雜的一個話題。

　　如下圖所示，在Vue里面由于依賴追蹤系統(tǒng)的存在，當任意數(shù)據(jù)變動的時，Vue的每一個組件都精確地知道自己是否需要重繪，所以并不需要手動優(yōu)化。用Vue渲染這些組件的時候，數(shù)據(jù)變了，對應(yīng)的組件基本上去除了手動優(yōu)化的必要性。

　　（2）組件系統(tǒng)

　　相信基本上所有的現(xiàn)代框架都已經(jīng)走向了組件化道路，Web Components 從規(guī)范層面做這個實踐。主流框架都有各有不同的封裝，但核心思想都是一樣，把UI結(jié)構(gòu)映射到恰當?shù)慕M件樹。

　　在Vue中，父子組件之間的通信是通過 props 傳遞。從父向子單向傳遞；而如果子組件想要在父組件作用里面產(chǎn)生副作用，就需要去派發(fā)事件。這樣就形成一個基本的父子通信模式，在涉及大規(guī)模狀態(tài)管理的時候會有額外的方案，這個后面會提到。

　　Vue的組件引入構(gòu)建工具之后有一個單文件組件概念，如下圖所示，就是這個Vue文件。在同一個Vue文件里，可以同時寫 template、 和 style，三個東西放在一個里面。

　　同時，Vue的單文件組件和 Web Components 有一個本質(zhì)不同，它是基于構(gòu)建工具實現(xiàn)。這樣的好處是有了一個構(gòu)建的機會，可以對這些單文件組件做更多的分析處，在每一個語言塊里可以單獨使用不同的處理器，這點后面還會講到。

　　（3）客戶端路由

　　在做一個界面復(fù)雜度非常的高應(yīng)用時，它會有很多的狀態(tài)，這樣的應(yīng)用顯然不可能在每做一次操作后都刷新一個頁面作為用戶反饋。這就要這個應(yīng)用有多個復(fù)雜的狀態(tài)，同時這些狀態(tài)還要對應(yīng)到URL。

　　有一個重要的功能叫做 deep-linking，也就是當用戶瀏覽到一個URL，然后把它傳給另外的人或者復(fù)制重新打開，應(yīng)用需要直接渲染出這個URL對應(yīng)的狀態(tài)。這就意味著應(yīng)用的URL和組件樹的狀態(tài)之間有一個映射關(guān)系，客戶端路由的職責就是讓這個映射關(guān)系聲明式地對應(yīng)起來。

　　若要自己實現(xiàn)一個這樣的路由，看上去倒是很簡單，用hash去模擬一下，就可以自己很快地做出很簡單的路由。但事實上，客戶端路由涉及很多更復(fù)雜的問題，如下圖所示。

　　可能同一層的路由有多個不同的出口，還有著復(fù)雜的URL匹配規(guī)則，等等。這些問題如果都由自己去一一實現(xiàn)，那么復(fù)雜度是非常高的。而Vue基本都有對應(yīng)的解決方案（router.vuejs.org）。配合Webpack還可以實現(xiàn)基于路由的懶加載，一條路徑所對應(yīng)的組件在打包的時候，會分離成另外一塊，只有當該路由被訪問的時候，才會被加載出來。這有相應(yīng)的解決方案，同時也有實例。

　　（4）狀態(tài)管理

　　說到狀態(tài)管理，本質(zhì)上就是把整個應(yīng)用抽象為下圖中的循環(huán)。臉書最早提出 Flux 這個概念的時，也是一個很松散的概念，而且官方的實現(xiàn)本身做得很難用。所以，社區(qū)就做了各種各樣的探索。圖中的這三個東西是一個單向數(shù)據(jù)流，State 驅(qū)動 View 的渲染，而用戶對 View 進行操作產(chǎn)生 Action，會使State產(chǎn)生變化，從而導(dǎo)致 View 重新渲染。

　　一個單獨的Vue的組件，其實就已經(jīng)是這樣的結(jié)構(gòu)。但是當多個這樣的組件來配套的時候，就會遇到一個問題。每個組件都有它自己的狀態(tài)，但整個應(yīng)用的狀態(tài)，跟組件之間并不一定存在一一對應(yīng)的關(guān)系。這個狀態(tài)可能是一個全局狀態(tài)。那么狀態(tài)到底放在哪里？大部分解決方案是把這個狀態(tài)從組件樹中提取出來，放在一個全局的 Store 里面。Vuex 也是這樣做的，但是它是針對 Vue 做了特化。

　　我們看到最左邊就是Vue的組件，這些組件在大部分情況下，就不再有私有的狀態(tài)，而是從全局的 Store 里面獲取狀態(tài)。Actions 和 Mutations 比較難用一兩句話說清楚，大致就是當應(yīng)用狀態(tài)進行改變的時候，需要通過 Mutations 去顯式地觸發(fā)，而 Actions 則是負責異步和其他副作用。

　　由于 Mutations 會被記錄下來，我們可以把這些記錄發(fā)到工具里面去做分析，甚至進行回滾。當發(fā)現(xiàn)bug的時候，這使得我們可以更好地理解大型應(yīng)用中的狀態(tài)變化。更多的細節(jié)，還請看官方文檔（vuex.vuejs.org）。

　　（5）構(gòu)建工具

　　構(gòu)建工具方面，Vue有一個官方的，全局安裝的 vue-cli。這里有一個筆誤。全局安裝之后，我們就可以用 vue 命令創(chuàng)建一個新的項目，Vue 的 CLI 跟其他 CLI 不同之處在于，有多個可選模板，有簡單的也有復(fù)雜的。極簡的配置，更快的安裝，可以更快的上手。

　　它也有一個更完整的模板，包括單元測試在內(nèi)的各種內(nèi)容都涵蓋，但是，它的復(fù)雜度也更高，這又涉及到根據(jù)用例來選擇恰當復(fù)雜度的問題。所有的模板在創(chuàng)建之后，構(gòu)建腳本都是通過 npm 腳本來執(zhí)行，在國內(nèi)安裝 npm 依賴的時候有點卡，可以用 yarn 或者推薦用淘寶的 npm 鏡象源，可以很大地提升安裝速度。

　　之前提到了單文件組件，如下圖所示，支持任意的處理器，開箱即用的熱重載，所以組件都支持熱重載 (hot-reload)。當你做了修改，不會刷新頁面，只是對組件本身進行立刻重載，不會影響整個應(yīng)用當前的狀態(tài)。CSS也支持熱重載。

　　我們看下左下角，在使用這個預(yù)處理器的同時，我們只需要添加一個 scoped 特性，Vue 會通過對模板和CSS代碼的解析改寫，來模擬CSS的效果。同時單文件組件也支持懶加載，一個懶加載的組件和它的依賴會被打包成一個額外的包，只有被用到的時候才加載，這對首屏的加載速度也是很有幫助的。

　　如下圖所示，這個開發(fā)者工具本身也是用Vue寫的。

　　使用它的話可以看到我們當前應(yīng)用的組件樹結(jié)構(gòu)。

　　點擊組件，就可以觀察這個組件當前的狀態(tài)。也可以把這個組件發(fā)送到控制臺里。同時這個開發(fā)者工具還有一個 Vuex 面板，如果你用了 Vuex，那么每次操作都會被記錄下來，記錄下來的狀態(tài)之間可以進行跳轉(zhuǎn)。

　　除此之外，還支持把當前應(yīng)用的狀態(tài)快照發(fā)送給另外一個人，這個人可以在他的控制臺里導(dǎo)入你發(fā)送的狀態(tài)，就可以立刻跳轉(zhuǎn)到你之前所在的狀態(tài)。這對于重現(xiàn)一些 bug，或要描述當前狀態(tài)都很有幫助。

Vue2.0

　　Vue2.0在不久之前剛剛發(fā)布（具體報道參見https://t.cn/RVC0foZ），之前一些技術(shù)細節(jié)在前文中已有所涉及。Vue2.0相對于1.0的改進有以下幾點。

　　1、更輕

　　對Vue1.0大小壓縮，Vue2.0它有一個只包含運行時的版本，所有的模板在編譯的時候已經(jīng)完成了。基于這個版本，下圖中Vue、vue-router和vuex三個（都是 2.0 版本）加一起，跟Vue1.0的核心庫大小一樣。

　　2、更快

　　Vue2.0可以說是當前最快的框架之一。這個是基于第三方獨立測試的結(jié)果。有興趣的話，可以移步鏈接（https://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html）進行查看。

　　這個測試是一個比較綜合的測試，它對于各種操作，以及在大列表里面更新移除等，都有相當完整的覆蓋。可以看出，Vue2.0，不僅僅是在Vue1.0的基礎(chǔ)上有很大提升，相比其他框架，也有相當明顯的性能優(yōu)勢。

　　3、Vue2.0 架構(gòu)

　　下圖是Vue2.0的架構(gòu)圖，這里不深入講整個架構(gòu)的實現(xiàn)。

　　Vue2.0同時支持服務(wù)端，服務(wù)端渲染支持流式渲染。因為HTTP請求也是流式，Vue 的服務(wù)端渲染結(jié)果可以直接 pipe 到返回的請求里面。這樣一來，就可以更早地在瀏覽器中呈現(xiàn)給用戶內(nèi)容，通過合理的緩存策略，可以有效地提升服務(wù)端渲染的性能。

　　下圖是Vue2.0以及服務(wù)端渲染的相關(guān)內(nèi)容，基本上把所有的功能都整合在了一起，有興趣的同學可以在這里搜索2.0，它可以作為參考應(yīng)用。

　　除了服務(wù)端渲染還有原生渲染，這里的原生渲染是指阿里巴巴的項目Weex。在架構(gòu)層面，通過編譯一個 Weex 源文件（類似于 Vue 單文件組建的格式）然后運行。界面節(jié)點的操作都是抽象的，這些抽象操作會派發(fā)到不同的目標引擎做實際的渲染，同時支持 iOS, Android 和 Web。

　　Vue和Weex現(xiàn)在有一個合作，Vue 2.0 將會正式成為 Weex 的 Java 運行時。這樣的合作可以使得符合功能交集的Vue組件可以跨平臺使用。

今日薦號：前端之巔

　　這里有深度及時的前端資訊，一線經(jīng)驗免費的分享活動，純凈的前端技術(shù)微信群，只待你加入，一起攀登前端之巔！

今日薦文

點擊下方圖片即可閱讀

微信PaxosStore內(nèi)存云揭秘：十億Paxos/分鐘的挑戰(zhàn)

喜歡我們的會點贊，愛我們的會分享！