「前端架構」React和Vue -CTO的選擇正確框架的指南

快速總結:爲項目選擇正確的javascript框架或庫是CTO和項目經理的基本任務。然而，選擇的範圍很大程度上取決於幾個因素，如項目時間、學習曲線、框架性能和團隊規模。這篇文章旨在指導他們選擇正確的javascript框架(或庫):React vs Vue。

React vs Vue -選擇正確框架的CTOs指南

這是一個值得你考慮的案例!

Rever Inc.，一家硅谷公司，在構建他們的最後一個MVP以前，將將近10,000行Angular.js代碼移植到了Vuejs上。

好吧，他們須要使用的Angular版本的發佈被延遲了，這是不可預見的，他們等不起，由於這會浪費時間和資源。

直接引用Luis Elizondo (Rever的工程總監)的話——

在爲咱們評估正確的選擇框架以前，我必須親自動手，因此我給了React和Vue.js幾天時間來回顧每一個不可能被谷歌回答的決策點。因爲我對它們一無所知，在兩天結束時，我將從新評估我在重寫咱們將要遷移的實際項目的某些部分時走了多遠。

在評估了兩個框架以後，Luis和他的團隊決定使用Vue，由於他們發現Vue比React更容易使用。

如今想象你本身處於一個相似的狀況，你的1000個小時的努力都是徒勞的，這不是你本身的錯。

考慮到項目的截止日期很緊，太多的產品經理和CTO落入了一個常見的陷阱——他們選擇了一個讓他們輕鬆開始的框架，而沒有考慮框架隨時間的影響。然而，他們很快就意識到最好事先評估用例並選擇合適的框架，以免任何類型的問題。

在這篇博客文章中，我將比較React和Vue的幾個因素，這些因素將幫助咱們評估須要的正確技術。

在進行深刻的比較以前，你能夠先問本身一些問題，這樣你就能夠對這個問題有一個全面的瞭解。這些問題只是幫助你評估React和Vue之間正確框架的因素。

React vs Vue: CTO和項目經理的比較因素

• 代碼有多幹淨和直觀?

• 框架支持模塊化嗎?

• 開始使用這個框架有多容易?它是否支持JS導入?

• 框架的測試和調試方面有多好?

• 個人隊友和我可以輕鬆地學習這個工具嗎?

• 框架在性能方面是如何脫穎而出的?

• 從項目開始算起，在5-10年以上的時間裏，這些代碼會給我帶來更多的麻煩嗎?或者在那些年裏，我將被一個幾乎沒法維護的遺留應用程序所束縛?

• 框架支持服務器端呈現嗎?

• 框架適合輕量級仍是重量級應用程序?

• 這些框架的頂級實用程序是什麼?何時使用它們是正確的選擇?

如今你有了問題，讓咱們經過將這些因素與React和Vue並置來深刻研究問題的實質，瞭解它們的區別。

React和Vue的代碼質量比較代碼有多幹淨和直觀?

首先:可以讓您快速瀏覽大型項目代碼的框架應該是理想的選擇。

顯然，對於許多CTO和項目經理來講，一切都歸結爲「代碼經過測試的速度有多快，以及這些測試如何處理類型」。

請注意，要提升代碼質量，還有不少事情須要考慮。例如，單元測試、linting和類型檢查是個人團隊和我在Simform積極執行的事情。

我不會在這裏拐彎抹角地提到全部這些實踐。由於我相信類型檢查確實能提升代碼質量，因此讓咱們比較一下Reactjs和Vuejs，看看它們是否支持任何方式的類型檢查。

React的靜態類型檢查

React確實利用了JavaScript ES6基礎做爲代碼語法，可是它是否支持編譯時的類型檢查之類的功能呢?

嗯，是的!

你能夠用Flow來作靜態檢查，它是Facebook開發人員開發的TypeScript的替代品。它容許您向代碼中添加類型，而後在構建(編譯)時刪除它們，以保留正常的Javascript代碼。

