[譯] State of Vue.js report 2017 中文版

時間 2019-11-17

標籤 state vue.js vue report 中文版欄目 JavaScript 简体版

原文原文鏈接

原文連接：https://www.monterail.com/state-of-vuejs-report

譯文出自：掘金翻譯計劃

Event Organizer：leviding

Translaters：sasa-m、altairlu、ParadeTo、ly525、zwwill、html5challenge、vxqqb

Reviewers：leviding、ParadeTo、PCAaron、vxqqb、zwwill、caoyi0905、JohnJiangLA、html5challenge、iFwu

本文永久連接：github.com/xitu/gold-m…

序

幾年前，Monterail 因其在 Ruby 和 Rail上的專業建樹，仍是一家享有盛譽的軟件開發商。不過如今看來，Monterail 和她的產品彷佛有點過期了。當咱們用 Ruby開發傳統多頁面應用程序時，很快意識到，隨着技術的進步和發展，許多好的開發實踐和規範已經發生了變化。因循守舊是沒法知足市場需求的，在2011年，咱們選擇了 Backbone.js 做爲咱們涉足的第一個 js 框架。咱們一直都積極地關注這個快速變化的世界，較早地採用了 Angular JS，並且對其很是精通。現在，新一代的基於組件的開發框架裏，咱們團隊已經研究了 React ( 包括 React Native ), Angula r( angular2 及以上)和使用最普遍的 Vue.js！javascript

熟悉的不必定是好的

那些要求用 Vue 開發應用程序的客戶在此以前，都沒有據說過 Vue。可當他們使用後，都對 Vue 的擴展性和能力留下深入印象，並但願在他們技術棧中包含 Vue。咱們認爲，不少公司之因此使用那些選擇有名的框架，並不是是由於全面考慮相關信息作出的決定，而只是由於那些框架比較出名和耳熟而已。他們並無意識到，名不見經傳的 Vue 結合了 Angular，React 的先進的部分，而且更加友好。html

爲何要作這份調查

當使用 Vue 後，咱們可以更有效率地交付更好的產品，更好地推進咱們的業務，使客戶更加滿意，咱們相信，Vue 值得關注並受到你們的喜好。正因如此，咱們決心開始向發者們和企業佈道，把 Vue 傳播到全世界；同時，咱們策劃了每週的 Vue-newsletter,組織了第一個 Vue.js 的國際性大會 VueConf，建立了 Vuelidate 和 Vue-mulitselect 等 Vue 庫。前端

你即將閱讀的這份報告咱們是佈道與宣傳 Vue 的另外一個里程碑。報告有三個主要目的。1.提供可信賴的 Vue 商業使用案例，讓任何人都可以一窺其它公司是如何使用 Vue；2.讓那些沒有據說 Vue 的人瞭解 Vue，並讓他們有足夠的理由來更加仔細瞭解這個框架；3.讓咱們再也不費力地說服客戶相信 Vue.js 已是一個成熟的解決方案，能夠幫咱們構建各種應用。vue

報告的內容

享受閱讀吧！html5

報告展現了從企業主和開發者的角度去看待 Vue。咱們調查了來自88個國家的1100多名行業專家，瞭解他們對於 Vue 的使用體驗，他們喜歡的特性和那些不喜歡的特性；咱們深刻採訪了6家公司，詢問他們想用 Vue.js 解決哪些問題；另外，爲了讓讀者對 Vue 近幾年的發展有一個全面的瞭解，咱們講述了 Vue.js 的歷史，以及框架的建立者尤雨溪對 Vue.js 將來的想法。java

報告的順利完成獲得了許多人的支持。他們分享他們的知識和經驗，給予了咱們莫大的幫助，僅僅由於他們想爲社區貢獻一份屬於本身的力量。react

感謝 Evan You（尤雨溪）。他從一開始就對這篇報告抱以熱情，並在建立報告過程的各個階段支持咱們。同時，Evan You（尤雨溪）還分享了對 Vue.js 將來和後期規劃相關的寶貴見解，並對個人的努力表示支持。android

感謝Vue.js的核心成員 Chris Fritz 和 Evan ，對咱們分析調查結果給予了很大的幫助。真的很榮幸！由於有了這樣的合做，咱們對最終的報告質量很是滿意。
webpack

很是感謝 Jacob Schatz, Sylvain Simao, Roman Kuba, Gilles Bertaux, Scott O’Brien, Erin Depew, Matt O’Connell 和 Yuriy Nemtsov。沒有大家花費間分享們們的故事，報告中的學習案例就不會存在。ios

主要貢獻者

Vue.js 的演變

你知道 Vue 第一次發佈是在何時嗎? 最初它甚至並不叫「Vue」。做者的首次提交是在 2013 年 06 月 27 日，那時項目叫「Seed」，轉瞬間，Vue.js 已經四歲了。「Seed」這個名字用了六個月，在 2013 年 12 月初，做者把它正式改名爲「Vue」。可是，Vue 的第一個對外的版本（0.8.0）在 2014 年 2 月才發佈，在那時候，Vue.js 還只關注 MVC 架構中視圖（View）部分。

Vue 具備幾方面重要的特性，使得它很容易被開發人員接受。 Vue 的模板語法風格很像 AngularJS，也有被 React 引入的基於組件的架構這樣，開發者能夠從兩者平滑地過渡到 Vue。我會把 Vue 想象爲一個繼承了父母（AngularJS，React）優秀基因的孩子，它本身也不斷地提高開發者的使用體驗。

也就在一年後，當時 Laravel 社區（一款流行的 PHP 框架的社區）首次使用 Vue，JS 社區纔對 Vue 愈來愈感興趣，也才真正的流行起來。幾個月以後，期盼已久的 1.0 版本終於發佈了，對於 Vue 來講，這是具備里程碑意義的一次版本發佈。

與此同時，vue-router（2015-08-18）、vuex（2015-11-28）、vue-cli（2015-12-27）相繼發佈，這意味着 Vue.js 從一個視圖層庫發展爲咱們如今所說的漸進式框架。

去年，備受期待的 2.0-alpha 版本發佈，它被完全重寫了，同時引入了一些新的概念，好比: Virtual DOM 和服務端渲染。可是，API 基本沒有變化，所以從 1.0 到 2.0 版本能夠平滑遷移。使用官方出品的遷移工具會幫助你完成遷移過程。

社區

在接近一年的時間裏，至今依然活躍的社區促使 Vue.js 成爲了 JavaScript 三大頂級框架之一，並且看起來並不會止步不前。

人們很是喜好 Vue。不要相信咱們帶有情感色彩的評估，看看這個數字：Vue 是 2016 年 GitHub 上 star 數最多的框架。

社區的興趣是很是濃厚的，當咱們啓動 Vue Newsletter 項目時，在幾分鐘內，便有數百人訂閱了。一直沒間斷的郵件通知，讓咱們感受本身就像 Instagram 的明星同樣（備受關注）。Newsletter 的第一期有 759 人訂閱，而到了 63 期，咱們的訂閱人數已差很少達 6000 人。每一期都是很難準備的，由於每週都產生不少和 Vue 相關的內容。天天都有高質量的教程、看法深入的文章以及我能想到的庫翻陳出新。有點瘋狂。這還不是所有，Vue 社區有一個活躍的論壇和一個聊天頻道，天天都有成百上千的開發者活躍在上面。

此外，咱們能夠發現，隨着開發者對 Vue 的興趣逐漸濃厚，全球不少公司開始關注 Vue。點擊 Vue.js Jobs，看看他們發佈的的職位吧。

生態

值得一提的是，除了社區項目以外，Vue 核心開發團隊也維護了一些官方庫，好比 vue-router、vue-loader、vuex（狀態管理庫）、vue-rx 以及針對 RxJS 開發的 vuex-observable。還有一些工具庫，好比 vue-cli、vue-server-renderer、vue-loader、vetur、vue-migration-helper。它們爲何重要? 由於這樣，你就能夠漸進式地使用其餘核心庫，這些庫能夠完美配合，使得 Vue 轉變爲一個像 Angular、Ember 同樣完善的框架。固然，若是你的項目須要，你能夠隨時將其中的一部分切換爲其它非官方的解決方案。官方庫的另一個好處是它們每每表明着高質量、長期支持以及與 Vue 良好的兼容性。

正如你們所料，像 Vue 社區這種大型並且參與感高的社區，會出現大量社區項目不只僅是小型項目、解決單一問題的庫，咱們如今來談談大型項目舉個例子，Nuxtjs 是一個頗有想法的基於 Vue 的框架，它採用了一些小工具庫以及設計模式，這使得開發須要服務端渲染的應用變得極其簡單。

Quasar 框架能夠幫助開發複雜的移動和桌面應用。還有其餘流行的UI框架，好比：Element-UI 和 Vuetify，這些框架提供了幾十個風格統一的 UI 組件來幫助你開發 Vue。在移動端開發方面，獲得了 OnsenUI （由Monaca開發）和 NativeScript 的大力支持。

從我做爲一個 Web 開發者的角度來看，我能夠向你保證 Vue 已經有你開發應用所需的一切了。每週，我都見證愈來愈多的庫發佈，以致於沒有辦法追蹤全部的庫。你能夠在 awesome-vue 找到這些庫。此外，Vue 核心開發團隊在 Vue Curated 管理了一些推薦的庫，這些庫主要用於表單驗證、國際化、AJAX 等常見的任務，避免開發者在選擇合適的庫出現選擇恐懼症。

