Vue2.0 中，「漸進式框架」和「自底向上增量開發的設計」這兩個概念是什麼？（轉）

https://www.zhihu.com/question/51907207?rf=55052497

徐飛

 

在我看來，漸進式表明的含義是：主張最少。

每一個框架都不可避免會有本身的一些特色，從而會對使用者有必定的要求，這些要求就是主張，主張有強有弱，它的強勢程度會影響在業務開發中的使用方式。

好比說，Angular，它兩個版本都是強主張的，若是你用它，必須接受如下東西：

- 必須使用它的模塊機制
- 必須使用它的依賴注入
- 必須使用它的特殊形式定義組件（這一點每一個視圖框架都有，難以免）

因此Angular是帶有比較強的排它性的，若是你的應用不是從頭開始，而是要不斷考慮是否跟其餘東西集成，這些主張會帶來一些困擾。

好比React，它也有必定程度的主張，它的主張主要是函數式編程的理念，好比說，你須要知道什麼是反作用，什麼是純函數，如何隔離反作用。它的侵入性看似沒有Angular那麼強，主要由於它是軟性侵入。

你固然能夠只用React的視圖層，但幾乎沒有人這麼用，爲何呢，由於你用了它，就會以爲其餘東西都很彆扭，因而你要引入Flux，Redux，Mobx之中的一個，因而你除了Redux，還要看saga，因而你要糾結業務開發過程當中每一個東西有沒有反作用，純不純，甚至你連這個均可能不能忍：

const getData = () => {
 // 若是不存在，就在緩存中建立一個並返回
 // 若是存在，就從緩存中拿
}

由於你要糾結它有外部依賴，一樣是不加參數調用，連續兩次的結果是不同的，因而不純。

爲何我一直不認同在中後臺項目中使用React，緣由就在這裏，我反對的是整個業務應用的函數式傾向，不少人都是看到有不少好用的React組件，就會傾向於把它引入，而後，你知道怎麼把本身的業務映射到函數式的那套理念上嗎？

函數式編程，無反作用，寫出來的代碼沒有bug，這是真理沒錯，可是有兩個問題須要考慮：

1. JS自己，有太多特性與純函數式的主張不適配，這一點，題葉能說得更多
2. 業務系統裏面的實體關係，如何組織業務邏輯，幾十年來積累了無數的基於設計模式的場景經驗，有太多的東西能夠模仿，可是，沒有人給你總結那麼多如何把你的厚重業務映射到函數式理念的經驗，這個地方很考驗綜合水平的，真的每一個人都有能力去作這種映射嗎？

函數式編程無bug的根本就在於要把業務邏輯徹底都依照這套理念搞好，你看看本身公司作中後臺的員工，他們熟悉的是什麼？是基於傳統OO設計模式的這套東西，他們覺得拿着大家給的組件庫就獲得了一切，可是可能還要被灌輸函數式編程的一整套東西，並且又沒人告訴他們在業務場景下，如何規劃業務模型、組織代碼，還要求快速開發，怎麼能快起來？

因此我真是心疼這些人，他們要的只是組件庫，卻不得不把業務邏輯的思考方式也做轉換，這個事情沒有一兩年時間洗腦，根本洗不到能開發業務的程度。

沒有好組件庫的時候，你們痛點在視圖層，有了基於React的組件化，把原先沒那麼痛的業務邏輯部分搞得也痛起來了，原先你們按照設計模式教的東西，照貓畫虎還能繼續開發了，學了一套新理念以後，都不知道怎麼寫代碼了，怎麼寫都懷疑本身不對，可怕。

我寧肯支持Angular也不支持React的緣由也就在此，Angular至少在業務邏輯這塊沒有軟主張，可以跟OO設計模式那套東西配合得很好。我面對過不少商務場景，都是前端很厚重的東西，不只僅是管理控制檯這種，這類東西里面，業務邏輯的佔比要比視圖大挺多的，如何組織這些東西，目前幾個主流技術棧都沒有解決方案，要靠業務架構師去擺平。

若是你的場景不是這麼厚重的，只是簡單管理控制檯，那當我沒說好了。

框架是不能解決業務問題的，只能做爲工具，放在合適的人手裏，合適的場景下。