[注:若是你喜歡TypeScript，但仍然想使用React，那麼你最好去，由於TypeScript對JSX有很好的支持，這可能就是微軟在最新版本的office中使用它的緣由]

Vue中的靜態類型檢查

Vue還利用Javascript ES6語法來編寫代碼。然而，當涉及到靜態類型檢查時，在Vue中使用Typescript就不是那麼簡單了。有一些課程是關於如何將Typescript和Vue一塊兒使用的，可是在複雜的項目中是否值得考慮仍然不清楚。

幸運的是，您能夠將flow與Vue集成並啓用靜態類型檢查。

React和Vue的模塊化

框架支持模塊化嗎?

根據模塊化原則，您的應用程序必須劃分爲獨立的模塊，每一個模塊表明單一的目的或功能。這一原則也被稱爲單一責任原則。

「作一件事並把它作好」——Unix哲學

讓咱們用一個簡單的現實生活用例來理解模塊化:

假設您的代碼庫包含一組專門爲API編寫的服務。如今，若是您的客戶端須要您從應用程序中刪除整個API功能，重要的是您要將這些服務保存在一個單獨的模塊中，以便在不破壞應用程序的狀況下輕鬆刪除這些服務。這就是您須要框架中的模塊化的地方。模塊化使得在應用程序很大的狀況下，能夠很容易地插入新特性，而更復雜的特性應該隨着版本的每次更改而迭代。

模塊化的React

在React中，應用程序的每一個部分都要處理組件。

在React中支持模塊化的一種理想方式是確保應用程序的每一個組件在理想狀況下只作一件事。即便組件在增加，更好的方法是將其進一步分解爲更小的子組件。

經過將代碼庫分割成小的、自包含的塊，它使React應用程序開發比Angular更直觀。您能夠單獨開發和測試模塊，這使得添加特性和識別錯誤變得更容易。

模塊化的Vue

Vue利用了「單文件組件」的概念。這彷佛是在分離關注點方面的權衡，由於您的腳本、模板和樣式將在一個文件中，但在三個不一樣的有序部分中。

學習曲線- React和Vue

我和個人同事可以輕鬆地學習這個工具嗎?

React的學習曲線

我觀察到許多開發人員聲稱，若是使用Vue，他們在React中所作的事情會更好、更容易。可是全部這些聲明對我來講都沒有意義。對我來講，Vue更像是一個簡單的JavaScript，還有一些新的想法，單向數據流、組件和事件驅動的模型。

Vue的學習曲線

在學習曲線方面，Vue賽過了其餘Javascript框架。您只須要一些像樣的JS技能或對ES6的良好理解就可使用Vue。總的來講，即便使用文檔自己，學習起來也容易得多。

開發者友好性和易用性

開始使用這個框架有多容易?

當涉及到開發時，框架應該更容易啓動。比較Reactjs與Vuejs或任何其餘框架的一種方法是，肯定在有項目需求時啓動它們的容易程度。

要爲您的項目選擇正確的框架，您須要肯定您和您的團隊想要在JSX仍是HTML上工做。爲了給您一個初步的概述，我想強調一下，基於標準HTML模板和組件的框架一般易於結構和代碼重用。然而，新開發人員更有可能發現難以處理JSX。

React:開發者友好性和易用性

React但願您構建組件而不是模板，由於組件是最可重用的，而且對單元測試友好。它依賴於JSX, JSX容許您混合UI模板和JavaScript。可是在一天結束的時候，你會以爲你是在Javascript上工做。使用JSX能夠極大地促進開發，由於它容許React顯示更有用的錯誤和警告消息。

因爲UI和JS代碼不能在React中分離，因此關於樣式的使用只有一個問題。

說到風格，你有多種方法來開始:

• 使用webpack提取您的導入' my '.css語句轉換成樣式表

• 或者使用 「CSS in JS」庫