支持

許多人指出，和 Angular 或 React 不一樣的是，Vue 背後沒有大公司的支持，並且看起來這也不太樂觀我毫不贊成。Vue 和 jQuery、Babel、webpack 以及 JS 世界中其它可被信賴的工具同樣體現了真正的開源精神。這樣有一個明顯的優點：這些項目不用去知足這些公司的特定需求，取而代之的是更專一社區的需求。

Vue 實現了不少社區最須要的功能提及 code spliting，webpack 核心開發團隊成員 Sean Larkin，這樣評價 Vue：

首個使用 webpack 來提升開發者體驗的框架。

但在開發體驗上已經遠遠超越 webpack，並且體驗在各個方面: 易用性、無縫集成、優秀的文檔、總體的可擴展性。

顯而易見，Vue.js 和不少其它開源項目同樣，剛開始是一個我的做品。慢慢地，它擁有了一個全職核心團隊，專門負責維護它的各個方面和生態系統。

基金會呢? 近兩年，經過在 Patreon 和 Open Collective 上的成功運做，全球的不少我的和公司決定每月固定贊助尤雨溪（Vue 做者）和核心團隊超過 10000 美圓。這樣，尤雨溪就能夠全職從事 Vue 的開發了。

贊助者包括許多公司和幾百位我的贊助者。在這裏能夠看到這些贊助者們。

成長

讓咱們經過一組數字來更直觀地感覺到 Vue 生態的快速成長。

以 GitHub 的 star 數爲例，儘管它不是衡量一個項目知名度的完美指標。但開發者們很興奮，並且這份興奮使得 Vue 成爲 2016 年 Github 上得到 star 數最多的項目。不限於 JavaScript 或者前端分類，在2016年，它是得到star數最多的項目。過了一段時間，到如今爲止，它已是 star 數第二多的前端框架了，僅次於 React。同時，它也是 GitHub 上 star 數第六多的項目，已經超過了 jQuery 和 Angular。

2016 年前端調查顯示: Vue 是用戶滿意度最高的語言之一，89% 使用過 Vue 的開發者表示會再次使用 Vue。

固然，還有其餘指標來衡量諸如 npm 上每月的下載量（大約 800k），開發者工具每週活躍用戶數達到 270k。npm 上的下載量相比 React 的下載量相差很小。但值得一提的是：在過去的十二月，Vue 的下載量增加了 5 倍。以 Vue 如今的增幅，我相信在將來幾年，這個數字將會以更快的速度增加。

事實上很大一部分的增加是由於愈來愈多的公司選擇 Vue 做爲主要的前端框架。除此以外，開發者們很欣賞 Vue 平滑的學習曲線、集成到現有的技術棧的便捷，以及頂尖的性能。也許最重要的因素是提高開發效率和減小維護成本。換句話說，選擇 Vue，省錢。

但不要只信個人一家之言。爲此，咱們對來自 88 個國家的 1126 位開發者作了調研，並收集了一系列來自不一樣行業的採用 Vue 的案例。

使用 Vue.js 的開發者調研報告

咱們很好奇軟件開發者以及技術主管們都是如何看待並使用 Vue.js 的，所以咱們分發了一份網上問卷給他們，其中列舉了如下這些問題：

爲什麼要將 Vue 加入大家的技術棧？
使用該框架能帶來哪些好處？
若是考慮在項目中使用 Vue 的話，大家會主要擔憂哪些問題？
大家使用哪些資源以便熟練地使用 Vue.js？
大家的同事中有多少也在用 Vue？大家以爲在將來一年裏這我的數會上升嗎？
大家和大家的團隊分別使用 Vue.js 多久了？
大家公司還使用過哪些其它的先後端技術？

報告的數聽說明

該報告中的全部數據來源於咱們在 2017 年的八月至九月進行的一次爲期四周的調研。咱們總共收到了 1,126 份問卷回覆，大多來自於使用 Vue 的組織中的技術主管及軟件開發者們（94.1% 的問卷回覆者都承擔相關的技術工做）。這些回覆者們來自世界各大洲（除了南極洲），總共 88 個國家。

咱們在撰寫該報告的同時還針對一些調研結果諮詢了 Vue 的創始人尤雨溪以及 Vue 的核心成員 Chris Fritz，他們爲咱們提供了一些獨到的觀點並分享了更深遠的洞見。

主要觀點

96% 的調研回覆者表示會在他們的下一個項目中繼續使用 Vue.js。
94% 的回覆者使用官方 Vue 文檔做爲他們瞭解該框架的主要資源。
81% 的回覆者說 Vue 的集成很方便，這是他們在本身組織中的技術棧裏推行它的一個主要好處。
54% 的回覆者相信在將來 12 個月裏，Vue.js 會在本身的組織中變得愈發流行。

調研問卷中的問題

將 Vue.js 加入技術棧中的最主要緣由是？

無論開發者們新建仍是接手已有的項目，他們基本一致地認爲：Vue.js 很容易上手，哪怕是對於一個很是複雜的應用而言。他們評論說集成 Vue.js 很容易，緣由在於它使用簡單、架構優雅、同時設計精巧。不只如此，他們還在將其與其它主流框架對比後聲稱 Vue 更輕量、性能更優，是毋庸置疑的勝者。總的來講，超過半數的問卷回覆者都認爲 Vue.js 是個對入門者至關友好的框架。

將 Vue.js 加入技術棧中的最主要緣由

Vue.js 上手很容易 59%
技術棧須要更新了 22%
團隊想嘗試下這個框架 10%
其它緣由 9%

很適合用於現有的或者新項目，並且用起來很容易！

—— 技術主管，大企業，法國

集成進現有應用中，或者實現個純單頁應用都很方便。

—— 軟件開發，中型企業，澳洲

你和你的團隊考慮將 Vue.js 加入技術棧的時候會有哪些顧慮？

對於這個提問，回覆者們提到了兩個主要擔憂的問題。首先的一點是關係到本身團隊成員的，45% 的回覆者都表示，這些成員們 缺少 Vue 的相關經驗 ，而這會是他們在考慮將 Vue.js 加入技術棧的時候可能面臨的問題。

考慮將 Vue.js 加入技術棧時的顧慮 該題爲多項選擇，於是結果總和超過 100%

同事們缺乏 Vue.js 相關經驗 45%
不肯定該框架的將來趨勢 45%
缺乏成熟的相關原生應用開發平臺 23%
對該框架的擴展性有所顧慮 15%
其它顧慮 12%

Vue 在手機上的支持是在持續提升的。如今 Vue 已經提供了對 Progressive Web Apps 的強大支持，這其中包括了咱們提供的可靠模板。社區項目中像是 Onsen UI 就簡化了構建類 native 的 hybrid UI 的過程。

—— Chris Fritz，Vue.js 的核心開發

咱們如今就有 Weex 和 NativeScript（譯者補充：來支持開發原生應用）, 但咱們也認可這二者都有不少改善空間。Weex 其實被阿里巴巴用以線上開發已經很長一段時間了，也是其在手機開發領域上的主要選擇。但 Weex 欠缺了一些英文文檔和學習資料。爲了彌補這一點，咱們也已準備在接下來一年內提供官方指南，幫助你們使用 Vue 來開發 Weex。（譯者補充：現已有官網教程）

NativeScript 也是個很成熟的技術了，雖然它和 Vue 的集成還相對年輕，但天天進展飛速，使人印象深入。因此若是你對使用 Vue 來開發原生應用有興趣的話請必定要關注下。

—— 尤雨溪，Vue.js 創始人

缺乏成熟的原生應用開發平臺 也被相近比例的回覆者提到，這也是他們在將 Vue.js 加入技術棧前的顧慮。

有 172 個被調研者勾選了對 Vue.js 擴展性的顧慮，這使得該選項成爲五個阻礙着開發者們擁抱 Vue.js 的主要緣由之一。

Vue 的開發是基於組件化模型的，這也是如今全部主流框架中共享的一種適用於 UI 開發的設計模式。對於單頁應用，Vue 提供了官方支持的路由庫，也支持大規模狀態管理。Vue 的設計初衷是輕量級易上手，但支持規模化也被咱們設計在案。

現已有不少成功的大規模項目是使用 Vue 打造的，有些甚至由幾百個組件構成還照樣運轉得很順利。另外值得一提的是，一些現有的大規模應用都在用 Vue 重寫，咱們收到了來自這些應用開發者們很是確定的反饋，好比 Adobe Portfolio 和 JSFiddle。

—— 尤雨溪

使用 Vue.js 給你的組織帶來的最大好處是哪些?

81% 的開發者都強調了 Vue.js 的易於集成，這個比例很驚人。大多數回覆者都談到要想熟練掌握 Vue 很容易，並且比起其它主流框架來講更容易。他們還稱讚其與後端框架集成也不復雜。

60% 的開發者還提到 Vue 的文檔是其亮點。差很少比例的回覆者（56%）認爲該框架的性能優異是其最大的優點。

Vue 最大的優點 多項選擇，結果總和超過 100%

易於集成 81%
文檔詳盡 60%
性能優異 56%
與時俱進 49%
社區活躍 29%
其它優點 4%

Vue.js 的學習曲線很平緩，不少人所以產生興趣。

—— 高級開發，中型企業，新西蘭

咱們以前在 React 和 Vue 之間進行過抉擇，最後咱們選擇了 Vue，至今咱們都很慶幸咱們的選擇。