如今我要說說爲何我這麼支持Vue了，沒什麼，可能有些方面是不如React，不如Angular，但它是漸進的，沒有強主張，你能夠在原有大系統的上面，把一兩個組件改用它實現，當jQuery用；也能夠整個用它全家桶開發，當Angular用；還能夠用它的視圖，搭配你本身設計的整個下層用。你能夠在底層數據邏輯的地方用OO和設計模式的那套理念，也能夠函數式，均可以，它只是個輕量視圖而已，只作了本身該作的事，沒有作不應作的事，僅此而已。

漸進式的含義，個人理解是：沒有多作職責以外的事。

 

 

http://www.infoq.com/cn/articles/vue-2-progressive-front-end-solution

 

前言：框架是什麼？爲何要有框架？在衆多的框架之中，Vue獨具魅力之處在哪裏呢？其背後的核心思想是什麼？Vue究竟火到什麼程度？最近發佈的Vue2.0又作了哪些改進呢？Vue和Weex又是怎樣的一種合做？

2016年10月20日，Vue Technology LLC 創始人， Vue.js做者尤雨溪在QCon上海作了題爲《Vue 2.0——漸進式前端解決方案》的演講，對上述問題一一進行了闡述。

1、爲何要有框架

1. 框架的存在是爲了幫助咱們應對複雜度

前端框架特別多，那麼爲何要有框架呢？我我的的見解是，框架的存在是爲了幫助咱們應對複雜度。當咱們須要解決一些前端上工程問題的時候，這些問題會有不一樣的複雜度。若是你用太簡陋的工具應對很是複雜的需求，就會極大地影響你的生產力。因此，框架自己是幫咱們把一些重複的而且已經受過驗證的模式，抽象到一個已經幫你設計好的API封裝當中，幫助咱們去應對這些複雜的問題。

2. 框架自身也有複雜度

可是，框架自己也會帶來複雜度。相信你們在調研各類框架或學習各類框架時，會遇到學習曲線問題——有些框架會讓人一時不知如何上手。

這裏就抽象出一個問題，就是要作的應用的複雜度與所使用的框架的複雜度的對比。

相關廠商內容

百度AI技能渠道體系首席研究員的重構分享

分仍是合？58到家訂單中心架構演進

架構優化！愛奇藝面對流量洪峯的三板斧

摩拜單車：如何經過機器學習等技術提升單車運營效率

如何基於AWS搭建大數據統計分析系統

相關贊助商

進一步說，是所要解決的問題的內在複雜度，與所使用的工具的複雜度進行對比。

3. 工具複雜度是爲了處理內在複雜度所作的投資

工具的複雜度是能夠理解爲是咱們爲了處理問題內在複雜度所作的投資。爲何叫投資？那是由於若是投的太少，就起不到規模的效應，不會有合理的回報。這就像創業公司拿風投，投多少是很重要的問題。若是要解決的問題自己是很是複雜的，那麼你用一個過於簡陋的工具應付它，就會遇到工具太弱而使得生產力受影響的問題。

反之，是若是所要解決的問題並不複雜，但你卻用了很複雜的框架，那麼就至關於殺雞用牛刀，會遇到工具複雜度所帶來的反作用，不只會失去工具自己所帶來優點，還會增長各類問題，例如培訓成本、上手成本，以及實際開發效率等。

4. Pick the right tool for the job

「Pick the right tool for the job」——在國外，跟開發者討論一些框架選型問題時，你們都會說這句話——一切都要看場景。由於，前端開發原生開發或者桌面開發模式相比，有本身的獨特之處，它跟其實並不那麼固定。在Web上面，應用能夠有很是多的形態，不一樣形態的Web應用可能有徹底不一樣程度的複雜度。這也是爲何我要談工具複雜度和所要作的應用複雜度的問題。

5. 怎麼看前端框架的複雜度

目前的前端開發已經愈來愈工程化，而咱們須要解決的實際問題也是不一樣的。

