爲何咱們從Angular 2遷移到Vue.js（爲何咱們沒有選擇React）

在Rever（www.reverscore.com），咱們剛剛使用Vue.js發佈了咱們的Web客戶端的新版本。通過641次提交和16周的緊張開發，咱們很是自豪以前作出的決定。 8個月前，咱們的前端在使用Angular 2.確切地說，它使用的是Angular 2 beta 9.這是一個由外包公司編寫的產品，咱們從不少層面上都沒有徹底滿意，從UX / UI到架構，在某種程度上，與Angular 2自己有很大的關係。

在以前，我認可Angular 2 beta 9是與Angular 2.0不一樣的產品，但這正是其中一個問題。從beta9到2.0.0，有8個beta版本，8個RC和2.0.0版本，總共有17個版本須要升級。咱們確實嘗試從beta 9升級到2.0.0可是太多的api更改了使升級變得很是困難。此外，大約在同一時間咱們質疑Angular 2做爲咱們選擇的框架，Angular團隊決定開始研究Angular 4.雖然他們承諾版本改變不會太大，這意味着當咱們完成升級到Angular時2.0.0咱們須要另外一次升級。多麼浪費時間和僅有的資源。

咱們不喜歡的主要緣由是不喜歡Angular 2是Typescript開發的。我知道Angular 2能夠和Javascript一塊兒使用可是一樣，使用Typescript的決定已經被內部使用了，根據個人理解，使用純Javascript和Angular 2並非你應該使用Angular 2的理想方式。不管如何，擺脫Typescript意味着徹底重寫項目。

我沒有以爲Typescript增長了實質性的價值，更糟糕的是，咱們注意到咱們的編碼速度下降了。使用Typescript在Javascript上很容易作的事情就像定義一個簡單的對象同樣在Typescript上更復雜。我強烈建議您在開始使用Typescript以前閱讀如下文章。這對每一個人來講都不必定是正確的解決方案。

我還記得使用Angular 1是多麼容易，它有本身的不足，但與其餘框架相比，Angular 2在途中失去了某些東西。關於Angular 2的結論很簡單，Angular 1和2的惟一共同點是名稱，它們是徹底不一樣的框架。

所以，考慮到咱們在未經測試的系統上有17個版本進行升級，來自業務的不少壓力來編寫新功能，大量錯誤和編寫得很差的代碼，原始開發人員再也不在團隊中，只有一個開發人員（我）當時有許多其餘職責，自從我使用測試版以來找到正確文檔的問題，以及Angular 2轉移到版本4.他的負面消息開始迅速地積累。

咱們作了一個決議，若是咱們要花費那麼多時間升級，那還不如看看別的框架。

應對

第一個顯而易見的選擇是React，由於大部分公司都在使用它，而那些沒用的人正在談論它。因此這是一個選擇，固然知道Facebook支持它是頗有幫助。可是，React自己不是一個簡簡單單框架，你須要添加額外的組件才能讓它綻開光芒。

Vue.js

Vue.js是一個新玩家，我之前從未據說過它，雖然他們剛剛發佈版本2時咱們開始考慮不一樣的框架。起初它引發了咱們的注意，可是仍是有必定風險的。

決策過程

咱們首先開始定義咱們的決策點。咱們知道框架須要具有如下條件：

• 它應該是穩定的
• 由強大的社區或一些大玩家支持
• StackOverflow上有很好的文檔或不少問題被解決了
• 簡單易學
• 與Bootstrap集成
• 小巧
• 理想狀況下，它容許咱們重用代碼
• 應該增長編碼速度
• 基於組件

咱們列出全部需求點之後，我不得不開始動手了，因此我給了React和Vue.js幾天，分別審查了Google沒法回答的每一個決策點。因爲我對它們中的任何一個都一無所知，因此在兩天結束時，我會從新評估我在多大程度上重寫了咱們要遷移的實際項目的某些部分。

我選擇重寫的部分是：

• 一些基本的API調用
• 兩個不一樣頁面的兩個佈局。
• 用戶相關內容的兼容性
• 登陸表單和一些內容表單
• 一個bootstrap模式

我對Vue.js的實力感到驚訝，在幾天以內我實際上有了一個概念證實，以展現給團隊的其餘成員和個人CTO。我對Vue.js的基本概念有了很好的理解，定義了一個良好的，可擴展的架構，但最重要的是我很是喜歡用它編寫代碼的經驗，我以爲比React上手更快一些。

React比我想象的要可貴多，在Redux和MobX之間進行選擇比有一個與Vue.js和Vuex這樣的框架徹底集成的選項更有問題。這很簡單，由於當沒有框架經驗時，它會讓你更自信，而不是一個框架有一個正式的庫來作某事。順便說一句，我以爲Vuex的適用性比Redux更容易，但可能這只是我的的一種感知，就像全部的學習曲線同樣。