—— 軟件開發，中型企業，美國

Vue.js 使得前端開發容易管理也易擴展。它的學習成本也不高，這使得後端開發們也不須要太多指導就能清楚前端這邊的工做。由於如今已經有不少好用的 webpack 相關配置，使用 Vue 如今有點像是裝個插件同樣。最後說一點，運行時和編譯時咱們都能使用 Vue.js，它真的是個很棒的工具，不管是對於小型的應用來講仍是大型應用而言，想要擴展都不太難。

—— 軟件開發，小公司，菲律賓

有哪些建議是你想對 Vue.js 提的嗎？

對於這個開放式問題，咱們收到了 481 份有效回答。因爲有些建議被 20 多人提到了，所以咱們決定列舉幾項比較共性的建議，再開放個單選題。

缺少 Vue 相關的原生開發解決方案是幾個最大的問題之一，24% 的回覆者都同時提到了這點。毫無疑問地，Vue.js 須要更先進完善的移動端解決方案。

15% 回答這個問題的都指出 Vue 還有個不足是其生態環境相對較小。若是其生態環境能更強大的話，它必定能孕育出更爲優秀的組件庫。

除此以外,

隨着下一版 CLI 的更新，Vue 的工具也會獲得改善，尤雨溪如此保證。

在這些回覆中，還有人提到說 Vue 缺乏一些官方教程（一個回覆者稱爲《 Vue 聖經》），或者一份能提供更多現實案例，特別是針對複雜應用的指導手冊。Christ Fritz 指出，

如今已經發布的官方風格指南某種程度上來講可做爲 Vue 聖經，但在開展調研那時還沒提供。

同時還有個建議是， 該框架須要一份更完善的文檔。有 53 個回覆者提到了和該建議直接相關的一些問題（好比建議多提供些用 Vue 構建一個大型應用的架構設計文檔），以及和該建議並不直接相關的問題，好比一些他們錯誤地認爲不能用 Vue 解決的問題。有兩個問題被 20 多個回覆者都指出了，一個是須要增強測試工具，另外一個是須要優化核心庫。

對 Vue.js 的建議

須要更先進完善的 Vue 原生應用客戶端解決方案 116票
須要更強大的生態環境，能提供更優秀的組件庫和工具組 74票
須要官方教程以及其它相關學習資源，以期提供更多現實案例和最佳實踐（特別是複雜應用相關的） 67票
須要更完善的文檔，以便更順利地開發應用 53票
須要更棒的測試工具和庫 37票
優化核心庫 21票

咱們將在十一月起認真撰寫使用手冊，以便爲構建大型應用、通用集成方案、架構設計探索等問題提供示例。

—— Chris Fritz

開發下一個項目時，你有多大可能會再次使用 Vue？

超過 95% 的回覆者聲稱他們在下一個項目中還會使用 Vue。許多開發者明確表示他們使用過該框架後，以前的顧慮都再也不是問題。即便他們仍是指出了它的一些不足和值得改進之處，但幾乎全部人在用過該框架後都對其稱讚有加。同時絕大多數回覆者選擇在下一個項目中依然使用 Vue。

在下一個項目中會使用 Vue 的可能性

5（很是高）82.9%
4 12.5%
3 3.5%
2 1%
1（很是低）0.1%

你所在的組織機構使用 Vue.js 有多久？

隨着 Vue 社區的逐步壯大，精心打造的相關項目在世界各地層出不窮，同時它也躋身於 GitHub 上星數排名前十的倉庫列表，Vue 越來越受到廣泛認同。超過 3/4 的回覆者在近一年內將 Vue.js 加入了他們的技術棧中。

咱們能夠預見在將來幾年內使用 Vue 的開發者數量會飛速上漲，同時該框架自身也在不斷變得成熟，其生態環境將不斷強大，也會有愈來愈多的使用案例。

你所在的組織機構使用 Vue.js 有多久？

少於 6 個月 45%
6–12 個月 34%
1–2 年 19%
超過 2 年 2%

學習 Vue.js 時你會使用哪些資源？

官方 Vue 文檔是最廣泛使用的參考資源。 94% 的軟件開發者都勾選了它，這也說明了，一份深思熟慮後發佈的文檔是學習任何框架的主要資源。另外，70% 受調研的軟件開發者還選擇了線上文獻、技術博客、一些社區像是 StackOverflow 或者官方 Vue 論壇等做爲知識來源。線上課程受到了 41% 開發者的青睞，而選擇了在職培訓、相關書籍的只佔 1/4 不到。

Vue.js 的學習資源 多項選擇，結果總和超過 100%

官方文檔 94%
線上文獻及博客 78%
線上社區（好比 StackOverflow、Vue 官方論壇） 72%
線上課程 41%
在職培訓 22%
書籍 12%
其它 5%

你以爲你所在的組織機構中使用 Vue.js 的員工比例會在一年內增加嗎？

54% 的回覆者相信 Vue.js 在將來一年中，將在其組織裏變得愈發流行。 然而那些在大型企業（超過 1,000 員工）工做的開發人員更確信 Vue 在其公司會被普遍接受：76% 的受調研者勾選了贊同。

使用 Vue.js 的員工比例會上升嗎

5（絕對會）33%
4 21%
3 24%
2 11%
1（絕對不會）11%

公司的其它項目都打算使用 Vue（甚至已經開始用了）。

—— 軟件開發，大型企業，法國

咱們在瘋狂擴招，有很是多的項目將要涌現。這些項目都會使用 Vue.js 來開發。

—— 技術總監，大型企業，德國

你主要使用的前端技術和框架是哪些？

主要使用的前端框架 多項選擇，結果總和超過 100%

Vue.js 33%
Angular 21%
ReactJS 24%
其它 11%
Backbone 6%

你主要使用的後端技術與框架是？

主要使用的後端語言與框架 多項選擇，結果總和超過 100%

PHP 53%
Node.js 45%
Java 18%
C#/.Net 17%
Python (Django、Flask等框架) 17%
Ruby (Rails等框架) 10%
其它 8%

受調研人員數據

咱們對來自 88 個國家的 1,126 名熟悉 Vue 的軟件開發者、CTO、以及其餘相關技術人員進行了調研。

公司規模（員工數量）

小型企業（少於 100 人）77%
中型企業（100-999 人）15%
大企業（超過 1000 人）8%

團隊規模（組員數量）

小團隊（2-10 人）73%
個企 17%
中型團隊（11-25 人）8%
大型團隊（超過 25 人）2%

在組織中擔任的職能

軟件開發 66%
技術主管 20%
其餘技術人員 8.5%
項目經理 4%
其餘 1.5%

案例研究

起草這份關於 Vue.js 現狀的報告，是想經過大量的數據來證實，Vue 已被不一樣種類、不一樣規模的公司採用，已然成爲了一門成熟的技術。每個研究案例都證實了 Vue 是足以應對商業用途的。咱們採訪了六家公司，他們都曾面臨着選擇一套合適框架的挑戰，即便他們處在不一樣的發展階段，也有着不一樣的目標，可是他們最終都選擇了 Vue。

在 Codeship 和 Vue 結合以前，他們的用戶忍受着卡頓甚至是瀏覽器崩潰。太多的用戶對他們的應用程序心有不滿。他們的故事很好地證明了，Vue 能夠有效地幫助構建安全、可靠、易維護且具備防護性的應用程序。

若是你正在尋找 Vue.js 的優秀企業級案例，那麼 Behance 和 Adobe Portfolio 的案例就能夠派上用場。他們的團隊使用 Vue 零基礎地創建了兩個獨立的產品，並且不會止步於此。

在 Livestorm 案例中，Livestorm 聯合創始人兼 CEO Gilles Bertaux 描述了他們如何從零開始創造一個可盈利的產品。得益於 Vue 及其可複用的組件，他們的開發速度更快也更容易。

GitLab 的前端 Leader Jacob Schatz 解釋了爲何他們決定從 jQuery 技術轉移到 Vue.js，同時分享了他們遇到的主要挑戰。他們專一於更好的 UX （用戶體驗），這使得他們的產品更爲理想，銷量也所以提高了。

Chess.com 則不得不處理 Angular 1 項目中難以維護的遺留代碼。他們發現，Vue.js使得 15 位遠程開發人員的團隊協做更容易。Chess.com 是一個服務全球 1900 萬用戶且擁有大規模基礎設施的平臺。在他們的案例中，你將瞭解 Vue.js 是如何化解了他們的難題。

最後一個案例與其餘案例大有不一樣。墨爾本 Clemenger BBDO 的技術主管 Sylvain Simao 介紹瞭如何用 Vue.js 開發 4 到 12 周的短時間項目。應對緊張的交付週期、大量的動畫和特效須要實現、活動頁面的高性能要求是他們面臨的最大挑戰。

Behance 和 Adobe Portfolio

Behance 是展現和發現創意做品類在線平臺中的引導者。 Adobe Portfolio 可讓（用戶）打造本身專屬創意做品展現網站的定製平臺。

咱們曾由於當時並無太多大公司使用 Vue 而猶豫。可是，每當我遇問題（一般都是由於個人多慮），Vue均可以很容易的解決，這讓我感到驚喜。

—— Erin Depew， Behance 軟件工程師 Yuriy Nemtsov， Behance 軟件工程師兼經理 Matt O'Connell， Adobe Portfolio 軟件工程師

挑戰