以下圖所示，咱們可能在任何狀況下都須要聲明式的渲染功能，並但願儘量避免手動操做，或者說是可變的命令式操做，但願儘量地讓DOM的更新操做是自動的，狀態變化的時候它就應該自動更新到正確的狀態；咱們須要組件系統，將一個大型的界面切分紅一個一個更小的可控單元；客戶端路由——這是針對單頁應用而言，不作就不須要，若是須要作單頁應用，那麼就須要有一個URL對應到一個應用的狀態，就須要有路由解決方案；大規模的狀態管理——當應用簡單的時候，可能一個很基礎的狀態和界面映射能夠解決問題，可是當應用變得很大，涉及多人協做的時候，就會涉及多個組件之間的共享、多個組件須要去改動同一份狀態，以及如何使得這樣大規模應用依然可以高效運行，這就涉及大規模狀態管理的問題，固然也涉及到可維護性，還有構建工具。如今，若是放眼前端的將來，當HTTP2普及後，可能會帶來構建工具的一次革命。但就目前而言，尤爲是在中國的網絡環境下，打包和工程構建依然是很是重要且不可避免的一個環節。

2、主流框架分析

咱們看一下現有的一些主流框架從少到多所解決的問題。這個多少並非來評價框架的好壞，而是從設計的角度出發看它涵蓋多少內容。

• 純模板引擎：最少的就是純模板引擎，只管狀態到界面的映射。

• React和Vue：其實這二者都是很是專一的只作狀態到界面映射，以及組件。

• Backbone：它會給你多一些架構上指導，好比它會讓你分層。

• Angular：它作的事情就更多，它有本身的路由，這些都會包含在裏面。

• Ember：相比Angular，Ember作得就更加完全，Ember信奉的是約定優於配置，它會將一切都幫你設計好打包好，你就開箱用就能夠了。

• Meteor：Meteor只是一個極端，它是從前到後全都包含，從前端到數據層到數據庫，全都幫你打包好。

經過簡單的分析，咱們能夠感覺到，作得少的框架不必定就不如作得多的框架，這體現出一種取捨。也就是說，作得少的框架能夠給你更多的靈活性，但你須要作更多的選擇；作得多的框架有更強的侵入性，學習成本更高，靈活性更低。一旦選擇了一個侵入性強的框架，那麼一些小的部分你就沒有機會去切換成其餘你更想用的方案。

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

這樣的一個配置方案，使得在你構建技術棧的時候有可彈性伸縮的工具複雜度：當所要解決的問題內在複雜度很低的時候，能夠只用核心的這些很簡單的功能；當須要作一個更復雜的應用時，再增添相應的工具。例如作一個單頁應用的時候才須要用路由；作一個至關龐大的應用，涉及到多組件狀態共享以及多個開發者共同協做時，纔可能須要大規模狀態管理方案。

一個純粹的複雜的單頁應用，和只是在後端渲染的靜態頁面上嵌入交互內容所須要選擇的工程棧實際上是有至關大區別的。這就是爲何我以爲，核心+生態的棧會是一個在總體選型更爲靈活的棧。

React和Vue都選擇這個模式。Facebook團隊只是專一作React自己，但React社區很是活躍，貢獻了大量的第三方解決方案。不能否認，React社區是當前最活躍的社區，不少優秀的想法和思路，包括狀態管理方案最先都是從React社區萌發出來。可是社區的這種活躍也帶來必定程度的反作用，那就是時代變化太快，三天出一個新版本，同一個問題曾經存在幾十種不一樣的解決方案。這就使得咱們在去搭建本身的棧時，須要花不少的時間去鑑別所選擇的部件。同時，因爲整個生態圈的這些庫並非由一個統一的團隊去規劃和設計的，因此很難考慮到不一樣的庫之間的協做，這就會致使磨合問題。

同時，這也使得不少開發者抱怨有一個「JavaScript Fatigue」，說JS生態圈東西太多了，爲了跟上潮流，須要不停學習最新的東西，以爲很累。固然，有不少人以爲這是生態圈繁榮的表現，但它確實使得你們面臨了選擇困難症的問題。

Dan Abramov 是以前React社區很是活躍的開發者，已經加入了React團隊。有一天他在推特上說，極度的模塊化使得他很是難去構建一個統一的體驗。這句話指的就是，React生態圈整個棧的每個部分來自不一樣開發者，想所有整合到一塊兒的時就有不少零碎的問題。這是他剛開始作React如今的官方的CLI的時候發出的感慨，他在試圖整合社區的各類東西放到一個架子裏面，因而遇到了不少這樣的問題。我這裏徹底沒有否定React生態圈繁榮的意思，我只是以爲能夠有另一種選擇，那就是咱們能夠作一個漸進式框架，這就是Vue選擇的方向。