JSX也是一個問題，由於咱們沒法重用HTML代碼，而Vue.js確實容許咱們在某種程度上這樣作。Vue文件實際上很是適合使用，由於我不喜歡內聯模板。React將JSX / HTML與JS代碼混合在一塊兒，我只是不喜歡，由於我堅信分離關注點，看起來很醜。

編碼速度

編碼速度是Vue.js擅長的領域，不須要學習JSX是一個巨大的幫助。當另外一位開發人員加入該項目並在大約1小時的培訓課程後的幾個小時以後就開始項目開發。

這對咱們來講很是重要，您能夠經過打開vue文件當即看到它。它包含一個帶有HTML和標籤的模板部分，看起來相似於Angular 1，因此若是你作了一些Angular 1，它將很是熟悉。一個vue文件也有一個樣式和純javascript部分，你實際上使用javascript，你只須要學習一些關於Vue.js的東西來徹底理解它們。理解Vue.js屬性（如方法，計算，屬性，數據和建立）將使您瞭解開始編碼所需的大約90％，很是簡單。

文檔

爲了得到適當的速度，咱們須要良好的文檔和Vue.js文檔是一流的。指南，示例，問題和API都記錄得很是好，涵蓋了咱們在開發過程當中發現的全部疑問。咱們懼怕找到咱們會遇到的許多問題的中文文檔，但事實並不是如此，一切都以英文提供。

問答

通過一個多星期的考慮後，Vue.js表現很是好，但令我驚訝的是，周圍的問題都迎刃而解，由於以前沒有人使用過Vue.js，我獲得的惟一評論是「 看起來很酷，但我尚未」用它「。React獲得了最多的說起，Angular 2排在第二位。

我開始尋找具備Vue.js經驗的本地人才，我確實找到了一些很是好的人，因此我開始認爲我並不孤單，個人社交技術圈可能過小並且我不該該對事實上，我不認識任何人與Vue.js合做進行製做。

移動端

在咱們考慮Vue.js vs React的時候，咱們也在考慮重寫咱們的移動應用程序，React Native看起來是一個很是好的選擇。這對React來講是一個很大的優點，由於Vue.js沒有任何相似於React Native試圖作的長遠穩定的開發，因此在網絡和應用程序客戶端之間重用代碼的可能性是一個巨大的優點，但我決定我不會考慮。畢竟，根據個人經驗，使用Node.js，我在瀏覽器和服務器之間重用了很是少許的代碼。

許可

在我寫這篇文章時，有不少討論，由於Facebook將React許可證更改成BSD +專利。根據Facebook，這個許可證旨在保護他們免受專利巨魔的侵害。這在咱們的決策過程當中並非最原始的，但我很高興咱們沒有采用React的方式，由於任何與許可相關的噪音都不是你想聽的噪音。

最終，Facebook落後於React可能會成爲項目的責任而不是實力，這就是爲何擁有獨立基金會或組織負責成功的開源軟件項目一般會更好。Facebook應該作正確的事情，以IBM爲例，當IBM收購Strongloop時，他們將Express.js捐贈給Node.js這樣一個重要軟件所屬的基金會。社區的壓力和IBM的意願確保了軟件的連續性。Twitter是另外一個很好的例子，他們在很是寬鬆的MIT許可下發布了Bootstrap，沒有人在談論Bootstrap的License問題。

最後的話

在我作出決定以前研究的許多網頁中，有一個圖表引發了個人注意，開發人員對Sacha Greif @sachagreif每一年進行的Javascript調查狀態的滿意度。我認可，正如做者所作的那樣，這不是科學調查，但確實提供了大量信息，後來當咱們有更清晰的圖片時，咱們的決策點證明了這一點，特別是關於Vue.js，由於咱們對它一無所知咱們研究的開始。您能夠經過如下連接閱讀Javascript狀態。

整體而言，Vue.js是咱們評估的贏家，它在Stack Overflow上有不少問題，最簡單的三個選項的官方文檔，最小的代碼庫，與Bootstrap很好地集成，而且學習它是有強大的項目支持的Laravel和像阿里巴巴這樣的大公司是一個很大的優點。沒有像React這樣大的社區並非影響我去用它的一個真正的因素，由於它自己足夠大。

選擇Vue.js是正確的選擇，我花了一段時間來講服個人首席技術官，我很是感激他老是問正確和棘手的問題並100％確定個人所作出的決定。若是我弄錯了，我會後悔的。

最後整個決策過程真的頗有幫助，可是我可以快速學習的事實產生了巨大的變化，若是你喜歡就稱之爲直覺，可是學習一些東西真的快的時候讓我對更復雜的問題有了很大的信心。我知道在實際開發過程當中我會面對。

我不是說React是一個糟糕的選擇，我對社區如此之大感到驚訝，而且有充分的理由，雖然jQuery也有不少人使用，並無使它成爲咱們想要的項目的良好框架/庫去作。

Vue.js正在得到更多開發者的支持，咱們在開發過程當中看到了這一點，讓咱們更加相信，咱們的選擇是對的。