從自產解決方案轉移到開源技術。保持良好的用戶體驗和高性能。可以在其餘團隊和項目之間共享組件。

解決方案

將 Behance 和 Adobe 前端團隊轉型到 Vue.js。使用 Vue.js 來遷移現有的代碼庫。

成果

能夠不緊不慢地遷移網站，而無需從頭開始。輕鬆整合現有代碼庫。高性能，低成本。

挑戰

Behance 是 Adobe 旗下的一家子公司，多年來他們一直在利用最新的技術和設計思想創造可以聯結並壯大創意世界的革命性的產品。

該團隊已決定使用開源框架，由於他們開始受限於目前已經使用的自產技術。

Yuriy 解釋說，在 Vue 以前，咱們一直在使用自主研發的一個 MVC 框架，它依賴於 Hogan.js（mustache）和 jQuery。咱們的框架沒法以聲明方式渲染 DOM，這迫使咱們只能手動同步數據到 DOM 上。它也沒法將功能抽離成組件，控制單向數據流，也沒有全面的文檔。因此儘管已經使用了幾年，咱們仍是決定轉向一個可讓咱們可以快速構建，減小出錯，下降成本，快速上手的技術方案。

Mustache 對咱們特別重要，由於當時咱們在先後端使用了相同的模板（如今多數 behance.net 的項目中依然如此）。利用 Mustache 將首屏快速提供給瀏覽器對於咱們和用戶都是很是重要的。若是咱們等待瀏覽器下載 JS，解析，編譯和執行它，而後纔將頁面顯示給用戶，要想達到與使用 Mustache 時一樣的速度是很是困難的。咱們也特地尋找過具備服務器端渲染功能的框架。

對於 Behance 團隊，首要目標是構建一個易用的代碼庫，併爲從此添加的新功能打下堅實的基礎。

我認爲咱們面臨的最大挑戰就是，因爲咱們決定不拆分咱們的代碼庫並從一個新平臺開始，咱們不得不花費大量的時間抽離舊的代碼來造成新的組件。Erin 補充說，既要用 Vue 重構舊代碼並保證網站其他功能正常運行，又要實現新功能，如何權衡這兩件事確實是個挑戰。

咱們很是重視 Behance 的性能，因此咱們很是當心，以確保在遷移代碼庫的同時保持性能指標。

對於 Matt 和他的團隊來講，用戶體驗也是很重要的一點，而且有很大的改進空間。

關於 Adobe Portfolio，咱們一開始使用 nbd.js，這是一個從本來咱們已經再也不維護的產品中提取出的 Backbone 自定義版本，稱爲「在線操做」，咱們用它來構建 Behance 網絡的模塊。Matt 補充說，它對反應式系統有限制，所以咱們使用 Ractive 構建了「反應性」部分。

就 Behance 的狀況來講，迄今爲止最大的挑戰就是，在複雜的用戶數據狀態管理下保持快速的用戶體驗，同時保證站點的內容和樣式的即時反饋。

解決方案

Adobe Portfolio 和 Behance 從新培訓其現有的團隊使他們能夠在平常工做中使用 Vue.js，而不是從新組建一個只關注於 Vue.js 的新團隊。

在咱們切換到 Vue 以前，絕大多數的團隊都在這裏。一旦咱們決定採用 Vue，咱們須要一些小項目來練手。對咱們來講，只須要很是小，只有前端功能且不公開訪問的站點便可，就像咱們的樣式指南。這樣，咱們能夠學習如何使用 Vue，如何編寫測試，並相對安全地對組件進行風格化。只有這樣，咱們才能安心投入更大的項目。咱們因而就用 Vue 開始打造 Behance Live，Yuriy 回憶說。

在 Portfolio 項目中，咱們 9 人的前端團隊都開始使用 Vue。咱們的一些後端開發人員也開始學習 Vue。 Matt 解釋說，Behance 產品中約有8位前端開發人員在使用 Vue 進行開發。

兩個團隊確實有一些功能上的重疊（Adobe Portfolio 和 Behance）。Erin 補充說，咱們在代碼庫之間共享了許多庫和 API，並且一些功能的展示一般須要兩個站點一塊兒合做。

Behance 團隊在定義如何構建應用程序的通常方法以及如何定義不一樣組件的角色方面遇到了許多挑戰。

對於比較大的應用程序，vuex 存儲區也很難構造。咱們決定使用命名空間模塊。一開始咱們不清楚每一個路由/頁面或數據類型（例如用戶或項目）是否應該存在單個存儲模塊。建立特定的路由存儲意味着跨路由的操做將不可重用。對咱們來講，使它們具備數據特性是最好的解決方案，其中包含一個頂級路由存儲模塊，它結合了路由所需的模塊。可是，這個解決方案還不夠完美。Yuriy如有所思地說。

爲了定義各類組件的角色，咱們區分「頁面」組件（路由器指向的第一個組件，也是與 vuex 交互的組件）和木偶組件（僅將屬性發送到子組件，將事件傳輸給父組件）。

使用 Vue.js 將近 1 年後，Matt 和他的團隊終於構建和重構了一堆功能。

在 Adobe Portfolio 中，咱們從內容管理功能入手。內容管理容許用戶能夠在本身的 portfolio 網站上進行從新排序，添加，刪除等操做。根據需求，咱們構建了可複用的 UI 組件，如選擇下拉列表，浮窗，切換控件和拖放列表，Matt 說。

成果

據 Erin 介紹，因爲 Vue 具備先進性和靈活性，Vue 易於和 Behance 現有的代碼庫集成。

我老是說，每一個框架僅僅是另外一個工具而已。然而，除了更新快和易閱讀的文檔以外，使用 Vue 的最大好處就是能夠將其集成到現有的代碼庫中。與其餘基於組件的框架不一樣，Vue 給予咱們在現有的頁面嵌入組件的能力，使咱們可以以本身節奏更新站點，而不是所有替換。

我會說 Vue 超出了咱們的指望。咱們曾由於並無太多大公司使用 Vue 而猶豫。可是，每當我遇到問題（一般都是由於個人多慮），Vue 均可以很容易地解決，這讓我感到驚喜。她笑着說。

目前，咱們正在計劃將咱們的整個 Behance 代碼轉換爲 Vue，固然，也在推薦 Adobe 的其餘團隊使用 Vue。

Yuriy 認爲，Vue.js 提供給開發人員的可能性與其餘框架同樣多。然而，與一些框架相比，它使開發更容易...也更便宜。

我不敢說 Vue 能幫你作一些其餘的框架作不到事情。可是，使用 React 的話，提高 SSR 的性能確實事件很難的事。在使用 Fiber 重寫（React v16）以前，一個具備巨大組件樹的頁面將阻塞主線程，反過來講，這就意味着若是須要 100ms 來渲染一個頁面，那麼 Node 服務器的全部其餘客戶端就只能等待。所以，咱們須要增長單個服務器的進程數量或增長服務器數量來提升吞吐量。這很難維持，並且很是昂貴。Vue 的 SSR 狀況就強大不少。Vue 有內置緩存和流式傳輸，所以即便不作大量優化，Behance Live 的性能也很好。

使用 Vue.js 絕對與使用其餘框架不一樣。不知何故，你會愛上他的。

Chess.com

Chess.com 是排名第一的在線國際象棋網站。來自全世界各個地方各個段位的棋手天天要對弈超過 100 萬局。Chess.com 是由 100 位成員組成的徹底遠程工做的團隊。

這是我第一次一口氣閱讀完整的文檔。如今是凌晨 1:30。當我看完時，我知道了 Vue.js 是個特別的東西。它有一些獨特之處。一些我歷來沒有見過的東西。

Scott O’Brien，Chess.com 首席用戶體驗工程師

挑戰

處理難以維護的 Angular 1 遺留代碼。

引入新特性以增長用戶參與度。

在一個徹底分佈式的開發團隊中管理變動。

解決辦法

對全部可用的框架進行基準測試。

從 Angular 1 遷移到 Vue.js。

構建日益增加的組件庫（連同它的模塊化 CSS）。

成果

使得全遠程的團隊合做更加愉悅。

app 內編寫 CSS 更加高效。

與其餘框架相比，在速度、能力和抽象方面更有效地進行擴展。

挑戰

Chess.com 是國際象棋領域中訪問頻率最高的網站，擁有多達 1900 萬成員龐大的社交網絡。它有新聞，博客，社區，教程，謎局，固然也包括實時對弈。網站門戶的複雜性是巨大的。

遺留代碼是用 PHP 和 Angular 1 編寫的。任什麼時候刻，Chess.com 都承載着網頁上或手機上成千上萬的實時對戰遊戲。對於這樣一個網站來講，性能是第一位的。

咱們已經知道使用 Angular 1 是一個巨大的性能瓶頸。這個問題會變得愈來愈大。從性能角度來看，咱們網站的有些部分在一些傳統的硬件設備上已經變得沒法使用。它是沒法維護的，Scott 回憶說。

Chess.com 面臨的挑戰不只是處理現有的功能，也包括對新功能的規劃

大部分討論都是關於架構，由於咱們知道須要加入不少新的功能以保證用戶下更多的棋並嘗試各類不一樣的下棋方式，Scott 解釋說。

我不是說用 Angular 就作不了，只是用這些過期的 javascript 框架很難作到。

爲了提升用戶體驗， Chess.com 須要作一些真正的改變。

