Vue比React有什麼優點嗎?
黑React沒事,
黑Vue丟工作。
開個玩笑,兩框架我都用,不存在Vue能怎樣React不能,也不存在React能Vue不能。
如果在使用中,出現了上述的結論,那就是使用者水平太低。運行時性能
React 和 Vue 都是非常快的,所以速度並不是在它們之中做選擇的決定性因素。對於具體的數據表現,可以移步這個第三方 benchmark,它專註於渲染/更新非常簡單的組件樹的真實性能。
優化
在 React 應用中,當某個組件的狀態發生變化時,它會以該組件為根,重新渲染整個組件子樹。
如要避免不必要的子組件的重渲染,你需要在所有可能的地方使用 PureComponent
,或是手動實現 shouldComponentUpdate
方法。同時你可能會需要使用不可變的數據結構來使得你的組件更容易被優化。
然而,使用 PureComponent
和 shouldComponentUpdate
時,需要保證該組件的整個子樹的渲染輸出都是由該組件的 props 所決定的。如果不符合這個情況,那麼此類優化就會導致難以察覺的渲染結果不一致。這使得 React 中的組件優化伴隨著相當的心智負擔。
在 Vue 應用中,組件的依賴是在渲染過程中自動追蹤的,所以系統能精確知曉哪個組件確實需要被重渲染。你可以理解為每一個組件都已經自動獲得了 shouldComponentUpdate
,並且沒有上述的子樹問題限制。
Vue 的這個特點使得開發者不再需要考慮此類優化,從而能夠更好地專註於應用本身。
HTML CSS
在 React 中,一切都是 JavaScript。不僅僅是 HTML 可以用 JSX 來表達,現在的潮流也越來越多地將 CSS 也納入到 JavaScript 中來處理。這類方案有其優點,但也存在一些不是每個開發者都能接受的取捨。
Vue 的整體思想是擁抱經典的 Web 技術,並在其上進行擴展。我們下面會詳細分析一下。
JSX vs Templates
在 React 中,所有的組件的渲染功能都依靠 JSX。JSX 是使用 XML 語法編寫 JavaScript 的一種語法糖。
JSX 說是手寫的渲染函數有下面這些優勢:
- 你可以使用完整的編程語言 JavaScript 功能來構建你的視圖頁面。比如你可以使用臨時變數、JS 自帶的流程式控制制、以及直接引用當前 JS 作用域中的值等等。
- 開發工具對 JSX 的支持相比於現有可用的其他 Vue 模板還是比較先進的 (比如,linting、類型檢查、編輯器的自動完成)。
事實上 Vue 也提供了渲染函數,甚至支持 JSX。然而,我們默認推薦的還是模板。任何合乎規範的 HTML 都是合法的 Vue 模板,這也帶來了一些特有的優勢:
- 對於很多習慣了 HTML 的開發者來說,模板比起 JSX 讀寫起來更自然。這裡當然有主觀偏好的成分,但如果這種區別會導致開發效率的提升,那麼它就有客觀的價值存在。
- 基於 HTML 的模板使得將已有的應用逐步遷移到 Vue 更為容易。
- 這也使得設計師和新人開發者更容易理解和參與到項目中。
- 你甚至可以使用其他模板預處理器,比如 Pug 來書寫 Vue 的模板。
有些開發者認為模板意味著需要學習額外的 DSL (Domain-Specific Language 領域特定語言) 才能進行開發——我們認為這種區別是比較膚淺的。首先,JSX 並不是免費的——它是基於 JS 之上的一套額外語法,因此也有它自己的學習成本。同時,正如同熟悉 JS 的人學習 JSX 會很容易一樣,熟悉 HTML 的人學習 Vue 的模板語法也是很容易的。最後,DSL 的存在使得我們可以讓開發者用更少的代碼做更多的事,比如 v-on
的各種修飾符,在 JSX 中實現對應的功能會需要多得多的代碼。
更抽象一點來看,我們可以把組件區分為兩類:一類是偏視圖表現的 (presentational),一類則是偏邏輯的 (logical)。我們推薦在前者中使用模板,在後者中使用 JSX 或渲染函數。這兩類組件的比例會根據應用類型的不同有所變化,但整體來說我們發現表現類的組件遠遠多於邏輯類組件。
組件作用域內的 CSS
除非你把組件分布在多個文件上 (例如 CSS Modules),CSS 作用域在 React 中是通過 CSS-in-JS 的方案實現的 (比如 styled-components、glamorous 和 emotion)。這引入了一個新的面向組件的樣式範例,它和普通的 CSS 撰寫過程是有區別的。另外,雖然在構建時將 CSS 提取到一個單獨的樣式表是支持的,但 bundle 里通常還是需要一個運行時程序來讓這些樣式生效。當你能夠利用 JavaScript 靈活處理樣式的同時,也需要權衡 bundle 的尺寸和運行時的開銷。
如果你是一個 CSS-in-JS 的愛好者,許多主流的 CSS-in-JS 庫也都支持 Vue (比如 styled-components-vue 和 vue-emotion)。這裡 React 和 Vue 主要的區別是,Vue 設置樣式的默認方法是單文件組件里類似 style
的標籤。
單文件組件讓你可以在同一個文件里完全控制 CSS,將其作為組件代碼的一部分。
&
這個可選 scoped
屬性會自動添加一個唯一的屬性 (比如 data-v-21e5b78
) 為組件內 CSS 指定作用域,編譯的時候 .list-container:hover
會被編譯成類似 .list-container[data-v-21e5b78]:hover
。
最後,Vue 的單文件組件里的樣式設置是非常靈活的。通過 vue-loader,你可以使用任意預處理器、後處理器,甚至深度集成 CSS Modules——全部都在 &
標籤內。
規模
向上擴展
Vue 和 React 都提供了強大的路由來應對大型應用。React 社區在狀態管理方面非常有創新精神 (比如 Flux、Redux),而這些狀態管理模式甚至 Redux 本身也可以非常容易的集成在 Vue 應用中。實際上,Vue 更進一步地採用了這種模式 (Vuex),更加深入集成 Vue 的狀態管理解決方案 Vuex 相信能為你帶來更好的開發體驗。
兩者另一個重要差異是,Vue 的路由庫和狀態管理庫都是由官方維護支持且與核心庫同步更新的。React 則是選擇把這些問題交給社區維護,因此創建了一個更分散的生態系統。但相對的,React 的生態系統相比 Vue 更加繁榮。
最後,Vue 提供了 Vue-cli 腳手架,能讓你非常容易地構建項目,包含了 Webpack,Browserify,甚至 no build system。React 在這方面也提供了 create-react-app,但是現在還存在一些局限性:
- 它不允許在項目生成時進行任何配置,而 Vue 支持 Yeoman-like 定製。
- 它只提供一個構建單頁面應用的單一模板,而 Vue 提供了各種用途的模板。
- 它不能用用戶自建的模板構建項目,而自建模板對企業環境下預先建立協議是特別有用的。
而要注意的是這些限制是故意設計的,這有它的優勢。例如,如果你的項目需求非常簡單,你就不需要自定義生成過程。你能把它作為一個依賴來更新。如果閱讀更多關於不同的設計理念。
向下擴展
React 學習曲線陡峭,在你開始學 React 前,你需要知道 JSX 和 ES2015,因為許多示例用的是這些語法。你需要學習構建系統,雖然你在技術上可以用 Babel 來實時編譯代碼,但是這並不推薦用於生產環境。
就像 Vue 向上擴展好比 React 一樣,Vue 向下擴展後就類似於 jQuery。你只要把如下標籤放到頁面就可以運行:
&
然後你就可以編寫 Vue 代碼並應用到生產中,你只要用 min 版 Vue 文件替換掉就不用擔心其他的性能問題。
由於起步階段不需學 JSX,ES2015 以及構建系統,所以開發者只需不到一天的時間閱讀指南就可以建立簡單的應用程序。
原生渲染
React Native 能使你用相同的組件模型編寫有本地渲染能力的 APP (iOS 和 Android)。能同時跨多平台開發,對開發者是非常棒的。相應地,Vue 和 Weex 會進行官方合作,Weex 是阿里的跨平台用戶界面開發框架,Weex 的 JavaScript 框架運行時用的就是 Vue。這意味著在 Weex 的幫助下,你使用 Vue 語法開發的組件不僅僅可以運行在瀏覽器端,還能被用於開發 iOS 和 Android 上的原生應用。
在現在,Weex 還在積極發展,成熟度也不能和 React Native 相抗衡。但是,Weex 的發展是由世界上最大的電子商務企業的需求在驅動,Vue 團隊也會和 Weex 團隊積極合作確保為開發者帶來良好的開發體驗。
另一個 Vue 的開發者們很快就會擁有的選項是 NativeScript,這是一個社區驅動的插件。
MobX
Mobx 在 React 社區很流行,實際上在 Vue 也採用了幾乎相同的反應系統。在有限程度上,React + Mobx 也可以被認為是更繁瑣的 Vue,所以如果你習慣組合使用它們,那麼選擇 Vue 會更合理。
摘選自
對比其他框架 — Vue.jscn.vuejs.orgVue 有單文件模塊(.vue文件) 和 JSX
React目測只有 JSX單文件 寫 html,css,stylus,scass等 的確很簡單方便,但靈活度不如 JSX + jscssjsx是js級別的能力,而vue的template只是vue賦予的功能React通過setState函數渲染 Vue是監聽數據變更渲染react可以很細粒度的監控渲染(給setState傳遞迴掉函數),而vue通過 this.$next 來監控,很難知道哪些數據變更導致的渲染。Vue更追求實用一些,React更追求純一些(相對於Vue來說)為了實用Vue會改變一些直覺上的東西,比如vue的methods中this,是vue把data,props,compute..這些拼裝注入進去的,而不是this指向methods對象。框架能做的是有限的程序員能寫的是無窮的
較平滑的學習使用曲線,但有些人不需要。全家桶解救選擇困難症患者,但不少人不喜歡。
引戰!!!
天天問這些沒有營養的問題意義在哪? 自己用的喜歡就行!滿足工作需求就行!框架 只是個便捷的工具。項目好不好 主要還得看寫代碼的 人的技術水平! 很多人 寫的 vue、react 寫的項目像坨屎樣!比那 些jquery用的溜的人用jquery寫的項目 不管是 代碼 結構 ,還是 代碼速度上 差一大截。最後一句話,用的什麼框架不重要,主要還得看重要的是 寫代碼的人!
最近在學習使用兩個框架的 SSR 功能,Vue 提供官方的 SSR 使用指導和解決方案 http://ssr.vuejs.org,而 React 則更多的是社區自行探索,對非同步組件的支持 Vue 原生完美支持,React 則需要自己探索方案或者藉助第三方包如 react-async-component 之類的,服務端 CSS 的支持 vue-style-loader 完美支持常用的預處理器的用法,而 React 方面更多的是 百花齊放的 CSS in JS 方案。
Vue 希望官方幫用戶儘可能多地解決問題,提供標準化的工具,React 則希望專註於視圖層,其他問題社區自己解決,這是兩個完全不一樣的產品哲學。
我個人更希望 Vue 的方式,當然 React 的方式對自己的技能增長很棒,所以都是要學的。
關於 React SSR 最近模仿 vue-server-renderer 整了一個 react-server-renderer,希望做到和 Vue SSR 一樣的使用體驗,有興趣可以看下:https://github.com/JounQin/react-server-renderer ,實例:https://github.com/JounQin/react-hackernews 。vue比react全家桶簡單。react默認使用es6(最新版本使用),需要一定的學習路線,vue默認es5。vue的中文文檔是目前前端框架最好的(我用react,這點兒我也挺佩服vue的,畢竟vue在國內市場佔比高於react)。react需要jsx(也可以不用),但是jsx需要學習成本。vue的vue-cli比create-react-app優秀(功能多)。vue目前是個人開發,react是fb開發。vue提供的api很多,可以實現很多功能。相比react,後者需要一定的經驗才能寫出同樣的功能。vue是個大雜和,react剛好相反,每個功能獨立成模塊。後者的學習路線長,也更難。vue幾乎不需要手動優化,因為vue已經自己處理好了。react一些時候需要自己優化。暫時想到這麼多。
都用過一些,只談感觸最深點。vue對數據源的操作比較方便,路由和狀態管理以及調試工具整合的比較好。但是slot比起react的children來要不方便不少。
vue上手簡單,文檔寫得好。漸進式框架。從簡單到複雜的應用都能輕鬆應對。react的話 完全在寫js,寫起來比較爽。但是redux這些比較麻煩
vue和react都可以看成是一種理念,現在vue可以做的地方太廣了,桌面客戶端 服務端渲染等等,以前ui上複雜的東西,現在都可以用vue,當然react也可以做,不過vue主打的快速上手可以吸引大量的開發者,優勢明顯。
為啥都說vue簡單呢?vue將結構、樣式、腳本放在一個文件中(這一點react不行),非常方便開發。路由有vue-router、狀態管理有vuex,獲取數據可以使用axios,腳手架有vue-cli,該有的都有了。
簡單、語法糖多、文檔對國人友好
謝邀,最近收到很多這種問題邀請我答,
我就說3點總結,也不酸那麼多技術名詞,以免反感,也沒有時間
1.vue 相對react 入門、上手都簡單-語法明快,api好理解
2. vue 和react本是一家 ,vue借鑒了react的組件概念,並優化的更好用,合原生js html無縫對接3. react比vue 好的最明顯的一點是,世界範圍內 react更受歡迎,組件合開源方案更多,vue更多的是華人再用,而且上手簡單,不用理會太多太多的 專業概念。以此判斷,你自己判斷
簡單應用構建視圖vue簡單,如果單文件的話jsx方便,引用3個js即可識別jsx。。。
優點就是vue可以在不依賴webpack,babel下也可以類組件開發,而react則很難。對於很多人來說,真的特別討厭寫前端也需要代碼編譯轉換。