3、漸進式框架Vue.js

1.Vue.js現狀

如下數據能夠體現出Vue.js的現狀。

• 前一段時間突破了三萬星（以下圖所示），總下載量過百萬。

• 官網上每月的用戶量爲26萬，這個應該是不包含中國區數據。官方開發者插件的周活躍用戶數在5萬5左右。這個數據是我以爲最有說服力的數據。安裝而且使用開發者插件的Vue用戶，應該會在實際生產中真正頻繁使用Vue。

Google搜索趨勢的相關數據以下圖所示。圖中，綠色的是Backbone的數據，黃色是Ember，紅色是React，藍色是Vue。能夠看出React和Vue近兩年發展勢頭都比較迅猛。能夠看出，Vue的曲線開始的是很早，2013年已經開始，可是有很長一段時間的增加是比較低的。由於在那一段時間我還在谷歌工做，Vue基本上是做爲我的項目在運營。在過去一兩年中，Vue得到了很是大的突破性發展。這個圖裏沒有Angular，由於Angular的量仍是很是大的，若是放進去就破錶了。

這些數據並不能絕對地表明框架當前的熱度，但有必定的參考價值。能夠看到React的勢頭很足。而由Vue的曲線還能夠看出它的增加速度還在不停上揚。

2. Vue的定位

我在作Vue的過程當中也在不停地思考它的定位，如今，我以爲它與其餘框架的區別就是漸進式的想法，也就是「Progressive」——這個詞在英文中定義是漸進，一步一步，不是說你必須一竿子把全部的東西都用上。

3. Vue的設計

接下來咱們回到以前看的圖：

Vue從設計角度來說，雖然可以涵蓋這張圖上全部的東西，可是你並不須要一上手就把全部東西全用上，由於沒有必要。不管從學習角度，仍是實際狀況，這都是可選的。聲明式渲染和組建系統是Vue的核心庫所包含內容，而客戶端路由、狀態管理、構建工具都有專門解決方案。這些解決方案相互獨立，你能夠在覈心的基礎上任意選用其餘的部件，不必定要所有整合在一塊兒。

4. Vue的實現

接下來深刻講一講這些具體的概念以及Vue在這些概念上具體是作怎樣的實現。

（1）聲明式渲染

如今基本全部的框架都已經認同這個見解——DOM應儘量是一個函數式到狀態的映射。狀態便是惟一的真相，而DOM狀態只是數據狀態的一個映射。以下圖所示，全部的邏輯儘量在狀態的層面去進行，當狀態改變的時候，View應該是在框架幫助下自動更新到合理的狀態，而不是說當你觀測到數據變化以後手動選擇一個元素，再命令式地去改動它的屬性。

下圖是Vue的一個模板示例，若是沒有用過Vue的話，能夠大概感受到這是一個怎樣的概念。

其實，在模板語法上，Vue跟Angular是比較類似。在Vue1.0裏面，模板實現跟Angular相似，以下圖所示，把模板直接作成在瀏覽器裏面parse成DOM樹，而後去遍歷這個樹，提取其中的各類綁定。

在Vue2.0中，渲染層的實現作了根本性改動，那就是引入了虛擬DOM。

從架構來說，Vue2.0 依然是寫同樣的模板，（Vue2.0於前段時間發佈，具體報道參見

http://t.cn/RVC0foZ）。在最左邊，Vue2.0跟1.0的模板語法絕大部分是兼容的。Vue的編譯器在編譯模板以後，會把這些模板編譯成一個渲染函數。而函數被調用的時候就會渲染而且返回一個虛擬DOM的樹。這個樹很是輕量，它的職責就是描述當前界面所應處的狀態。當咱們有了這個虛擬的樹以後，再交給一個patch函數，負責把這些虛擬DOM真正施加到真實的DOM上。在這個過程當中，Vue有自身的響應式系統來偵測在渲染過程當中所依賴到的數據來源。在渲染過程當中，偵測到的數據來源以後，以後就能夠精確感知數據源的變更。到時候就能夠根據須要從新進行渲染。當從新進行渲染以後，會生成一個新的樹，將新樹與舊樹進行對比，就能夠最終得出應施加到真實DOM上的改動。最後再經過patch函數施加改動。