我知道咱們須要一個質的飛躍。從 Angular 1 遷移到哪一個框架讓咱們深思熟慮。固然，咱們有考慮過兩位大佬：Angular 2 和 React。

龐大的基礎設施和持續的產品開發須要一個組織良好且規模龐大的團隊。

在咱們的開發團隊中，有各類各樣的技術棧。此外，咱們的團隊是徹底分佈式和國際化的。任何像技術遷移同樣重要的決定都會引發不少人的關注。

解決辦法

選擇一個由 Facebook 或 Google 支持的框架，如 React 或 Angular，相對來講，貌似是一個比較安全的選擇。可是，Vue.js 社區證實這個新來者無疑是一個強力的競爭者。

咱們是如此的關心性能以致於咱們可能會選擇對開發者不那麼友好但基準測試看上去不錯的框架。看到 Vue.js 贏得了渲染和性能的基準測試是振奮人心的，Scott 解釋到。

咱們擔憂的是整個 Vue.js 是創建在 Evan 的想法上的，這個框架的生死都由他主導。咱們決定只要社區發展迅速而且咱們相信他們在作一些革命性的事情，咱們就會帶頭並確信其餘人在未來會看到它的價值，正如咱們如今看到的同樣。因此最大的問題是，它是否會繼續發展，我認爲這已經被證明了。

Chess.com 團隊首先要作的事情之一就是將不一樣的頁面從 AngularJS 重寫爲 Vue。

重寫工做如今仍在進行，目前已經持續了數月。咱們的另外一個任務是構建咱們內部的可重用組件集，Scott 指出。

我認爲用 Vue 構建一個不斷增加的組件庫是一件很是酷的事情，每一個組件都有本身的模塊化 CSS，這些組件最終會構成咱們網站上的所有用戶界面元素。一個團隊一直在用 Vue 來實現特定產品領域的 components、routes 和 stores，而另外一個團隊一直致力於構建全站共享的組件庫，幾乎不用擔憂產生衝突。此外，它還使咱們的產品討論更加抽象和複用。

成果

對於一個像 Chess.com 這麼大的應用來講，Vue 帶來的好處遠遠超過其餘。

單個文件組件絕對是構建和維護咱們庫的不二法則，這樣使得團隊可以僅僅在有官方的狀態管理系統的框架部分中進行投入。咱們相信這些事情會一塊兒工做——這都是集體願景的一部分。

有了 Vue.js，Scott 發現與遠程團隊合做起來更加容易了。

他指出，咱們對Vue的熱愛在於，它具備難以置信的易用性和低的入門門檻，同時具有拓展能力，與其餘組件庫相比，有至關的(若是不是更好)能力、速度和抽象性。

咱們是一個徹底由15個開發人員組成的遠程團隊，咱們很是依賴 Slack, Jira 和 GitHub。然而，在 Vue 中更容易進行協做，由於它與咱們的遺留代碼沒有太大的區別——仍然有聲明式模板以及咱們習慣的全部內容。

其次，編寫 CSS 的便捷性使人驚歎。它給咱們帶來了巨大的利益。咱們有許多開發人員說着不一樣的語言使用不一樣的編程風格，他們只需針對特定文件中的標記來命名，而不須要擔憂全局名稱空間的名稱衝突。使用方便的感受是如此美妙。

介於 Vue 給 Chess.com 團隊提供了巨大的支持，將來他們無疑將會繼續使用它。

咱們如今都在用 Vue.js！正如我說的，咱們的工做分兩部分：重構咱們的組件，從 Angular 1 遷移。所以，咱們同時用兩種徹底不一樣的方式實現，這是值得驕傲的。

Clemenger BBDO

Clemenger BBDO 是一個全方位的服務機構，提供包括品牌戰略、綜合創意開發、CX、數字服務、CRM、PR、設計、顧客和激活的全套功能

在過去的12個月裏，在戛納廣告獎和創意獎上，它被評爲世界上最具創意的機構。

咱們決定選擇 Vue.js 由於它知足了咱們的項目提出的全部需求，同時爲咱們的團隊提供了一個溫馨的開發環境。它很是接近於原生 JavaScript，所以很容易上手。

Sylvain Simao, Clemenger BBDO 技術總監，墨爾本

挑戰

項目週期短（4 到 12 周），由多人完成開發。

使用動畫和過渡效果。

移動設備上加載和運行速度要快。

解決方案

對靜態頁面使用 Vue.js 的預加載方案

構建ES6模塊而不是框架特定的代碼。

成果

按時交付多個成功的互動活動。

高流量的數字項目。

快捷的入職培訓和項目初始化。

挑戰

Clemenger BBDO 大多數項目是活動網站。他們大部分是前端的（包含小部分後端），大多數項目使用的是無服務器的方式、API、AWS 服務等。

因爲同時須要開展多個有着嚴格工期的項目，Clemenger BBDO 必須設計出一套標準的能夠顯著提升開發速度，且要有足夠的靈活性，能夠用於不一樣的項目之中的方案。

做爲技術領導，我須要記住的一件事情是個人團隊在短期內交付高端的高質量項目的能力。咱們是一家廣告公司，這意味着一個爲期3個月的項目真的很長，Sylvain 解釋道。

快節奏的環境意味着咱們須要人們可以快速地投入到新的工具。有時咱們也須要與外部承包商合做，因此對於咱們最完美的方案是那些很容易學習和用於工做的東西。Vue在工做流程方面給了咱們很大的靈活性——例如，可以與已經知道的 HTML 和 CSS 的預處理器一塊兒工做是一個很大的優點。

在客戶端項目上，Sylvain 和他的團隊使用了不一樣的 JavaScript 框架。

我以爲咱們都試過了! Sylvain 笑道。

咱們嘗試了一些框架，好比 Angular，React，和 Riot.js。可是 Vue 最終獲得了咱們的青睞。Vue 即簡單又不失健壯。對咱們來講，這是一縷新鮮的空氣。它有一個豐富的生態系統，並且它是一個漸進的可採用的工具，使它成爲咱們所要交付的工做類型的完美工具。

交互式活動網站處處是挑戰。

您必須處理 SEO、可訪問性和瀏覽器兼容性，但同時也要實現通常的動畫、過渡和不少交互界面。這些無疑是咱們工做中最具挑戰性的方面。

解決方案

因爲其流暢的學習曲線，Vue.js 能夠很容易讓新開發人員或外部承包商使用。

咱們注意到 Vue.js 在培訓新手方面表現很不錯。爲何？由於學習曲線很是平滑，很是接近原生 JavaScript，Sylvain 說。

對咱們企業來講，它真的很棒。人們能夠很快得到最新的速度，咱們能夠更有效率地交付。另外一個值得注意的一點是，Vue 的官方文檔和資源的質量使人難以置信。它可能應該獲得一個最容易理解的框架文檔獎!

對於每個 Clemenger 服務的網站來講，重要的是 SEO。

對於這個特定的問題，咱們爲咱們的全部頁面作預渲染。大多數時候，當咱們有一個新的項目須要 Vue.js 的時候，咱們從基於官方 Vue webpack 模板構建的樣板開始。而後，咱們使用像 PhantomJS 或 Prep 這樣的庫來呈現頁面的靜態快照。最後，經過使用 Nginx 或 Lambda@Edge 等用戶代理工具，很容易將這些頁面提供給爬蟲。

Sylvain 使用 Vue.js 來處理動畫和過渡效果。

如今咱們正在改變咱們實現動畫的方式。自從 Vue 的最新版本發佈以來，如今的過渡效果有了更多的靈活性。咱們如今有了一個更細粒度的轉換鉤子，這使得能夠觸發第三方庫並實現複雜的動畫，同時核心仍使用 Vue。我正努力推進個人團隊走向那種模式。

對於 Airbnb 的活動設計--「Until we all belong」，技術選型是 Vue.js。

該項目最初設計爲一個單頁面應用，基於 Vue 和 webpack。爲了提升效率，web 頁面託管在 Amazon S3 bucket 中，這意味着咱們不能使用任何服務器端渲染。UI 的每一個部分和每一個頁面都是使用 Vue 單個文件組件構建的。在這樣一個預期會有大流量的網站上，性能是關鍵，這就是爲何全部東西都按需加載。咱們的一個項目記錄到了每分鐘 6000 個的訪問量——是很是大的。咱們須要作好準備，Sylvain 解釋道。

在這種狀況下，Vue.js 是救星。對於 Airbnb 項目，背景中有很大的圖片資源須要加載以及應用動畫。爲此，咱們使用 Vue-router 來聲明須要預加載的資源或數據，而 VueX 則負責跟蹤每一頁上的內容。這個項目在交互方面也頗有挑戰性，但咱們在6周內就成功發佈了這個網站。

成果

使用 Vue.js 來按時交付項目要容易得多。

若是不是 Vue，咱們就不會那麼快了。主要是由於 API 的簡單性。咱們最近開發了一個基於 Angular 2 的混合應用程序的原型，語法很優雅，但學習曲線很陡峭，簡單的事情也須要時間。有了 Vue，你能夠快速地實現原型，這多是它最大的優點。

有了 Vue，Clemenger 團隊可以處理各類不一樣的項目。