當涉及到React項目時，它更像是一個狂野的西部，您擁有一個龐大的庫和工具生態系統來補充您的應用程序。就我我的而言，我真的很喜歡這樣，可是對於開發者來講，若是他們有不少選擇的話，作出正確的選擇並不老是那麼容易。此外，React沒有明確的規則或規章。每次應用程序的體系結構必然要改變時，您都必須選擇不一樣的內容。這使得事情的範圍很容易出錯。

Vue:開發者友好性和易用性

Vue被稱爲「進步web框架」是有緣由的，由於有不一樣的特性會影響正在開發的應用程序的大小。Vue還提供了一個CLI和與webpack等構建工具集成的包。在這種環境中編寫組件的最首選方法是單文件組件，即帶有模板、腳本和樣式標記的文件。

我過去與幾家公司合做過，當被問及選擇Vue的緣由時，他們給出的理由只是他們的開發人員以爲Vue更容易學習。Vue減小了初級開發人員和高級開發人員之間的差距，從而使他們在項目中很好地協做。它甚至對項目也有好處，由於它完成時bug更少，投放市場的時間更短。

測試和調試

框架的測試和調試方面有多好?

在React中測試和調試

測試:Facebook推薦Jest來測試React代碼。下面是Jest和Mocha 的比較——還有一篇文章是關於如何在Mocha 中使用Enzyme 的。Enzyme 是Airbnb使用的一個JavaScript測試工具(與Jest、Karma和其餘測試運行程序一塊兒使用)。若是您想閱讀更多內容，這裏有一些關於在React中進行測試的老文章(這裏和這裏)。

Vue的測試和調試

測試:目前，Vue缺少任何重要的測試指導，但Evan在他的2017預覽中寫道，團隊計劃在這方面工做。他們建議使用Karma。Vue與Jest一塊兒工做，還有Vue test Utils.。

調試:與調試任何其餘web應用程序同樣，Vue中的調試變得更加容易。您能夠利用開發工具、斷點、調試器語句等來調試應用程序源代碼。還有這個vVue.js devtools ，這樣您就能夠輕鬆地調試Vue應用程序。

在React和Vue中支持服務器端呈現

框架支持服務器端呈現嗎?

若是web應用程序的目標是優化高搜索引擎，服務器端呈現是一個基本要求。因爲任何多頁面應用程序均可以由幾個較小的spa組成，所以框架擁有這個選項是一個重要的標準。

如下是AirBnB的開發團隊對服務器端渲染的見解:

首先，與客戶端呈現相比，服務器端呈現具備更好的用戶體驗。用戶獲取內容的速度更快，當JS失效或禁用時，網頁更容易訪問，搜索引擎也更容易索引它。

React中的服務器端呈現

目前，React缺少關於***的官方文件。React API支持一個名爲ReactDOMServer的對象，當您但願以HTML代碼的形式顯示組件時，該對象很是方便。此外，學習如何使用諸如React Router和Redux這樣的庫，以便在沒有任何問題的狀況下執行服務器端呈現，也是很重要的。React團隊宣佈官方支持將很快發佈。還有一個框架能夠用來建立一個React ***應用程序，叫作Next.js。所以，React啓用了***，但沒有官方支持，而且使用了額外的第三方包。

Vue中的服務器端呈現

還有一個官方發佈的Vue.js指南，用於構建在服務器上呈現的Vue應用程序。該指南放置在一個特殊的領域，與Vue文檔分開。它很是詳細，而且假設用戶已經熟悉Vue，而且對Node.js和Webpack有必定的瞭解。此外，文檔引用了 Nuxt.js，是社區發佈的框架，是Vue中對***的更高層次的解決方案。它提供了某些附加特性，可是，它限制了開發人員對應用程序結構的直接控制。

Reactjs與Vuejs中的代碼可維護性

從項目開始算起，在5-10年以上的時間裏，這些代碼會給我帶來更多的麻煩嗎?