這樣作的主要緣由是，在瀏覽器當中，JavaScript的運算在現代的引擎中很是快，但DOM自己是很是緩慢的東西。當你調用原生DOM API的時候，瀏覽器須要在JavaScript引擎的語境下去接觸原生的DOM的實現，這個過程有至關的性能損耗。因此，本質的考量是，要把耗費時間的操做盡可能放在純粹的計算中去作，保證最後計算出來的須要實際接觸真實DOM的操做是最少的。

下面看渲染函數。用過React的開發者可能知道，React是沒有模板的，直接就是一個渲染函數，它中間返回的就是一個虛擬DOM樹。JSX實際就是一套用於讓咱們更簡單地去描述樹狀結構的語法糖。

以下圖所示，在Vue2.0當中，能夠看到就是說當好比左側的模板，通過Vue的編譯以後就會變成右側的東西。

這個函數相似於建立一個虛擬元素的函數，咱們能夠給它一個名字，給它描述應該有的屬性特性和可能其餘的數據。而後後面這個最後這個參數是個數組，包含了該虛擬元素的子元素。總的來講2.0的編譯器作的就是這個活。

同時，在Vue2.0裏，用戶能夠選擇直接跳過模板這一層去手寫渲染函數，同時也有可選JSX支持。從開發者的偏好以及開發者的效益的角度來考量，模板和JSX是各有利弊的東西。模板更貼近咱們的HTML，可讓咱們更直觀地思考語義結構，更好地結合CSS的書寫。JSX和直接渲染函數，由於是真正的JavaScript，擁有這個語言自己的全部的能力，能夠進行復雜的邏輯判斷，進行選擇性的返回最終要返回的DOM結構，可以實現一些在模板的語法限制下，很難作到的一些事情。

因此在Vue2.0裏，兩個都是能夠選擇的。在絕大部分狀況下使用模板，可是在須要複雜邏輯的狀況下，使用渲染函數。在Vue2.0的路由和內部的一些實踐上，都大量地應用渲染函數作複雜的抽象組件，好比過渡動畫組件以及路由裏面的link組件，都是用渲染函數實現的，同時還保留了它自己的依賴追蹤系統。

以下圖所示，Vue的依賴追蹤經過ES5的 Object.defineProperty 方法實現。好比，咱們給它一個原生對象，Vue會遍歷這個數據對象的屬性，而後進行屬性轉換。每個屬性會被轉換爲一個 getter 和一個 setter。同時每一個組件會有一個對應的 watcher 對象，這個對象的職責就是在當前組件被渲染的時候，記錄數據上面的哪些屬性被用到了。

例如，在渲染函數裏面用到A.B的時候，這個就會觸發對應的 getter。整個渲染流程具體要點以下：

• 當某個數據屬性被用到時，觸發 getter，這個屬性就會被做爲依賴被 watcher 記錄下來。

• 整個函數被渲染完的時候，每個被用到的數據屬性都會被記錄。

• 相應的數據變更時，例如給它一個新的值，就會觸發 setter，通知數據對象對應數據有變化。

• 此時會通知對應的組件，其數據依賴有所改動，須要從新渲染。

• 對應的組件再次調動渲染函數，生成 Virtual DOM，實現 DOM 更新。

這樣一個流程跟主流的一些框架，例如React是有較大區別的。在React中，當組件複雜的時候須要用shouldComponentUpdate 作優化。可是，它也有本身的各類坑，好比要確保該組件下面的組件不依賴外部的狀態。雖然說這在大部分狀況下是夠用的，但遇到極大複雜度的應用，遇到性能瓶頸的時候，這個流程優化起來也是至關複雜的一個話題。

以下圖所示，在Vue裏面因爲依賴追蹤系統的存在，當任意數據變更的時，Vue的每個組件都精確地知道本身是否須要重繪，因此並不須要手動優化。用Vue渲染這些組件的時候，數據變了，對應的組件基本上去除了手動優化的必要性。

（2）組件系統

相信基本上全部的現代框架都已經走向了組件化道路，Web Components 從規範層面作這個實踐。主流框架都有各有不一樣的封裝，但核心思想都是同樣，把UI結構映射到恰當的組件樹，以下圖所示。

在Vue中，父子組件之間的通訊是經過 props 傳遞。從父向子單向傳遞；而若是子組件想要在父組件做用裏面產生反作用，就須要去派發事件。這樣就造成一個基本的父子通訊模式，在涉及大規模狀態管理的時候會有額外的方案，這個後面會提到。