咱們如今有至關多的項目創建在 Vue.js 之上。「Airbnb’s Until we all belong」，一個澳大利亞的婚姻平等活動，已經得到了一些行業獎項，包括 AWWWARDS 和 CSSDA。另外一個項目--Meet Graham which introduce the only person designed to survive on our roads, Graham。在第一週內，該項目記錄了超過 1000 萬的頁面瀏覽量，並得到了身臨其境的公認和媒體報道。它備受好評，並得到了衆多獎項，包括 2017 年戛納國際電影節大獎。咱們最近的一個項目是 Snickers Hungerithm，此次咱們決定用 Vue 重寫活動應用用於全球推廣。Hungerithm 是飢餓識別算法，能夠經過推文來監控在線情緒。當飢餓度上升時，士力架的價格就會實時降低。

Codeship

Codeship 是一個持續集成平臺，它可讓你在雲端放心地發佈你的應用。在 Codeship 上的開源項目老是免費的。

Vue 給了咱們作任何想作的事情所需的靈活性。它打下了堅實的基礎，所以咱們能夠用任何咱們喜歡的方式去擴展它，它不只僅是咱們用來完成目標的工具。這是咱們很是喜歡它的理由。

來自 Roman Kuba ，Codeship 前端 Leader。

挑戰

應用內的凍結和崩潰。使用 Angular 進行單元測試很是困難。雄心勃勃的新功能計劃以及構建新的，複雜的東西。

解決方案

構建一個概念驗證( Proof of concept )，並以此說服其餘開發人員去嘗試一下 Vue.js。只接受驗收測試。重構以及重寫頁面。

產出

自從 Vue.js 實施以來，沒有發生任何應用程序崩潰的現象。牢固（Bulletproof），可靠，易於維護的代碼。獲得客戶滿意當前用戶體驗的正面反饋。

挑戰

Codeship 是 2010 年推出的一款 CI 平臺，被 CNN，Red Bull 和 Procuct Hunt 等公司使用。他們的技術棧中包含了 jQuery 和 CoffeeScript，他們爲全球開發者創建了一個成功的平臺。

但隨着時間的流逝，這個團隊意識到是時候該去找一個新的技術去支撐更久遠的發展以及促進更復雜東西的建設。

給你一些觀點 —— 大量的客戶在他們的平常操做中依賴着 Codeship。當咱們正在開發一個新功能時，一般可能須要四個月的時間，不知爲什麼，這樣總感受不太好，就好像咱們正在從顧客那裏拿回什麼東西。但若是咱們花兩個月的時間去開發功能, 就反過來了，這每每意味着兩個月的痛苦而且對客戶不負責。快速而可靠的提供產品對咱們來講相當重要。Roman 這麼說。

咱們擁有可以完整接收終端輸出的頁面做爲咱們用戶的可讀日誌,這樣他們就能夠看到什麼樣的測試經過了以及測試的信息。像咱們以前的產品使用 jQuery，由於一些變得愈來愈複雜的緣由，不得不將它砍掉,對比很明顯。Roman 反映道。

接下來的六個月裏面咱們使用了 Angular 1。僅僅是由於咱們對它比較熟悉。

公司切換到了 Angular 並且適應的很好。然而隨着服務的增加，咱們發現堅持使用它從長遠的角度來說是不太可能的。

咱們一直試圖去改善的一個東西是性能。這是 Angular 裏面的一個超級大問題。咱們在構建的頁面上須要展現的數據量遠遠超過了 Angular 的能力上限。客戶們紛紛報告嚴重的問題 —— 頁面無響應，有些人甚至遭遇了凍結和瀏覽器崩潰的現象。

即便如此，Roman 仍是不想立刻放棄 Angular。

固然，咱們已經盡力去優化了。我甚至嘗試將一部分的渲染工做移出 Angular 的默認渲染列表並用原生的 JavaScript 代替，可是並無什麼用。Roman 嘆了口氣。

在某一時刻， Angular 試圖經過跟蹤頁面的範圍並運行相關的 digest cycles 來把握頁面上的變化。。。這很影響性能，咱們嘗試去消除這一影響，但沒什麼用，它沒有辦法順利地運行。

Codeship 面臨的另外一個重大挑戰是改進測試過程並使應用程序變得更加可靠。

咱們在使用 Angular 的時候仍是會盡量地利用驗收測試。咱們基本上會把整個應用裏的用戶故事都給測試一遍。使用 Angular 自己進行單元測試以及單獨測試組件，模塊或控制器是很是痛苦的。它幾乎給不了咱們所需的所有畫像。Roman解釋說。

解決方案

獲得工做人員的承認以及 VPE 的批准是從 Angular 轉型的第一步。

起初，讓全部人都贊成去使用 Vue 是一場艱苦的鬥爭。這個團隊以前歷來都沒有聽過它，他們只知道 Angular 2 以及 Google 正在拋棄它，還有 React 和它背後的 Factbook。Roman 說。

在團隊會議中，第一個問題一般是關於 Vue.js 社區的規模，你們想知道若是在開發過程當中遇到問題，他們是否可以獲得來自社區的幫助，由於咱們的大部分員工都是作後端的，他們更想要堅持選擇他們所能聽到的可信賴的名字。

Roman 決定用他的知識和調查結果來講服他們轉移到 Vue.js。

「我作了一些樣例和一個內部演示，至少要讓他們相信這個決定以及決定背後的理由」他說「若是你簡單地閱讀過 Vue 的源碼，你會發現獨立去擴展這些代碼並不困難。它不像 Angular 或者其餘相似的沉重的框架。」

在 Codeship 直接投入開發以前，他們須要一個概念驗證。

當時我對 Vue也沒有太多的經驗，我對框架中涉及到的技術瞭解十分有限。可是，從 Vue 開始彷佛毫無費力，我很快就意識到這是一個針對困擾咱們大多數問題的解決方案。只用了一個晚上左右，我就用 Vue 重構了一個關鍵部分並試圖使用大量的 Loglines 做爲概念驗證。

而後我對全部的代碼作了CPU性能分析，這件事當即向個人團隊證實了 Vue.js 已經給咱們帶來了巨大的性能提高。咱們將渲染時間從30秒縮短到了7秒左右。Roman 回憶到。

概念驗證在手，Roman 和它的員工終於能夠開始向 Vue 過渡了。

咱們試圖移走概念驗證並用 Vue 代替咱們現有的系統。這裏頭的實際風險很是小。咱們有一個對用戶來講正處於崩潰的系統，因此，還會有什麼更糟糕的事情會發生？Roman 笑道。

我經過花了一個禮拜的時間重構並重寫頁面，而後將它發給用戶來獲取反饋來快速驗證工做的可行性。只過了一天的時間，咱們就發現過去困擾咱們的問題所有都消失不見了，甚至是在有 15 Mb 日誌呈現的狀況下。在渲染時間在 30 到 40 秒之間（咱們正在努力進一步減少這個數字），應用在全部的瀏覽器上都可以出色的運行而且沒有被咱們記錄到任何一次崩潰。

拋棄驗收測試使整個測試部分變得更加愉快和可靠。

咱們拋棄了驗收測試，開始考慮咱們能夠獲得什麼，並使用 Jest 和 Vue 來測試。咱們在 Vue 中使用多個組件，甚至是複雜的頁面，可是隻能經過 Jest 進行測試，由於咱們有快照並驗證渲染 HTML 是不是咱們想要的。Roman 解釋道。

產出

一些不多作前端的工程師如今感受有能力去接觸一些代碼片斷了。

Angular 和它的結構、模塊、模型和控制器，以及幾十個其餘東西。。引入了沒必要要的高度複雜性。對於這些工程師來講，大部分名詞聽起來就像是奇怪的魔法同樣。可是當他們真正地看到 Vue.js 的時候，他們能感受到本身有能力去立刻深刻研究它。這對於咱們公司來說是一個很是大的勝利，Roman反映道。

Vue.js 幫助 Codeship 組織他們的代碼並優化用戶體驗。

它能夠幫助咱們更快的交付所需功能，用戶不須要爲了他們須要的或者指望的東西來等待數個月的時間，他們很是喜歡這一點。咱們的頁面中有一個是基於 jQuery 運行的，它的結構很是奇怪。咱們將它基於 Vue 重構了。如今，它提供了更加細化的體驗和更友好的 UI 交互效果，所以，它顯著地改善了用戶體驗。人們老是這樣告訴咱們。

使用 jQuery 的時候，代碼很是混亂，難以和維護。而使用 Vue 的時候就不同了，你能夠利用它組件的強大功能和它的生態系統，好比 Vuex。咱們如今正在作的是頁面狀態管理，這是咱們之前歷來沒有完成過的，至少沒有以這樣一種乾淨的方式完成。

對於 Codeship 來講， Angular 測試是一個很是痛苦的過程。而用了 Vue.js，他們知道他們的代碼是牢固的。

Vue.js 確實提高了咱們的測試協議。Jest對咱們來講是一個比較聰明的測試工具。可是有了 Vue 以後，咱們以爲咱們又更多的方法來控制應用的各個方面，Roman 闡述道。

我能夠運行 15 個執行特定操做的測試。這樣的方式可讓我輕鬆地識別代碼中的斷點。在之前的驗收測試中，我沒辦法這樣作，由於這須要消耗很長的時間。獲得的結果不值得咱們付出那麼多的精力。單元測試在這方面反而更好。在代碼方面，我知道它是牢固的，由於咱們以全新的方式對它進行測試，結果使人難以置信。

GitLab

GitLab 是一個集代碼託管,測試,部署於一體的開源git倉庫管理軟件。

每個框架都有本身的適用領域，使用 Vue 的時候，每一次鬥爭都是你本身的，而不是 Vue 的。它只是一個完美的框架。