幾年前，個人一個客戶要求轉移到一個框架，以便如今和未來的開發團隊可以圍繞代碼工做。很明顯，對於他們來講，擁有一個高可維護性的框架是多麼重要。在比較框架時，代碼的可維護性應該是最重要的方面之一。

也就是說，如今讓咱們比較一下在代碼可維護性方面React和Vue是如何結合在一塊兒的。

React的可維護性

至於React，雖然通往0.14系列的道路也很坎坷，但從React 15開始，Facebook開始以一種更負責任的方式專一於作出突破性的改變。即將到來的破壞性更改如今會在您的應用程序中發出棄用警告，並給您時間遷移到新的api。

當前的穩定版本(第16版)改變了一些核心的生命週期方法，但也正式穩定了一些長期使用的「實驗」api，這意味着在達到這一點後，將來的更新會更容易。

因爲React在工具上的反應更輕，雖然一些破壞性的更新能夠自動化，但不是全部事情均可以。這意味着一些更新可能會比其餘的更痛苦，儘管在覈心庫中的改進一般是值得的。

React的一個明顯的煩惱是，舊版本文檔的刪除，使得現有(和潛在的將來)項目的維護更加困難，除非您保持最新。

Vue的可維護性

考慮到Vue的增加速度，決定Vue是否能夠用做長期運行的框架將是將來的事情。我不會詳細介紹這個方面，可是有一篇有趣的文章是關於Vue的可維護性因素以及它是如何應對的。

React vs Vue -性能和內存消耗

框架在性能方面是如何脫穎而出的?

說到性能，我想用這個簡單的一行代碼來講明個人狀況:

「每一個框架的績效評估都很重要，它絕對應該是評估一個框架的重要前提指標。」」

若是你還想知道這些框架在性能方面的突出之處，那麼你能夠經過這個綜合的研究，在DOM操做的基礎上對Reactjs和Vue的性能和內存消耗進行基準測試。這項研究是使用一個基準工具執行的，該工具測量了使用這些框架完成大量DOM操做事件所需的時間。

對React和Vue的性能進行基準測試

基準測試研究中包含的DOM操做基於研究這些框架在操做錶行方面的性能。對這一行進行的操做是:

• 向表中添加10行，

• 向表中添加1000行，

• 每隔10行更新一次表，

• 在表中選擇一行，而且

• 從表中刪除一行

當涉及到React和Vue的內存評估時，該研究利用了Chrome Profiler，它可讓你對網頁的JavaScript堆進行快照。

拍攝了兩個快照來演示在如下時間的內存使用狀況:

• 在執行任何操做以前加載頁面

• 在表上執行5個添加十、5個添加1000和5個更新操做以後

研究結果以下:

React性能和內存消耗

性能:如圖所示，當DOM更新愈來愈大，須要更新更多數據時，React的虛擬DOM彷佛得到了回報。這就是大多數React出現的性能問題。React在刪除和添加1000指標上的性能最好。

內存消耗:React的初始內存佔用與Angular很是類似。從初始狀態8.3 MB的內存消耗到DOM操做以後15.1 MB的內存消耗，您能夠看出響應DOM操做操做的計算開銷至關大，但它們仍然能夠。

Vue性能和內存消耗

性能:在大多數狀況下，Vue的性能與React同樣好，好比添加十、更新和選擇指標，極可能是這樣，由於Vue還利用虛擬DOM來操做操做。

Vue在性能方面反應滯後的惟一區別是增長了1000個指標，這是由於DOM操做操做數量的增長。

內存消耗:Vue在初始狀態時的內存佔用是7.6，考慮到它是純JavaScript語言，這比React和Angular都要好。然而，一旦執行了DOM操做，這個值就會增長到16.1，這比React和Angular都要大。

可擴展性——Reactjs vs Vue

框架是否足夠成熟，能夠構建可伸縮的應用程序?

