每個框架都不可避免會有自己的一些特點，從而會對使用者有一定的要求，這些要求就是主張，主張有強有弱，它的強勢程度會影響在業務開發中的使用方式。 一、Angular，它兩個版本都是強主張的，如果你用它，必須接受以下東西：- 必須使用它的模塊機制- 必須使用它的依賴註入- 必須使用它的特殊形式定義組件（這 ...
每個框架都不可避免會有自己的一些特點，從而會對使用者有一定的要求，這些要求就是主張，主張有強有弱，它的強勢程度會影響在業務開發中的使用方式。
一、Angular，它兩個版本都是強主張的，如果你用它，必須接受以下東西：
- 必須使用它的模塊機制
- 必須使用它的依賴註入
- 必須使用它的特殊形式定義組件（這一點每個視圖框架都有，難以避免）
所以Angular是帶有比較強的排它性的，如果你的應用不是從頭開始，而是要不斷考慮是否跟其他東西集成，這些主張會帶來一些困擾。
二、React，它也有一定程度的主張，它的主張主要是函數式編程的理念，比如說，你需要知道什麼是副作用，什麼是純函數，如何隔離副作用。它的侵入性看似沒有Angular那麼強，主要因為它是軟性侵入。
你當然可以只用React的視圖層，但幾乎沒有人這麼用，為什麼呢，因為你用了它，就會覺得其他東西都很彆扭，於是你要引入Flux，Redux，Mobx之中的一個，於是你除了Redux，還要看saga，於是你要糾結業務開發過程中每個東西有沒有副作用，純不純，甚至你連這個都可能不能忍：
const getData = () => {
// 如果不存在，就在緩存中創建一個並返回
// 如果存在，就從緩存中拿
}
因為你要糾結它有外部依賴，同樣是不加參數調用，連續兩次的結果是不一樣的，於是不純。
為什麼我一直不認同在中後臺項目中使用React，原因就在這裡，我反對的是整個業務應用的函數式傾向，很多人都是看到有很多好用的React組件，就會傾向於把它引入，然後，你知道怎麼把自己的業務映射到函數式的那套理念上嗎？
函數式編程，無副作用，寫出來的代碼沒有bug，這是真理沒錯，但是有兩個問題需要考慮：
1. JS本身，有太多特性與純函數式的主張不適配
2. 業務系統裡面的實體關係，如何組織業務邏輯，幾十年來積累了無數的基於設計模式的場景經驗，有太多的東西可以模仿，但是，沒有人給你總結那麼多如何把你的厚重業務映射到函數式理念的經驗，這個地方很考驗綜合水平的，真的每個人都有能力去做這種映射嗎？
函數式編程無bug的根本就在於要把業務邏輯完全都依照這套理念搞好，你看看自己公司做中後臺的員工，他們熟悉的是什麼？是基於傳統OO設計模式的這套東西，他們以為拿著你們給的組件庫就得到了一切，但是可能還要被灌輸函數式編程的一整套東西，而且又沒人告訴他們在業務場景下，如何規劃業務模型、組織代碼，還要求快速開發，怎麼能快起來？
所以我真是心疼這些人，他們要的只是組件庫，卻不得不把業務邏輯的思考方式也作轉換，這個事情沒有一兩年時間洗腦，根本洗不到能開發業務的程度。
沒有好組件庫的時候，大家痛點在視圖層，有了基於React的組件化，把原先沒那麼痛的業務邏輯部分搞得也痛起來了，原先大家按照設計模式教的東西，照貓畫虎還能繼續開發了，學了一套新理念之後，都不知道怎麼寫代碼了，怎麼寫都懷疑自己不對，可怕。
我寧可支持Angular也不支持React的原因也就在此，Angular至少在業務邏輯這塊沒有軟主張，能夠跟OO設計模式那套東西配合得很好。
框架是不能解決業務問題的，只能作為工具，放在合適的人手裡，合適的場景下。
三、Vue，可能有些方面是不如React，不如Angular，但它是漸進的，沒有強主張，你可以在原有大系統的上面，把一兩個組件改用它實現，當jQuery用；也可以整個用它全家桶開發，當Angular用；還可以用它的視圖，搭配你自己設計的整個下層用。你可以在底層數據邏輯的地方用OO和設計模式的那套理念，也可以函數式，都可以，它只是個輕量視圖而已，只做了自己該做的事，沒有做不該做的事，僅此而已。
漸進式的含義，我的理解是：沒有多做職責之外的事。