來自 Jacob Schatz, GitLab 前端 Leader

挑戰

實現複雜的功能以及維護現有的功能會有困難。大型的 Rails + jQuery 應用難以擴展。應用速度不足。

解決辦法

逐漸將 Vue.js 引入到 GitLab 中，以便與 jQuery 一塊兒使用。把 Vue.js 用在合適的新的功能上以及遷移舊的功能。如無必要，不作完整的重寫或者重構。使用 webpack 建立優化後的代碼包。

產出

整個代碼庫和代碼結構體系中的統一的樣式指南變得更加容易維護。極大改善了時間消耗以及編碼效率。由於可以實現更復雜的功能，改善了用戶體驗，從而致使了更好的銷售業績。經過減小包的體積使頁面的加載時間獲得改善。

挑戰

通過六年的市場推廣，GitLab 已經成爲上千家公司開發人員心目中知名的解決方案提供商。可是在兩年前，公司內部的大部分代碼仍然是用 Rails 和 jQuery 編寫的。

直到 2015 年，公司尚未專職前端的開發人員，並且整個體系運轉得十分良好。Rails 開發人員兼職寫前端代碼並且作的很棒。然而，公司將來的計劃須要一個新的解決方案。

當我剛進公司的時候，我看到咱們有一些比較簡單的項目是隻用 jQuery 實現的。但若是咱們想要作一些更復雜的東西，或者說咱們想要實現一些比較大的點子，咱們須要一些別的東西。Jacob 解釋道，

jQuery 很棒，可是由於你要負責代碼內的每個狀態的變化，這樣容易致使它形成更多的 bug。

爲了達成目標，GitLab 開始尋找一個新的解決方案。

由於我以前有使用 Backbone 的經驗，因此咱們考慮過它。咱們也仔細考慮過 React，可是也淘汰了。還有 Embar 和其餘的不一樣的框架。我甚至想過用每一個框架都作一個小項目出來，那時候咱們甚至還沒想過 Vue.js！Jacob 回憶道。

測試全部的這些框架幫助 Jacob 認識到了它們的優缺點。

Backbone 有很好的結構，它有不少小工具能夠完成任務。可是你用起來其實和 jQuery 沒什麼太大區別。而我對使用 React 這種依賴大公司的框架有些恐懼，所以它彷佛也不適合我。我很是喜歡 Mithril！惟一的問題是它寫起來很是困難。若是他們能加入一些友好性，我相信人們會開始適應它。

另一個大的挑戰就是爲切換新技術作個成熟的方案。這麼作有很大的風險，所以必須良好地切換它。

在 GitLab，咱們有成噸的代碼。當我加入的時候，咱們的代碼庫已經有 8000 行的 JavaScript代碼了。很明顯，我徹底不想去完全重寫這玩意。實際上咱們的代碼庫中仍是有些地方是用 jQuery 寫的。

解決方案

測試了一些框架以後，Jacob 在他手頭的框架裏仍是找不到一個完美匹配的。只有在他用 Vue.js 的早期版本寫了一個很大的項目以後，他才意識到本身可能找到黃金了。

當我把這個項目放在一塊兒的時候，我就知道咱們能夠用這個框架寫不少代碼。這不只僅是寫一個簡單的 todo 應用。全部問題都會在你開始處理這個大型的應用的時候真正開始，Jacob 解釋道。

在 GitLab 開始切換到 Vue.js 以前，他們須要作一次概念驗證。

Phil Hughes [Sr. GitLab 前端工程師],建立一個概念驗證，咱們在那裏採起了一個咱們正在作的主要功能 —— issue boards 。Phil 用 Vue.js 寫這個，顯而易見，咱們在很短的時間內完成了大量的工做！沒有以前 jQuery 帶來的各類 bug。Jacob 說道。

Vue.js 支持 Jacob 在他的團隊中推廣本身的方法--小範圍迭代，並創建概念驗證。

他說，咱們老是有四到五個概念驗證。

經過這種方法, GitLab 引入了 webpack ，它可以將資源拆分紅更小的塊供瀏覽器下載，從而縮短了應用的加載時間。

咱們建立了一個小的概念驗證來判斷 webpack 是否可行，當咱們發現這是可行的時候，咱們走完了整個流程並結束了 Vue 和整個 trello 應用的開發。並在一個月內取代了數十億美圓的產業，幹得好，Phil！Jacob 笑了。

響應式模板（reactive templates）這個功能是 Vue.js 中最有用的。

這是 Vue 所作的很是很是簡單的一件事情。我在 GitLab 中編程的第一件事就是進入 issue 頁面，在以前，當你點擊 close 的時候，你必須刷新頁面。而現再，它改變了合併按鈕（merge button）的狀態，它會自動改變下面全部按鈕的狀態。在 jQuery 中，咱們須要寫至少三四十行的代碼來保證這個按鈕的狀態是正確的。在 Vue.js 中只須要一行代碼。視圖老是會反映出當前的狀況， Jacob 解釋道。

並且如今咱們使用 Vuex，它比以前作的更好。狀態管理工做有了很大的不一樣

雖然 Vue 有不少優勢，可是它也有一個缺點。

目前 GitLab 有 15 名開發者。像 Angular 這樣的框架，你們能夠在一塊兒用一樣的方式工做。而 Vue 比它開放不少，因此咱們須要創建文檔來告訴你們在 Vue.js 中寫代碼時該遵循什麼樣的模式。不過這是咱們已經解決了的問題，Vue的開放性也是它的魅力所在，可是你須要保證全部人都在同一個層面上。

**VUE.JS STYLE GUIDE BY GITLAB

產出

使用 jQuery 來擴展應用和引入新功能實際上是能夠的，不過維護起來就要困難的多。

咱們如今正在作的事情須要很是大的代碼量以及不少的組織。針對這些問題 Vue 解決了不少。Jacob 說。

像 Vue.js 中的響應式這種, 你給它一個變量，它會直接綁定到 DOM 上並處理好全部其餘的事情，尤爲是 2.0 版本中的虛擬 DOM，它提供給咱們一個簡化工做流程的辦法去改善性能。

GitLab 之因此能夠快速迭代並提升代碼的可用性，這都要歸功於 Vue.js。

在以前咱們須要專一一些小的細節和代碼，如今咱們終於能夠專一於代碼可用性以及用戶體驗。咱們能夠思考更大的圖景。

Vue.js 是如此的開放和易上手，GitLab 的前端開發人員天天都可以處理它。

和其餘工具相比，Vue 不用遵循任何嚴格的知道規則。它是開放的，這點實在太讚了。我喜歡它如今作的一切。固然它有着你能想象到的最神奇的文檔。它對於新人很是直觀和友好。

Vue.js 幫助 GitLab 改善了時間和成本效益

你們知道事實上咱們的發展速度更快了。這很容易看出來。從銷售角度來看，咱們正在創造的更良好的用戶體驗功能吸引人們使用 GitLab ，並使它成爲更加使人期待的產品。人們喜歡咱們用 Vue.js 開發的新功能。由於咱們改善了用戶體驗，也間接增長了銷售量。

Jacob 認爲他們未來確定會再使用 Vue.js。

咱們都準備好了！如今咱們還有其餘的挑戰。目前咱們正在努力改進咱們的流程並加快測試的速度。 Vue.js 爲咱們解決了如此多的問題以致於咱們確定在未來持續地使用它。

Livestorm

Livestorm 是一種基於網絡的、集成一體的在線會議解決方案。它幫助像 Workable, Pipedrive 或者 Instapage 等公司進行現場銷售演示或者客戶培訓。

咱們不須要花一個月時間用 React 來把全部事都安排好，Vue 讓咱們在一週內就能夠辦到。我徹底確信若是沒有 Vue ，就不會有今天的咱們。

來自 Livestorm 的聯合創始人兼首席執行官 Gilles Bertaux.

挑戰

從零開始創建可靠的實時網絡軟件，並使其在競爭激烈的市場中產生影響。在巴黎，只有極少數的 Vue.js 專家。吸引初始用戶並驗證產品的理念。

解決方案

創建一個快速的最優秀應用。使用 Vue.js 和 Ruby 建立一個高性能的應用。在 Vue.js 社區上爲團隊尋找潛在的員工。

成果

當即獲得用戶的積極反饋。可重用的組件以及快速開發。快速成長的業務量以及每個月 20-30% 的收入增加。

挑戰

與其餘網絡平臺不一樣，Livestorm 渲染了瀏覽器中的一切。該服務經過分析、與流行的客戶關係管理系統集成、以及營銷自動化軟件提供可實施的辦法。

對於這樣的應用，Gilles 和他的團隊必須選擇一個高性能的技術棧。他們打算從零開始驗證他們的想法並創建一個穩定可靠的產品。

Livestorm 的主幹是一個 Rails 應用程序——後端全部東西都是用 Ruby 作的。 Gilles 解釋道：對於咱們全部的前端組件，咱們選擇了 Vue.js。

咱們從 2016 年 1 月開始開發咱們的項目，從第一天開始，咱們就知道咱們會使用 Vue。咱們須要一些徹底開源的、高性能的、有特定邏輯的組件。Vue 是惟一能知足咱們全部需求的框架。

Livestorm 由四位聯合創始人建立，力圖從公司的最初階段組建一支強大的員工隊伍。