當談到可伸縮性時，惟一重要的是您的解決方案如何處理請求的累積數量，以及在負載忽然達到峯值時它的顯著行爲是什麼。因爲大多數基於JavaScript的web應用程序都是爲大量用戶設計的，所以評估您選擇的解決方案是否具備可擴展性就變得很是有意義。話雖如此，讓咱們看看React和Vue是否知足可伸縮性預期。

React構建可伸縮的web應用程序

React只是一個用於在頁面上建立和呈現可重用組件的庫——您仍然須要收集一堆其餘庫來將它們組合在一塊兒(路由、HTTP請求等)。

web應用程序中的可伸縮性問題主要歸結爲代碼組織得有多好、技術債務的數量以及web應用程序如何做爲一個總體進行架構設計。

根據我我的與數千個客戶打交道的經驗，我發現像Angular這樣的框架絕對是可擴展的，由於開發人員從一開始就傾向於遵循這種設計模式。

不要誤解個人意思，我喜歡React，可是若是一個React應用程序從一開始就沒有通過很好的考慮，它可能會很快失控(好比不少意大利麪條式的代碼)。我曾經有一個客戶爲React編寫了一個自定義類模塊的特性，瀏覽他們的代碼很是愉快。

也就是說，React仍然能夠用於構建可伸縮的web應用程序，但只有在從一開始就考慮可伸縮性時纔會考慮。

Vue用於構建可伸縮的web應用程序

做爲輕量級的JavaScript庫，Vue只適合於較小的應用程序。它不適用於構建可伸縮的應用程序。

React vs Vue:應用程序大小

框架適合輕量級仍是重量級應用程序?

在爲大型應用程序選擇框架時，最重要的是一致性和架構決策制定。在大型應用程序中，明智地選擇框架是相當重要的。不然，轉換將是一個巨大的痛苦。

所以，讓咱們探討一下React和Vue的框架大小以及它們的大小對您業務的軟件開發項目的影響。

React

框架/庫的大小會對軟件開發項目產生重大影響。React大小約爲100kb，很是適合輕量級應用程序。此外，React還須要其餘庫對特定任務的支持，其中一個任務就是路由。它的小尺寸很是適合輕量級應用程序。

Vue

Vue是其餘框架和庫中最小的。它的大小大約爲80kb。它甚至比反應還要小。Vue很是適合開發輕量級應用程序。若是您須要一個小於Vue的庫，那麼您應該選擇Preact。

React vs Vue -在哪裏使用什麼?

這些框架的頂級實用程序是什麼?何時使用它們是正確的選擇?

如今咱們已經評估了幾乎全部必要的因素，讓咱們探索您的項目的React和Vue的最重要用例。它將幫助你選擇正確的一個，從而避免沒必要要的成本。

React

我認爲React是構建靜態網站的最佳選擇。您所須要作的就是使用renderToStaticMarkup呈現組件，並將呈現的有效負載發送給客戶機。

此外，選擇React開發小而簡單的應用程序可能並不過度，由於它是爲大型web項目建立的。。儘管React須要大量樣板代碼來設置一個工做項目，但從長遠來看，它的架構是值得的。

JSX提供了JavaScript的所有功能(如流控制)和高級IDE特性(如組件視圖模板中的自動完成)。

React vs Vue:對照表

Reactjs vs Vue:選擇正確框架的專家意見

我快速接觸了一些Javascript專家和CTO，詢問他們對於在React和Vue中選擇一個框架的見解。我感謝@KentCDodds和@TomGoldenberg對這篇博客所作的寶貴貢獻。

咱們問了他們一些問題，如下是他們對這場辯論的見解:

Thomas Goldenberg，突擊隊首席技術官你對著名的「React vs Angular vs Vue」辯論有什麼見解?

我用的是React和Angular，不是Vue。但我不會在這方面投入大量資金，由於我以爲它的應用不如另外兩種那樣普遍。因爲有了React和Angular，我確定以爲React對代碼更直觀。也就是說，Angular一直在進步，TypeScript也獲得了不少支持。

