2016 年的今天，Web 前端框架是否已經同質化？

01-01

React, Vue, 似乎都差不多的模式了。Angular2 也拋棄了 controller，完全組件化。
它們還有什麼區別嗎？

如果我們把「同質化」這個詞換一個說法，應該叫做「標準化」。這種標準可以認為是來自於技術進步所帶來的必然演化。

模塊化和組件化這種事情在後端界已經早已是常識，前端界為什麼才剛剛熱起來，難道前端人不懂計算機世界的基礎知識么？

我們把時間往前倒退五年，前端工程師們談及最多的還是IE6的兼容，還是瀏覽器的差異，直到今天，屏幕適配和手機機型兼容也是很多前端工程師日常要頭疼的事情。在前端只承擔UI和數據交互的時候，組件化和模塊化的複雜度，一直都是由後端來承擔的。

前端的另外一條發展脈絡是spa，所謂單頁面應用或者富客戶端。在微博看到（不記得誰說的）一個「邏輯守恆定律」，即：「業務邏輯的複雜度不會隨著結構優化而降低，而是在不同的系統中轉移分配。」富客戶端就是把原來後台框架承擔的邏輯移向前端，最早的時候我們用JQuery，後端承擔數據和路由，前端接入DOM；現代前端框架，已經接管了模板和路由，後端變成了純粹的數據支持；而Virtual DOM則更純粹的分離了頁面邏輯對於渲染引擎的依賴。

這一切的進化路徑是很自然的，需求就擺在那裡，原來大家不做是因為做不到，原來大家做的方式不同，是因為用了不同的奇技淫巧。大家同乘一輛歷史的列車，方向一定是一致的，但是在細節或者說「哲學」上又大概不會統一。正如有太多的編程語言，大家都有變數，循環，有函數，可我們並不覺得他們同質了，不是么？

隨著HTML5標準定稿，ES6在chrome（金絲雀）上也已經近乎全面支持，微軟大力推進win10普及，360瀏覽器讓小白用戶們也用上了最新的瀏覽器內核。當基礎達成，技術自然會向前推進，就好像2016年大熱的直播領域，當人均帶寬已經可以允許這個市場被進入的時候，這個市場的大門自然自己就會打開。

所以「同質化」其實是個偽命題，這就好像老師問你，為什麼小明卷子上1+1的答案是2，你寫的也是2，你們的答案為什麼這麼像。

因為正確答案就是2啊

謝邀。

首先要有一個論點：是的，根據 https://juejin.im 上的內容，技術框架很多的功能點都在趨於統一

Reactiveness
Module / Component Programming
Isomorphic JavaScript =&> Backend render / Flux（Vuex）
ES6/7 - Friendly
Virtual DOM

但是，我覺得不是前端框架趨於統一，而是前端開發需要解決的問題越來越明確且統一。

瀉藥

上面有高票答案表示很贊同，不是同質化而是標準化了。

視圖層方面，基本上各類框架/庫都是用的基於組件的方案，組件都具備基本的生命周期，差異只是鉤子的命名及細分程度不一樣而已。

狀態管理上基本就是兩個派系了，flux/redux rx，各有擁躉。

數據流向設計上，組件的單向數據流已經是主流了。毫無疑問單向數據流相比雙向數據流具備更好的可預測性，但這並不代表雙向綁定就是辣雞。很多場景雙向數據流開發會更有效率更簡潔，只是要避免濫用。Vue跟Angular對於兩者都能支持。

代碼編寫上，靜態類型檢查對於大體量應用而言重要性越來越強。樓主標籤的三個框架中，react/vue2都是用的flow，ng2則是侵入性更強的typescript。可以大膽猜測一下的是，es後面或許也會加入這個機制。

數據類型上，我猜Immutable類型會不會加入到es里？&>_&<

說了半天越來越「同質化」的原因也是web開發的基礎設施越來越完善了。

需要強調一點的是，儘管越來越「同質化」，但並不代表會有大一統的框架出現。總有一些愚蠢的開發者認為自己所喜愛的框架/庫是一個適用於任何場景的解決方案，然後拿著一把鎚子把所有東西都看成釘子。。還是那句陳腔濫調，拋開業務場景談解決方案都是耍流氓。

先想到這麼些。

以上

問得好。

我們先來研究一下前端主要做些什麼事。

占坑。

沒有啊，Cycle.js 就和React/Redux完全不同。

變化的曲線剛開始平穩些就被說同質化了，這樣真的好嗎

8考慮到另外一個情況很少人會在前端界專研5年以上現在的前端開發工程師真正有2年以上做個5個大型項目的都是非常之少而且很多後台和UI也在爭取前端的工作崗位我也是一個新手相對來說我們這些經驗不夠但是數量龐大的前端開發才是使用各種框架和模塊的主流用戶我們不需要那麼多奇奇怪怪的東西我們需要考慮的是如何做出老闆要求的東西保住我們的飯碗所以才會造成市場上那麼多同質化的框架出現我們需要的是我在學一個新的框架的時候最好幾天就可以做成點東西所以bootstrap和animetion.css才會那麼相像 jq和zepto才會那麼想與其說是瀏覽器在決定我們的開發方向不如說我們為了保證我們的飯碗選擇的開發方向題主您應該考慮到數量龐大的經驗不夠的前端開發會使用什麼框架就會導致這種框架的數量擴大舉個例子 swiper框架很火所以後來百度也弄了一個touch.js比如說手機h5頁面出來的時候我們新手們發現swiper框架可以幫助我們在2天甚至1天之內就能弄出一個看起來酷酷的網站老闆滿意客戶滿意就行了相信我大部分都不知道js已經開發到第六代了（手機碼字不方便很多錯別字）

條條大路通羅馬。

框架們是條條，要解決的問題是羅馬。

問題很有深度

技術發展大趨勢是一定的，但在大趨勢下還是可以有不同選擇和偏好。個人覺得前端的各種框架和技術還是會繁榮下去，但大方嚮應該還趨於一致。