<img _href="img://null" _p="true" data-cke-saved-src="/mag4media/repositories/fs/articles//zh/resources/23.jpg" src="https://res.infoq.com/articles/vue-2-progressive-front-end-solution/zh/resources/23.jpg" "="" width="550" rel="share" >

Vue的組件引入構建工具以後有一個單文件組件概念，以下圖所示，就是這個Vue文件。在同一個Vue文件裏，能夠同時寫 template, script 和 style，三個東西放在一個裏面。同時，Vue的單文件組件和 Web Components 有一個本質不一樣，它是基於構建工具實現。這樣的好處是有了一個構建的機會，能夠對這些單文件組件作更多的分析處，在每個語言塊裏能夠單獨使用不一樣的處理器，這點後面還會講到。

（3）客戶端路由

在作一個界面複雜度很是的高應用時，它會有不少的狀態，這樣的應用顯然不可能在每作一次操做後都刷新一個頁面做爲用戶反饋。這就要這個應用有多個複雜的狀態，同時這些狀態還要對應到URL。有一個重要的功能叫作 deep-linking，也就是當用戶瀏覽到一個URL，而後把它傳給另外的人或者複製從新打開，應用須要直接渲染出這個URL對應的狀態。這就意味着應用的URL和組件樹的狀態之間有一個映射關係，客戶端路由的職責就是讓這個映射關係聲明式地對應起來。

若要本身實現一個這樣的路由，看上去卻是很簡單，用hash去模擬一下，就能夠本身很快地作出很簡單的路由。但事實上，客戶端路由涉及不少更復雜的問題，以下圖所示。

可能同一層的路由有多個不一樣的出口，還有着複雜的URL匹配規則，等等。這些問題若是都由本身去一一實現，那麼複雜度是很是高的。而Vue基本都有對應的解決方案（router.vuejs.org）。配合Webpack還能夠實現基於路由的懶加載，一條路徑所對應的組件在打包的時候，會分離成另一塊，只有當該路由被訪問的時候，纔會被加載出來。這有相應的解決方案，同時也有實例。

（4）狀態管理

說到狀態管理，本質上就是把整個應用抽象爲下圖中的循環。臉書最先提出 Flux 這個概念的時，也是一個很鬆散的概念，並且官方的實現自己作得很難用。因此，社區就作了各類各樣的探索。圖中的這三個東西是一個單向數據流，State 驅動 View 的渲染，而用戶對 View 進行操做產生 Action，會使State產生變化，從而致使 View 從新渲染。

一個單獨的Vue的組件，其實就已是這樣的結構。可是當多個這樣的組件來配套的時候，就會遇到一個問題。每一個組件都有它本身的狀態，但整個應用的狀態，跟組件之間並不必定存在一一對應的關係。這個狀態多是一個全局狀態。那麼狀態到底放在哪裏？大部分解決方案是把這個狀態從組件樹中提取出來，放在一個全局的 Store 裏面。Vuex 也是這樣作的，可是它是針對 Vue 作了特化。咱們看到最左邊就是Vue的組件，這些組件在大部分狀況下，就再也不有私有的狀態，而是從全局的 Store 裏面獲取狀態。Actions 和 Mutations 比較難用一兩句話說清楚，大體就是當應用狀態進行改變的時候，須要經過 Mutations 去顯式地觸發，而 Actions 則是負責異步和其餘反作用。因爲 Mutations 會被記錄下來，咱們能夠把這些記錄發到工具裏面去作分析，甚至進行回滾。當發現bug的時候，這使得咱們能夠更好地理解大型應用中的狀態變化。更多的細節，還請看官方文檔（vuex.vuejs.org）。

（5）構建工具

構建工具方面，Vue有一個官方的，全局安裝的 vue-cli。這裏有一個筆誤。全局安裝以後，咱們就能夠用 vue 命令建立一個新的項目，Vue 的 CLI 跟其餘 CLI 不一樣之處在於，有多個可選模板，有簡單的也有複雜的。極簡的配置，更快的安裝，能夠更快的上手。它也有一個更完整的模板，包括單元測試在內的各類內容都涵蓋，可是，它的複雜度也更高，這又涉及到根據用例來選擇恰當複雜度的問題。全部的模板在建立以後，構建腳本都是經過 npm 腳原本執行，在國內安裝 npm 依賴的時候有點卡，能夠用 yarn 或者推薦用淘寶的 npm 鏡象源，能夠很大地提高安裝速度。

