英文: Kit Kelly 譯文:oschina vue
https://www.oschina.net/translate/web-frameworks-conclusions
是該讀些評論和作一些總結的時候了。當咱們開始寫這個系列博客的時候,咱們知道 JavaScript/web 應用框架並不太好總結。咱們努力對這個不可回答的問題做出回答:我該用什麼樣的框架?react
在這篇文章中,咱們將對這個系列中所提到的每款框架作一個總結,包括咱們所認爲的強項和弱項。另外,咱們爲你留下了一些值得思考的問題。web
我是否須要使用框架?typescript
若是不嘗試回答這個問題就是咱們的失職,這愈來愈成爲社會上某些人的口頭禪,在網絡平臺上的爭論也已經發展到猶如不須要額外編寫 API 能更簡單建立 Web 應用那樣的地步。就像本系列中全部的內容同樣,咱們的回答也大都是依據這些內容。redux
雖然無框架也能正常工做,可是,這也是有代價的。那些主張無框架手寫 Javascript 的人,那些一般會被咱們認爲是斯德哥爾摩綜合症(情感上會依賴他人且容易受感動的人)的人,忘記了網絡平臺上有多套快速發展的 API ,至少有三種不一樣的技術,三種大相徑庭的語法。web 平臺規範並肯定了超過 12000 個 API,事實上瀏覽器中的維恩圖也顯示了這些巨大差距。設計模式
若是你是一個有着深厚技術和經驗的人,確實能夠坦誠的不使用框架。但你團隊的其餘成員呢?你手下的那些人呢?或者當你的決定把你本身陷入困境的時候呢?這種狀況下,咱們將會看到一個不用框架的團隊在展開冒險,最後他們會發現本身建立了一個須要本身着手維護的框架。接着就會出現尋找人才的問題,他們不須要知道框架是如何工做的,只須要尋找會調用網絡平臺 API 的高級技能人才或者一些自稱有經驗的人才,最後卻發現缺乏利於團隊發展的技能深度和經驗。瀏覽器
團隊應該避免虛假等價(false equivalence)的陷阱,很顯然,在 web 技術的應用方面具備創新性的公司在不斷提升他們的市場價值和競爭力,Google、Facebook 和 Netflix 公司都是很好的例子。可是大多數公司不是這樣,他們應該認可這一點。安全
有什麼優點?網絡
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 最大的弱點不是它們是什麼,而是它們不是什麼。要構建一個功能豐富的 Web 應用程序,你須要許多功能,一旦脫離 React 和 Redux 和其餘一些庫的核心,你將發現一個很是分散的社區,擁有無數的解決方案和模式,不容易整合在一塊兒。
所以,雖然 React 和 Redux 都是很是專一的庫,但缺少經驗的團隊仍是會很容易地生成不可維護的解決方案,而不是意識到他們所作的選擇會致使性能不佳或錯誤。 即便有經驗的開發人員也可能意識到,一個鬆散的架構或慣例可能會在將來困擾他們。
假省錢是一種對本身的欺騙,組織範圍內採用 React 和 Redux 將輕鬆下降無效率問題。 沒有其餘庫和模式的普遍約定和標準化,標準化 React + Redux 比較於咱們正在採用的 JavaScript 來編寫咱們的應用程序效率要高。
Facebook 和 React 最近從繁瑣的附加專利糾紛中抽離,他們認識到,就像其餘項目同樣,更普遍的社區可以提升本身的聲音。 我以爲這有助於 Facebook 意識到他們還不能更好地瞭解咱們,相信咱們來引導項目。 但願這將繼續貫穿項目的特色和技術方向。
很難預測 React 和 Redux 的將來。 可是,將庫集中在一塊兒,確實會顯着提升適應性,大多數React + Redux 模式都會促進一個分離的體系結構,從而能夠輕鬆地進行重構和迭代。 兩年前,你們喜歡的仍是React + Flux,但整個社區很快就擁抱了Redux。 思惟或模式的其餘重大轉變可能很容易被採納。 這種關鍵能力可能會持續到將來。
若是你不多須要手把手指導,而且正在尋找更好的庫而不是全面的框架,那麼 React + Redux 多是正確的。 在這一過程當中,你不只須要對你的團隊和組織的能力保持誠實,還要在你的初始開發過程當中,以及在整個應用程序的長期維護過程當中保持誠實。
有什麼優點?
漸進式構建能力是 vue.js 最大的優點,vue 有一個簡潔並且合理的架構,使得它易於理解和構建。
vue 有一個強大的充滿激情人羣的社區,這爲 vue.js 增長了巨大的價值,使得爲一個空白項目建立一個綜合的解決方案變得十分容易。
在模型-視圖應用程序和狀態容器類型的應用程序之間的互相轉換可能會使人感到困惑,即便沒有完美包含一個模式到另外一個模式的完美轉換,但讓人感受但願能維持兩個模式的相關性。對於那些期待 vue.js 完美解決方案,並可能致使難以維護不一致的應用程序的人來講,這至少是使人困惑的。
一個更大的挑戰是 vue.js 依賴於一個單獨的人,很明顯,其餘的項目基本是由一個組織提供支持,但這讓人感受更加有意義,雖然它有一個強大文件的社區和許多有創新的新增項目,可是 vue 核心的開發基本落在一我的身上。
咱們很高興看到 vue 更加容易接受新興的標準方法,可是它的相似於 web 組件的模式,而不是真正的 web 組件,這多是 vue 所得不償失的地方。
雖然 vue.js 有至關普遍的應用,但也很難預測在中期發展中這個勢頭能持續多久,它不是由一個商業組織直接支持並維護,所以,這很大程度上依賴於維護者的生存能力和繼續維護下去的願望來決定。
它也表現出了必定程度的語言適應能力,而且隨着某些模式的落伍和失寵而繼續保持自身語言的現代化和時代性,目前沒有跡象代表 vue.js 架構未來沒法適應進一步發展。
若是你有一個傳統的 web 應用程序,並須要一個強壯穩健的應用程序層,那麼 vue.js 多是一個很好的選擇,它有清晰的模式,即便沒有經驗的團隊也能正確或者錯誤的使用它。儘管 vue UX 框架沒有開箱即用的功能,但在 vue.js 上也能大量持續性構建應用,這將有利於你的項目。
Dojo2 專一於帶來更多構建在狀態容器體系之上的動態組件的體驗模式,填補了 react+redux 等框架的許多空白。
Dojo2 也知道它不僅僅只是在本身的生態圈發展,經過包含 web 組件導入和導出功能,也意識到須要支持不一樣的應用實例,但它依舊提供了一個結構化和固有的框架價值,Dojo2 的核心基礎仍然是專一於提供交互性。
Dojo2 以爲它提供了大量重要的功能和解決方案,這對於構建完整的 web 應用是十分重要的,對於其餘大多數框架而言這並非重點。提供一個國際化系統和普遍的易接入性的模式也是其中之一,同時也提供一個主題系統和演進模式,用以確保不只能爲 Typescript/JavaScript 提供良好的代碼開發,也能像 CSS 那樣管理資源。
Dojo2 專一於提供一個結構化和符合人體工程學的開發環境,經過使用 typescript 和其餘開發模式,它試圖提供安全的防禦機制去引導新手開發人員,經過專一於提升框架開發效率和開發安全性,旨在讓開發團隊可以快速交付更好的 web 應用程序。
有爭論的是,經過進一步延長 Dojo2 的發佈時間的作法是不是在阻礙框架的發展,反觀其餘項目因爲其資源的擴大可以繼續發展和快速迭代,致使 Dojo2 目前明確的處在一個擁擠的競爭環境之中。
這也許是一個潛在的發展機遇和挑戰,同時但願可以在靈活性和交互性上而不是別的特殊理由去使用 Dojo2 。
Dojo2 將是將來優秀 web 框架之一,它將繼續努力爲構建可擴展性的 web 應用程序提供清晰的模式和指導。隨着新標準的不斷出現,Dojo2 將進一步努力去在框架中實現新的標準方法,繼續嘗試擴大框架的開放性和交互性,創造適合更多人使用的解決方案。
若是你想採用一個靈活的、現代的、響應式的 web 應用程序架構,而且你須要不少智能化的默認設置,那麼 Dojo2 將是一個不錯的選擇。不用去拼湊和構建一個管道,而且爲你提供更高階的命令模式讓你能夠更加專一的開發項目,更加確認它是直接爲你能夠直接生產開發所準備的。另外,若是你瞭解 typescript 的優點,Dojo2 會十分嚴謹的使用 typescript 來管理並提供一個穩健的開發者開發環境。
有什麼優點?
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有不少關於構建Web應用程序的方法,結構和想法。 這個框架的編寫有不少技術上的優勢。
有什麼弱點和挑戰?
咱們估計最大的挑戰就是核心發展的動力和臨界物質的缺少。咱們感受不少的觀點和概念都是咱們對其餘框架的批評性的想法,可是這些願望都沒有徹底交付。它彷佛就像是一個正在進行的工做同樣,就像Dojo 2,可是它已是一個已發佈的框架。
大部分的Aurelia是坐落在一我的的肩膀上,若是這我的的的注意力或可用性改變,那麼將會帶來挑戰。
將來會如何?
對於Aurelia來講,有一個很大的機會。若是它可以實現他的願景,他將要完整的保存這個構建Web應用程序的已有的模板,但會以更健全、更完整的方式交付。咱們不知道Aurelia是否可以充分的利用此次機會。
爲何我會選擇Aurelia?
若是您致力於Web模型視圖應用程序模塊,而且你和你的團隊試圖想把一些事作的更好,那麼Aurelia會是一個選擇。它就像是一個正在尋求一個更大的社區來幫助它的發展和進化的框架。
真心但願這一系列的帖子至少給了你一點思考,你應該很容易有這樣的想法那就是不可能有可驗證的正確決定。同時,但願你也意識到沒有廣泛的錯誤決定,你應該用一些問題和思考來武裝本身,幫助你選擇框架。
一個框架僅僅是一些模式的體現,一些科技的集成,源碼幫助咱們更加容易去構建和維護網站應用,若是你是個體開發者,咱們能提供的最好的建議是花費盡量多的時間使用那些你認爲能夠爲你所用的框架。若是你是公司的管理者或骨幹領導要去作決定,請記住特色列表只是決定的一方面,有時候並非越多越好。挑戰你本身活着你的團隊使用一個總體的框架,可是首先,列出對你和你的組織重要的列表,尤爲是那些技術以外特色。