若是有機會構建一個社交網絡應用程序，你會選擇哪一種框架(或語言)?

Social意味着許多鏈接，這將使React - GraphQL成爲一個很好的組合。這將有助於準備全部鏈接數據。

若是有機會構建基於企業的電子商務web應用程序(有將來迭代的可能性)，您會選擇哪一種框架(或語言)?有什麼特殊的緣由嗎?

對於電子商務網站應用程序，我會使用Next.js，由於服務器端呈現對許多電子商務網站來講很重要，在這些網站中，每一個列表都必須是可索引和可搜索的。接下來真是太棒了，時代週刊的團隊也讓人印象深入。

若是有機會構建一個基於內容的平臺，站點結構不會發生變化，您會選擇哪一種框架(或語言)?

我也會用Next.js，由於基於內容的平臺須要有好的SEO和索引。

Kent C. Dodds, PayPal軟件工程師，Javascript/ React專家當你在React、Angular或Vue(或其餘幾個)中選擇一個合適的框架(或語言)時，你會考慮哪些方面?

全部這些框架在功能和性能方面都很是類似。與其餘框架相比，我更喜歡React是有一個緣由的，這個緣由是我相信它在概念上比其餘框架更簡單，而其餘框架會使應用程序更具可維護性和更容易測試。與其餘緣由相比，最重要的考慮是我在一個給定的框架下會有多有效，而React對我來講絕對是最好的一個。

若是有機會構建一個社交網絡應用程序，你會選擇哪一種框架(或語言)?

若是我有足夠的時間去學習，我可能會嘗試使用ReasonML做爲語言，而ReasonReact做爲框架。若是我須要快速完成它，那麼我確定會使用JavaScript(加上用於靜態類型的Flow)並對框架作出反應。

若是有機會構建基於企業的電子商務web應用程序(有將來迭代的可能性)，您會選擇哪一種框架(或語言)?有什麼特殊的緣由嗎?

若是我有足夠的時間去學習的話，我仍然更喜歡使用合情合理的語言和合情合理的框架。若是試驗和學習的時間更少，我寧願使用Javascript(加上用於靜態類型檢查的Flow)並做爲框架來響應。

若是你的開發團隊並不精通Javascript，你會選擇哪一種框架(或語言)?

我確定會選React。緣由是，我認爲一個開發團隊雖然不精通JavaScript，但構建web應用程序時確定應該學習JavaScript，而能教他們最好的JavaScript框架是React。其餘框架在隱藏JavaScript方面作得至關好，你最終會編寫比JavaScript更多的框架代碼，這在一開始看起來彷佛是正確的，但從長遠來看，團隊最好仍是好好學習JavaScript。

結論

React或Vue或任何其餘基於Javascript的解決方案就它們本身的用例而言都很是酷。我想說，沒有最好的解決辦法。最好由您來肯定您的用例，並將其映射到這些框架的各個方面。

爲了讓事情更簡單，我總結了用例和React和Vue之間推薦的解決方案(不老是):

• 若是你喜歡擺弄大量的libary、工具或生態系統，那麼選擇React

• 若是你是一個「JS迷」，而且討厭把你的UI和代碼分開——選擇React

• 若是你喜歡編寫乾淨和簡單的代碼——選擇Vue

• 若是你想盡快開始你的項目，選擇Vue

• 若是您是一個沒有團隊的單獨開發人員，請選擇Vue(或React)

• 若是您但願開發可伸縮的應用程序，而不爲測試和調試帶來任何麻煩，請選擇React

• 若是您想在您的項目中更好地分離關注點，請選擇Vue

• 若是你喜歡玩Javascript而且接受應用狀態變化的概念-選擇React(或Vue)

• 若是你要創建任何複雜的應用程序，有更好的上市時間-選擇React

那麼你對React vs Vue的比較有什麼見解，請在評論中告訴我。