以前提到了單文件組件，以下圖所示，支持任意的處理器，開箱即用的熱重載，因此組件都支持熱重載 (hot-reload)。當你作了修改，不會刷新頁面，只是對組件自己進行馬上重載，不會影響整個應用當前的狀態。CSS也支持熱重載。咱們看下左下角，在使用這個預處理器的同時，咱們只須要添加一個 scoped 特性，Vue 會經過對模板和CSS代碼的解析改寫，來模擬CSS的效果。同時單文件組件也支持懶加載，一個懶加載的組件和它的依賴會被打包成一個額外的包，只有被用到的時候才加載，這對首屏的加載速度也是頗有幫助的。

以下圖所示，這個開發者工具自己也是用Vue寫的。

使用它的話能夠看到咱們當前應用的組件樹結構。

點擊組件，就能夠觀察這個組件當前的狀態。也能夠把這個組件發送到控制檯裏。同時這個開發者工具還有一個 Vuex 面板，若是你用了 Vuex，那麼每次操做都會被記錄下來，記錄下來的狀態之間能夠進行跳轉。除此以外，還支持把當前應用的狀態快照發送給另一我的，這我的能夠在他的控制檯裏導入你發送的狀態，就能夠馬上跳轉到你以前所在的狀態。這對於重現一些 bug，或要描述當前狀態都頗有幫助。

4、Vue2.0

Vue2.0在不久以前剛剛發佈（具體報道參見

http://t.cn/RVC0foZ），以前一些技術細節在前文中已有所涉及。

Vue2.0相對於1.0的改進有如下幾點。

1.更輕

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

2. 更快

Vue2.0能夠說是當前最快的框架之一。這個是基於第三方獨立測試的結果。有興趣的話，能夠移步連接（http://stefankrause.net/js-frameworks-benchmark4/webdriver-ts/table.html）進行查看。這個測試是一個比較綜合的測試，它對於各類操做，以及在大列表裏面更新移除等，都有至關完整的覆蓋。能夠看出，Vue2.0，不只僅是在Vue1.0的基礎上有很大提高，相比其餘框架，也有至關明顯的性能優點。

3. Vue2.0 架構

下圖是Vue2.0的架構圖，這裏不深刻講整個架構的實現。

Vue2.0同時支持服務端，服務端渲染支持流式渲染。由於HTTP請求也是流式，Vue 的服務端渲染結果能夠直接 pipe 到返回的請求裏面。這樣一來，就能夠更早地在瀏覽器中呈現給用戶內容，經過合理的緩存策略，能夠有效地提高服務端渲染的性能。下圖是Vue2.0以及服務端渲染的相關內容，基本上把全部的功能都整合在了一塊兒，有興趣的同窗能夠在這裏搜索2.0，它能夠做爲參考應用。

除了服務端渲染還有原生渲染，這裏的原生渲染是指阿里巴巴的項目Weex。

在架構層面，經過編譯一個 Weex 源文件（相似於 Vue 單文件組建的格式）而後運行。界面節點的操做都是抽象的，這些抽象操做會派發到不一樣的目標引擎作實際的渲染，同時支持 iOS, Android 和 Web。

Vue和Weex如今有一個合做，Vue 2.0 將會正式成爲 Weex 的 JavaScript 運行時。這樣的合做可使得符合功能交集的Vue組件能夠跨平臺使用。

身爲架構師的你是否還須要繼續不斷學習呢？若是你還想要有更廣闊的技術視野，那就來ArchSummit吧，100+實踐案例，1500+技術專家，Facebook、Twitter、LinkedIn、阿里、騰訊、百度、新浪、滴滴等知名企業來分享他們的一線實戰經驗。目前8折報名中，點擊閱讀原文連接，瞭解詳情。www.archsummit.com/bj2016/index.html?utm_source=infoqwechath5

---

感謝韓婷對本文的審校。

給InfoQ中文站投稿或者參與內容翻譯工做，請郵件至editors@cn.infoq.com。也歡迎你們經過新浪微博（@InfoQ，@丁曉昀），微信（微信號：InfoQChina）關注咱們。