Instant2FA在2016年選擇Ember替代了React

約定超過配置
React最好的一點是，因為它只是一個檢視層，它可以很容易地被新增到一個預先存在的JavaScript應用程式。 三年前，當Clef的前端基於我們自己的物件導向JavaScript框架構建時，我們開始探索React是否可以幫助我們，這是最好的部分之一。 我們不是立即切換到新的框架，而是逐步用React元件替換不同的元件 - 只在必要時在React之上新增額外的邏輯層（如redux來處理資料流）。

隨著時間的推移，我們自己融入了React生態系統。 不同的庫會彼此重複，但能工作。 我們用了：
coffeescript
React檢視
reflux for data flow
react-router 2 for routing
jQuery.ajax for network requests
underscore for utilities

幾個月前，我們做了一個小的專案，我們必須從頭開始建立一個客戶端應用程式。 我們使用React一起進入檢視層，但考慮到過去幾年生態系統的戲劇性演變，我們最終使用了一個非常不同的組合：

ES6
React for the view
redux and redux-saga for data flow
react-router 3 for routing
fetch for network requests
lodash for utilities
webpack for module building
post-css & css-modules for styles
karma, mocha, sinon and chai for tests

每一步我們都詢問自己：這個庫包選擇錯誤了嗎？在React生態系統中使用工具配置我們框架，但是主要關心我們的配置是幫助我們還是傷害我們。

將高階架構技術決策委託給在域中經驗有限的工程師通常會導致錯誤決策。 我們是一個由4名工程師組成的Clef團隊，但由於我們定期在5個平臺（iOS，Android，後端Python，客戶端JavaScript和WordPress外掛）上維護程式碼，我們的工程師中只有兩個真正致力於我們的React應用程式。 在這個邊際專案作為一個團隊的工作結束時，我們為自己制定了一套後來經常被證明不穩定的工具，它們阻礙了我們完成工作。這裡體現了配置繁瑣的問題，如果工具框架能夠自動配置一些場景，也就是公約大於配置，那麼很顯然會提高生產力。

我們每個工程師有一半時間使用JavaScript，因此這意味著超過一半編寫程式碼的人將是相對缺乏經驗的JavaScript工程師。 相對缺乏經驗與前端工程 - 使得公約大於配置這個好處特別顯現。

當我們開始使用Ember實現Instant 2FA時，Ember為我們做出所有這些公約大於配置的決定思想 -是非常誘人的 。

mber內建了測試，測試在建立新單元（模型，路由，服務，序列化器等）時自動生成。 而我們在構建最後一個React應用程式，我們花了幾天時間設定測試工具，驗收測試以及所有其他必要的工具，以便擁有一個快速，易於使用的測試套件，我們仍然不斷對我們自己的這種設定感到失望。 Ember在框架中構建了接受和單元測試，我們希望這將使我們的程式碼更容易在每個級別進行測試。

在構建部署這塊，Ember公司是由ember-cli ，處理構建的每一步，這個工具鏈帶有開箱即用的預設值（例如ES6和模組），但圍繞這個標準建立的社群是最強大的部分。

在我們以前的設定中，每次我們需要改變構建build以實現特定的目標時，我們需要編寫自定義程式碼。 一個很好的例子是在我們的程式碼部署時將源對映上傳到Sentry。 在我們的React應用程式中，我們在完成webpack構建之後，是在shell指令碼中執行了這一操作。

使用ember-cli，幾乎所有我們需要補充的的新一步，都可作為Ember外掛，由於Ember強制執行約定，這些外掛幾乎總是開箱即用。 因此，我們的構建和部署邏輯已經從一系列自定義JavaScript和shell指令碼邏輯轉變為不同模組的乾淨組合，這些模組由不同社群維護著。

資料流和建模
Ember的資料流和永續性的預設實現依賴於ember-data，而在 React中，使用redux與redux-saga，總是試圖搞清楚如何將它們用在我們的專案中，而我們與ember-data已經建立了怎樣做事方式-即使其中的一些模式感到有點過時，因為ember-data和ember-cli都是統一由ember核心團隊維護的。

伺服器端呈現
Ember FastBoot能啟用伺服器渲染，在任何Ember應用中使用一個命令，在我們以前的React應用程式中探索了伺服器端渲染，我們知道對於圍繞React的每個庫配置都有一個同樣複雜的伺服器端渲染設定。 伺服器端呈現出來的不是我們需要的，因為有些我們還沒有啟用啟用它。現在使用一個cli命令，而不是捆綁一個大專案，這減輕了我們的負重。

漸進增強
當討論漸進增強的主題時，它通常指從純HTML＆CSS到高階互動式JavaScript應用程式驅動的逐漸增強網頁。

對於瀏覽Web應用程式的使用者，他們的體驗應該根據其使用的瀏覽器支援（或已啟用）的技術是逐步增強的。 使用者在沒有JS支援的瀏覽器中將獲得一個純粹的HTML和CSS體驗 - 雖然它可能較慢或笨重，仍然可以工作 - 而一個使用者使用提供JavaScript的現代瀏覽器，他們的體驗完全是現代。 換句話說，透過逐步增強，我們滿足使用者的需求，也許最重要的是， 他們得到最好的經驗，而他們自己無需做任何工作。

漸進增強的最好的想法應該在JavaScript框架和庫是顯而易見的，我們稱這種為漸進開發人員體驗（Progressive DX），它是的Ember框架和社群所定義目標之一。

在React生態系統中，漸進增強最常見的是透過建立新的庫包。 Flux正規化和單向資料流的概念是一個特別好的例子。當Facebook首次釋出Flux架構時，一些小型庫包實施了這種模式（其中一個是reflux，也是我們開始使用的庫包）。 隨著時間的推移，這些庫包中的許多已經消失了，而社群周圍形成了其他社群（如redux），但是概念的演變最常見的是透過引入新的庫包。對於在概念層面發展的每次新迭代，一個新的庫或工具需要被新增到您的工具：或搭售漸進增強的語言， 開發者需要改變他們的工具以獲得最佳的體驗。

相比之下，Ember的目標之一是給開發者當前總是可用，而不需要做任何工作（或儘可能少）,帶給開發者最好的體驗 。

在核心團隊評估期間，大家對Progressive DX這點感覺一致：Ember Fastboot（伺服器端渲染），glimmer（更快的渲染引擎），可路由元件（單向資料流）和服務（隔離關注）都是Ember體驗逐步增強的例子，通常可能是直接從其他框架已經引入的模式中借用，讓Ember使用者享受最好的網路技術。

更多見原文：

Choosing Ember over React in 2016

[該貼被banq於2016-11-17 11:48修改過]