咱們考慮了不少招聘問題。在咱們工做的巴黎地區只有不多的 Vue.js 開發人員。咱們也考慮招聘精通相似於 Vue 的其餘框架的開發人員，可是這種狀況下，新員工培訓過程可能花更長時間，這對咱們來講是有問題的。

爲了創建一個成功的流媒體產品，團隊必須關注可靠性。

可靠性對咱們來講是頭等大事。Gilles 說：若是你失去了直播流，網絡研討會和演示會崩潰而且流媒體丟失，咱們的業務就會變得毫無心義。

若是應用程序掛了，或者有一個 bug 讓它沒法使用，咱們會失去用戶。咱們須要一種技術來保證最高的代碼質量，而且運行得很快。咱們仍然在執行端到端單元測試。有些事情咱們尚未用 Vue 實現，這對咱們來講是全新的。

解決方案

大多數開發人員仍然選擇 React 和其餘流行的框架，可是 Gilles 相信這將會有所改變。

爲了給咱們的員工招聘專家，咱們參加了在巴黎的 Vue.js 聚會，在那裏咱們遇到了頗有經驗的人。咱們也試了在招聘網站上發佈招聘，有趣的是，約談的大多數程序員說他們在本身的項目上用 Vue.js，可是他們平日工做用的基本是 Angular、React，和其餘框架。Gilles 指出，他們大多數來自大公司。

然而，我注意到一件事，那些常用這些技術的公司，是由於代碼遺留所迫，或者是由於他們想嘗試一下其餘人也在嘗試的技術新熱點。在創業社區，在我參加的多個輕鬆的渠道和會面中，與我交談的首席技術官和聯合創始人對遷移到 Vue.js 很感興趣，他們對咱們在 Livestorm 裏用了 Vue 很興奮而且問了不少問題。坦率地說，我相信會有一個重大的轉變——人們會對遷移到可靠、高效的東西更感興趣，像 Vue.js。Gilles 補充說：而像 React 這類炒做的技術會逐步減小流行，直到他們最後被淘汰。

Gilles 想把他的產品儘快發佈，他的團隊建立了一個快速的 MVP 來得到外部世界的最初反饋。

咱們花了不到一個月的時間建立了第一個 MVP。這足以展現產品和基本理念。他回憶說：最後，咱們獲得了不少積極的反饋，從而確保了咱們是符合市場需求的。

咱們花了 5 個月的時間賣出了第一份訂閱。這是至關長的一段時間，可是咱們須要首先完成一些與技術沒有必然聯繫的東西。

Gilles 的團隊在他們的平臺上建立的一系列功能使其成爲一個有競爭力的解決方案，真是使人驚歎。

直播會議、網絡攝像頭和屏幕共享中的 WebRTC 實時流、全高清流媒體直播是主要的視頻相關的功能。咱們也提供了一個運行於 Vue.js 的聚焦於分析的部分，而且與流行的銷售和營銷工具，例如 Salesforce 集成。咱們也開發了其餘基於瀏覽器的網絡會議軟件所沒有的獨一無二的功能，讓用戶能夠在飛機上從 WebRTC 切換到 HLS，使媒體流能夠與 IE 瀏覽器用戶以及一部分移動設備匹配。

成果

投入市場一年後，Livestorm 擁有來自世界各地的用戶，而且有了一個已經盈利的產品。

咱們已經有大約 150 名付費用戶，他們都對 Livestorm 的速度之快印象深入，他們也喜歡界面和交互。從商業上來講，咱們有一個不受咱們干擾能獨立運行的應用程序，因此說——咱們沒有一個銷售團隊。咱們有 7 名員工，包括產品專家、工程師，以及一名營銷人員。那我的是我，Gilles 解釋道：可是隻是由於產品很是好並且可靠，咱們每月有 20%-30% 的增加。

藉助 Vue.js ，Livestorm 能夠更快地發佈新功能，以知足客戶的需求。

固然，咱們試圖儘快地上新功能。如今咱們在一個爲期兩個月的開發階段，該階段將以一個大型功能的發佈而結束，可是咱們一般在一兩週內發佈功能，Gilles 解釋道。

有了 Vue.js 咱們沒必要每次都去造輪子。

咱們能夠重用全部已有的組件來加快開發。如今，咱們代碼庫的 39.5% 是用 Vue 建立的。

Gilles 聲稱選擇 Vue.js 而不是其餘框架讓他的公司成功得更快。

只有基準說明了真相，而如今基準清楚地證實了 Vue.js 絕對是新產品和現有產品的選擇。他說：因此若是任何人在不久的未來必須作出技術選擇，他們應該依靠具體事實、數據和基準，而不是觀點。

若是你有不少開發人員，他們已經習慣了使用 Angular 或者是更加經典的框架，讓他們遷移到 React 會使整個團隊感到痛苦。另外一方面，過渡到 Vue，更加順暢，反過來只要更低的成本。咱們不須要像 React 花一個月的時間來把全部事都創建好。Vue 讓咱們在一週內開始運做。若是不是 Vue，我 100% 地確定咱們永遠不會達到如今這樣的成就。

Vue.js 的特色

來自 Vue.js 的做者 Evan You

可持續性

做爲一個項目，Vue.js 已經走了很長的路才能成爲今天的樣子。它已經從一個小的實驗成長爲一個成熟的框架，而且被全世界成千上萬的開發者使用。它已經從一個「項目」發展成一個生態系統，在 vuejs 組織中有超過 300 個貢獻者，並由來自全球的超過 20 個活躍成員組成的核心團隊維護。核心團隊成員承擔了核心庫的維護、文檔、社區參與以及主要的新特性例如類型聲明的改進和測試功能。說 Vue 是「一我的的項目」再也不準確，也是對團隊和社區的全部驚人貢獻的不尊重。

從財政上來講，從 2016 年 2 月來，Patreon 活動已經收到了穩定的有保障的收入，這讓我能夠在過去一年半時間裏全職工做在這個項目裏。另外，最近開始的 OpenCollective 活動，旨在爲社區舉措提供財政支持，在短短兩週裏已經收到超過 11000 美圓的年預算，並且還在持續增加。更重要的是，這些開放的財政貢獻渠道意味着你的公司能夠經過成爲贊助商積極幫助確保項目的可持續性。

今天我有信心地說做爲一個開源項目，Vue.js 已經超越了這一臨界點，即項目的生存對任何考慮是否採用該項目的人來講再也不是一個問題。

穩定性

前端的設計變化很快，咱們知道不斷改變有多麼使人沮喪。這是爲何咱們這麼重視穩定性。在 GitHub 上查看項目的歷史，你會看到一系列新特性和改進的版本的堅實記錄，及時的 bug 修復，以及對代碼一絲不苟的標準（是的，咱們保證 100% 測試覆蓋率）。

全部 Vue.js 包的發佈遵循了語義版本控制，咱們盡最大努力經過交流提早知道任何潛在的須要的操做。2015 年 10 月，1.0 版本發佈了，並無在公共接口中有所突破，直到一年後 2.0 版本的發佈。在 2.0 發佈以前，咱們進行了公開設計討論，併發布了多個 alpha/beta/RC 版原本確保最終版本的穩定性。咱們盡力保持接口與 1.0 類似，並提供全面的指導和升級工具。今天，2.0 已經發布了一年多了，在全球的產品內獲得普遍應用，咱們不認爲在可預見的未來須要對主要的接口作修改。咱們致力於在對用戶最小影響下改進框架。

連續改進

固然，咱們不會只知足於當前咱們已經作的事情。咱們在將來幾年的探索和實施的計劃中有不少想法，我會將它們分爲三類：

近期的改進

這些新特性/改進將會持續發佈於 2.x 小版本中，它們能夠來自特性需求、來自更廣網絡開發社區的靈感，以及咱們在實際開發中遇到的用例。

中期的改進

有新的 JavaScript 語言特性（好比 ES2015 代理，Promises）能夠簡化或改進當前的接口，可是由於必需要支持 IE9，如今還不適合放在主分支上，咱們計劃在並行分支中開始利用這些特性，而這須要最新的主流瀏覽器支持。

長期的改進

咱們還關注新興的標準，好比 ES 類語法改進（類變量和裝飾器），網絡組件（自定義元素和 HTML 模塊）以及 WebAssembly。咱們已經開始了其中一些實驗，而且必定會利用它們來進一步改進 Vue 的開發經驗和性能，由於它們在瀏覽器適應方面已經成熟。

長期願景

不少人問我爲何開始使用 vue.js。老實說，一開始目的是爲了「給本身撓癢癢」，建立一個我本身喜歡用的前端庫。在這個過程當中，隨着 Vue 被愈來愈多的用戶接受，我收到了不少來自用戶的消息說 Vue 使他們的工做變得愈來愈使人愉快，所以看上去個人偏好與不少網絡開發者朋友們不謀而合。今天，我設想 Vue 的目的變爲用來幫助更多開發人員喜歡在網絡上建立應用程序。我相信更快樂的開發人員會更加高產，而且最終爲每一個人創造不少價值。目標須要提供一個可得到的、直觀的、同時可靠、強大而且可擴展的框架。我相信咱們正處於正軌上，但咱們也能夠作更多的事情，特別是經過 Web 平臺獲得比以往更快的發展。

咱們爲即將到來的事情感到興奮。

Monterail 是一個由 80 多個專家組成的緊密團隊爲創業公司和企業提供網絡和移動開發。而且咱們喜歡 Vue。

www.monterail.com hello@monterail.com