關鍵時刻，第一時間送達！
在這篇文章中，我們将對 6 款主流 Web 架構進行總結，包括我們所認為的強項和弱項。另外，我們為你留下了一些值得思考的問題。
我是否需要使用架構？
如果不嘗試回答這個問題就是我們的失職，這越來越成為社會上某些人的口頭禅，在網絡平台上的争論也已經發展到猶如不需要額外編寫 API 能更簡單建立 Web 應用那樣的地步。就像本系列中所有的内容一樣，我們的回答也大都是依據這些内容。
雖然無架構也能正常工作，但是，這也是有代價的。那些主張無架構手寫 JavaScript 的人，那些通常會被我們認為是斯德哥爾摩綜合症（情感上會依賴他人且容易受感動的人）的人，忘記了網絡平台上有多套快速發展的 API ，至少有三種不同的技術，三種截然不同的文法。web 平台規範并确定了超過 12000 個 API，事實上浏覽器中的維恩圖也顯示了這些巨大差距。
如果你是一個有着深厚技術和經驗的人，确實可以坦誠的不使用架構。但你團隊的其他成員呢？你手下的那些人呢？或者當你的決定把你自己陷入困境的時候呢？
這種情況下，我們将會看到一個不用架構的團隊在展開冒險，最後他們會發現自己建立了一個需要自己着手維護的架構。接着就會出現尋找人才的問題，他們不需要知道架構是如何工作的，隻需要尋找會調用網絡平台 API 的進階技能人才或者一些自稱有經驗的人才，最後卻發現缺少利于團隊發展的技能深度和經驗。
團隊應該避免虛假等價（false equivalence）的陷阱，很顯然，在 web 技術的應用方面具有創新性的公司在不斷提高他們的市場價值和競争力，Google、Facebook 和 Netflix 公司都是很好的例子。但是大多數公司不是這樣，他們應該承認這一點。
Angular 2+
有什麼優勢？
Angular 2+ 的最大優勢在于它的流行程度。也有人認為它和 Google 密切相關的名字，會影響團隊使用它。Angular 1 的迅速流行是因為那些來自其他互動式應用程式開發環境的人會發現對于開發單頁面 web 應用程式具有相似的模型-視圖模式。
通過對 Angular 1 進行現代化演變和重新建構架構的某些部分，Angular 2+ 已經真正的爆發了，大量的正式的和非正式教育訓練機構數量都讓人印象深刻，開發者有很強的市場競争力。對于使用者來說它有一套用于建構使用者界面的豐富元件，這也是本系列中少有的幾個架構能夠做到這點。
有什麼弱點和挑戰？
我們覺得 Angular 架構着重于在單個頁面應用程式中建立使用者界面并沒有處理建構完整的 web 應用這個更大的關注點，如果不及早确定下來，這将會導緻整個項目難以維護，在實際項目中，運作時提供不屬于核心架構的技術往往讓人覺得不可思議，這大大降低了 TypeScript 對最終開發者的價值。
未來将何去何從？
Angular 5 剛剛釋出，這看來是 Angular 已經成功的印證了快速釋出版本的承諾，在 Google 的持續支援下，Angular 會越來越成熟。
像許多的大型組織一樣，Google 具有多重（分裂）的人格，從外表上看，Angular 團隊和那些專注于浏覽器标準的團隊之間顯得很和諧。但我們的觀點是，和諧隻是一層薄薄的窗戶紙。Angular 團隊對于 web 元件和漸進式 web 應用沒有一個真正解決方案。我們認為，業界普遍認可的标準将會在 Angular 架構中會逐漸實作，這将會影響到如何更好的建構 Angular 應用将成為一個中/長期的風險。
何時選擇 Angular 2+
如果你需要在一個大型的架構内擷取技術資源，架構内的技術通常很容易移植；或者你需要在架構中訓練開發人員，并且還要有一定的信心，他們會在短期内獲得一定的開發能力，這樣的話你可以考慮 Angular 2+ 。需要注意的是 Angular1（angular.js）與 Angular2+ 是截然不同的，其中的應用、技術和經驗不能直接移植到 Angular2+ 的開發中去。
如果你的 Web 應用能夠很好的轉化為标準的模型-視圖模式，那麼你也可以忽略其他直接考慮使用 Angular2+ 。
如果你對 Google Material UX 設計模式滿意，那麼 Material Angular 是遵循該模式的一種快速、簡單且可靠的方式。
React + Redux
React 和 Redux 的最大優勢在于它們相對簡單和專注。做一件事情并把它做好是非常困難的，但這兩個庫都很有效地完成了它們的目标。雖然對于某些狀态容器方法可能是外部的，但大多數開發人員還是可以輕松掌握概念，并了解單向資料體系結構的好處，簡化大量的使用者界面應用程式。
React 和 Redux 最大的弱點不是它們是什麼，而是它們不是什麼。要建構一個功能豐富的 Web 應用程式，你需要許多功能，一旦脫離 React 和 Redux 和其他一些庫的核心，你将發現一個非常分散的社群，擁有無數的解決方案和模式，不容易整合在一起。
是以，雖然 React 和 Redux 都是非常專注的庫，但缺乏經驗的團隊還是會很容易地生成不可維護的解決方案，而不是意識到他們所做的選擇會導緻性能不佳或錯誤。 即使有經驗的開發人員也可能意識到，一個松散的架構或慣例可能會在未來困擾他們。
假省錢是一種對自己的欺騙，組織範圍内采用 React 和 Redux 将輕松降低無效率問題。 沒有其他庫和模式的廣泛約定和标準化，标準化 React + Redux 比較于我們正在采用的 JavaScript 來編寫我們的應用程式效率要高。
Facebook 和 React 最近從繁瑣的附加專利糾紛中抽離，他們認識到，就像其他項目一樣，更廣泛的社群能夠提高自己的聲音。 我覺得這有助于 Facebook 意識到他們還不能更好地了解我們，相信我們來引導項目。 希望這将繼續貫穿項目的特點和技術方向。
很難預測 React 和 Redux 的未來。 但是，将庫集中在一起，确實會顯着提高适應性，大多數 React + Redux 模式都會促進一個分離的體系結構，進而可以輕松地進行重構和疊代。 兩年前，大家喜歡的還是 React + Flux，但整個社群很快就擁抱了 Redux。 思維或模式的其他重大轉變可能很容易被采納。 這種關鍵能力可能會持續到未來。
何時選擇 React + Redux？
如果你很少需要手把手指導，并且正在尋找更好的庫而不是全面的架構，那麼 React + Redux 可能是正确的。 在這一過程中，你不僅需要對你的團隊群組織的能力保持誠實，還要在你的初始開發過程中，以及在整個應用程式的長期維護過程中保持誠實。
Vue.js
漸進式建構能力是 Vue.js 最大的優勢，Vue 有一個簡潔而且合理的架構，使得它易于了解和建構。
Vue 有一個強大的充滿激情人群的社群，這為 Vue.js 增加了巨大的價值，使得為一個空白項目建立一個綜合的解決方案變得十分容易。
在模型-視圖應用程式和狀态容器類型的應用程式之間的互相轉換可能會令人感到困惑，即使沒有完美包含一個模式到另一個模式的完美轉換，但讓人感覺希望能維持兩個模式的相關性。對于那些期待 vue.js 完美解決方案，并可能導緻難以維護不一緻的應用程式的人來說，這至少是令人困惑的。
一個更大的挑戰是 vue.js 依賴于一個單獨的人，很明顯，其他的項目基本是由一個組織提供支援，但這讓人感覺更加有意義，雖然它有一個強大檔案的社群和許多有創新的新增項目，但是 vue 核心的開發基本落在一個人身上。
我們很高興看到 vue 更加容易接受新興的标準方法，但是它的類似于 web 元件的模式，而不是真正的 web 元件，這可能是 vue 所得不償失的地方。
雖然 vue.js 有相當廣泛的應用，但也很難預測在中期發展中這個勢頭能持續多久，它不是由一個商業組織直接支援并維護，是以，這很大程度上依賴于維護者的生存能力和繼續維護下去的願望來決定。
它也表現出了一定程度的語言适應能力，并且随着某些模式的落伍和失寵而繼續保持自身語言的現代化和時代性，目前沒有迹象表明 vue.js 架構将來無法适應進一步發展。
何時選擇 Vue.js？
如果你有一個傳統的 web 應用程式，并需要一個強壯穩健的應用程式層，那麼 vue.js 可能是一個很好的選擇，它有清晰的模式，即使沒有經驗的團隊也能正确或者錯誤的使用它。盡管 vue UX 架構沒有開箱即用的功能，但在 vue.js 上也能大量持續性建構應用，這将有利于你的項目。
Dojo 2
Dojo2 專注于帶來更多建構在狀态容器體系之上的動态元件的體驗模式，填補了 react+redux 等架構的許多空白。
Dojo2 也知道它不單單隻是在自己的生态圈發展，通過包含 web 元件導入和導出功能，也意識到需要支援不同的應用執行個體，但它依舊提供了一個結構化和固有的架構價值，Dojo2 的核心基礎仍然是專注于提供互動性。
Dojo2 覺得它提供了大量重要的功能和解決方案，這對于建構完整的 web 應用是十分重要的，對于其他大多數架構而言這并不是重點。提供一個國際化系統和廣泛的易接入性的模式也是其中之一，同時也提供一個主題系統和演進模式，用以確定不僅能為 Typescript/JavaScript 提供良好的代碼開發，也能像 CSS 那樣管理資源。
Dojo2 專注于提供一個結構化和符合人體工程學的開發環境，通過使用 typescript 和其他開發模式，它試圖提供安全的防護機制去引導新手開發人員，通過專注于提高架構開發效率和開發安全性，旨在讓開發團隊能夠快速傳遞更好的 web 應用程式。
有争論的是，通過進一步延長 Dojo2 的釋出時間的做法是否是在阻礙架構的發展，反觀其他項目由于其資源的擴大能夠繼續發展和快速疊代，導緻 Dojo2 目前明确的處在一個擁擠的競争環境之中。
這也許是一個潛在的發展機遇和挑戰，同時希望能夠在靈活性和互動性上而不是别的特殊理由去使用 Dojo2 。
Dojo2 将是未來優秀 web 架構之一，它将繼續努力為建構可擴充性的 web 應用程式提供清晰的模式和指導。随着新标準的不斷出現，Dojo2 将進一步努力去在架構中實作新的标準方法，繼續嘗試擴大架構的開放性和互動性，創造适合更多人使用的解決方案。
何時選擇 Dojo2？
如果你想采用一個靈活的、現代的、響應式的 web 應用程式架構，并且你需要很多智能化的預設設定，那麼 Dojo2 将是一個不錯的選擇。不用去拼湊和建構一個管道，并且為你提供更高階的指令模式讓你可以更加專注的開發項目，更加确認它是直接為你可以直接生産開發所準備的。另外，如果你了解 typescript 的優勢，Dojo2 會十分嚴謹的使用 typescript 來管理并提供一個穩健的開發者開發環境。
Ember
Ember.js 可能是最固執己見的主流架構，這也是其最大的優勢。它有建立 Ember.js 應用程式的正确方法，通常隻有一種方法來建立應用程式。Ember.js 更類似于一個産品或平台，在那裡你會到一個供應商的長期支援和維護。Ember.js 提供了對其平台的全面版本管理，更新工具以及對 API 更新的強大指導和工具。成熟，是對 Ember.js 的一個很好的總結。
Ember.js 多年來已經證明，它可以保持其架構并使其與現代标準保持一緻，同時不會過早遺忘傳統浏覽器。
Ember.js 有一個清晰合理的架構來全面建構 Web 應用程式。
Ember.js 可能是最固執己見的主流架構，這也是它最大的弱點。雖然社群是開放的并且接受投資，但是仍然需要找到一個正确的方式來擺脫下滑的趨勢，這可能是具有挑戰性的問題。
擁有一個豐富的第三方社群也可能具有挑戰性。由于沒有開箱即用的 UX 元件，這很可能會讓你使用第三方套件。你可能會發現，雖然這些套件并不全面，你将需要建立或尋找其他元件。由于 Ember.js 沒有擴充，是以對如何互動和管理 DOM，你會發現你有不一緻的部件，而且也沒有提供一個易于管理的界面。
未來該何去何從？
Ember.js 的主要貢獻者是 JavaScript 語言标準委員會 TC39 的核心參與者。在過去的幾年中，Ember.js 對 JavaScript 的方向比任何其他架構都有更直接的影響。我們的觀點是，這将在未來繼續受影響，并幫助促進 JavaScript 的特性和模式。這也意味着 Ember.js 将繼續保持與未來标準的緊密結合的關系。
Ember.js 不可能在将來随時消失，盡管他們的創新很可能是通過與 Ember.js 緊密結合的其他項目來實作的，比如 Glimmer，它為 Ember.js 應用程式提供了一個新的 UI 架構，該架構基于 TypeScript。
為什麼我會選擇 Ember.js？
如果你在架構中尋找成熟度，那麼 Ember.js 很難出錯。另外，由于 Ember.js 提供的内容被了解，并且有廣泛的官方和官方認可的教育訓練，以及嚴格的結構，找到能夠建立基于 Ember.js 的應用程式的人才可能比其他架構更容易。也可以教大型團隊如何建構應用程式，并確定整個團隊的共同對話和了解。
如果你想要對社群保持信心，并批判性地思考他們平台的變化，那麼 Ember.js 會是一個很好的考慮因素。您可以花更少的時間跟随目前的技術趨勢，并更多地關注建立應用程式。
Aurelia
優勢在哪？
Aurelia 有很多關于建構 Web 應用程式的方法，結構和想法。 這個架構的編寫有很多技術上的優點。
我們估計最大的挑戰就是核心發展的動力和臨界物質的缺乏。我們感覺很多的觀點和概念都是我們對其他架構的批評性的想法，但是這些願望都沒有完全傳遞。它似乎就像是一個正在進行的工作一樣，就像 Dojo 2，但是它已經是一個已釋出的架構。
大部分的 Aurelia 是坐落在一個人的肩膀上，如果這個人的的注意力或可用性改變，那麼将會帶來挑戰。
未來會如何？
對于 Aurelia 來說，有一個很大的機會。如果它能夠實作他的願景，他将要完整的儲存這個建構 Web 應用程式的已有的模闆，但會以更健全、更完整的方式傳遞。我們不知道 Aurelia 是否能夠充分的利用這次機會。
為什麼我會選擇 Aurelia？
如果您緻力于 Web 模型視圖應用程式子產品，并且你和你的團隊試圖想把一些事做的更好，那麼 Aurelia 會是一個選擇。它就像是一個正在尋求一個更大的社群來幫助它的發展和進化的架構。
最後的思考
真心希望這一系列的文章至少給了你一點思考，你應該很容易有這樣的想法那就是不可能有可驗證的正确決定。同時，希望你也意識到沒有普遍的錯誤決定，你應該用一些問題和思考來武裝自己，幫助你選擇架構。
一個架構僅僅是一些模式的展現，一些科技的內建，源碼幫助我們更加容易去建構和維護網站應用，如果你是個體開發者，我們能提供的最好的建議是花費盡可能多的時間使用那些你認為可以為你所用的架構。
如果你是公司的管理者或骨幹上司要去做決定，請記住特點清單隻是決定的一方面，有時候并不是越多越好。挑戰你自己活着你的團隊使用一個整體的架構，但是首先，列出對你和你的組織重要的清單，尤其是那些技術之外特點。