以下內容多爲自己平時積累而來，思考和結論正確與否純個人觀點，希望對大家有所感悟和觸發~~~
先寫下兩個觀點和感悟：
- 每一項技術的誕生都是爲了解決現有技術的一些弊端或滿足現有發展的訴求；技術的發展會推動行業發展；行業的變革會衍生技術的變革！
- 前端行業是第二次信息產業浪潮的新產物！第三次、乃至第四次浪潮會帶來怎樣的變革以及淘汰哪些已有的觀念，值得我們思考~~
回顧
17年9月剛到公司，感覺公司前端最大的問題：不是統一UI、不是搞個新框架，而是要通過建全基礎設施，改變開發方式以及改變公司對前端的認知，將所有業務徹底解藕纔是癥結（前後端解耦、前端組件解耦）。
我們花了大約一年半的時間，來確立一套自己的基本遊戲規則：代碼規範、code review、Git的用法、開發流程、圖表管理等等；現在我們需要熟練這套規則，與此同時想着如何添磚加瓦（我們的fusion系列已經陸續展開 — 旨在打造自己的前端生態圈閉環）。
做這些事情往往要求我們忍耐默默無聞、要就經常跳出自己的舒適區，到另一個不熟的領域甘心當小白，目的只有一個切實有效的把產品中的前端問題解決掉。對我們而言，通常這麼做可以收穫到更多更深刻的經驗和知識，所以我們也樂此不疲。
首先，回顧從2017年10月份以來，我們做了哪些~~
- 「技術架構的確認」 — 我們確定並鞏固了 Vue 作爲觀安前端團隊的基礎架構地位，ElementUI + Echarts 成爲了我們首選。技術棧的統一，降低了產品間人員調動地成本，大大降低了架構層面的重複性問題。大家上手也可以更快，到目前爲止，大部分人獨立完成過前端架構的搭建~~
- 「源代碼管理規範化」 — 我們出臺了包括代碼開發、代碼管理、代碼發佈等等各種規範，避免了因多人協作而導致的風格不統一，保證產品的快速持續的功能集成。與此同時，我們提供了 Eslint 和 Commit Hooks 的結合處理；
- 「規範化 Git 工作流」 — 作爲公司的支撐線，我們面對的項目衆多，版本衆多。制定了 Git 管理流程（fork+分支）以及提交規範，以及採用Angular cz 來約束大家提交信息。在衆多業務線之間，達到了互不影響、平穩推進的效果；
- 「組件化過程」 — components => fusion 系列；組件化開發理念，可以快速拼裝出產品；
- 「衍生」 — 基於 fusion 構想，我們完成了大屏生成工具、自動打包工具等一系列腳手架和工具集。
再者，回顧近幾年前端圈，都發生了那些~~
- [框架] — 2013年 React 誕生，意味着 jQuery、Bootstrap 當紅時代即將結束。到今天前端框架逐漸形成 React/Vue/Angular 三足鼎立之勢。幾年前還在爭論單向數據流和雙向數據流孰優孰劣，現在三大框架已經不約而同選擇單向數據流，雙向綁定淪爲單純的語法糖。隨着應用複雜度上升，會發現數據散落在不同的組件，組件通信會變得異常複雜，Redux、Vuex、NgRx 相應的問世。框架間的差異越來越小！！！
- [端] — 2014年前後 IOS 以及 Android 開發炙手可熱，到如今的H5、RN、Flutter 以及混合式開發 PWA 已佔居鰲頭。更多用戶交互方式上變化，帶了技術的變更。
總之，擁抱變化是前端工作中應被灌輸的價值觀！
這麼多的變化，我們該何去何從？
- 工具是易變的，包括各種庫、框架到構建工具、編輯器等；(jquery => vue；webstorm => vscode；grunt=>webpack)
- 前端技術是演變的，其不會像工具那樣完全棄用，但新的標準（如ES6、TS）需要積極擁抱；
- 開發思想是不變的，在長期的開發實踐中不斷的總結、反思、衍生，其永遠不會過時。
切實解決問題爲導向，我們追求“最流行”的技術，但不盲目、不強加，加入自己的思考 。
當下
所謂“當下”，即是我們必須積極擁抱的技術，需要我們學習、嘗試並用到我們的項目上來~
TypeScript
Angular，React，Vue 底層語言已陸續全部換成了 Typescript（TS 是 JavaScript 類型的超集，其可以編譯成純 JavaScript）。TypeScript 提供最新的和不斷髮展的 JavaScript 特性，包括那些來自2015年的 ECMAScript 和未來的提案中的特性，比如 async…awati 和 Decorators，以幫助建立健壯的組件。TypeScript 最大的優勢是它提供了強大的靜態分析能力，結合 TSLint 能對代碼做到更加嚴格的檢查約束。實現了從後端 API 接口到 View 組件的全鏈路靜態分析，具有了完善的代碼提示和校驗能力。編譯通過幾乎就代表運行正常！！
自己的獨想：
三大框架發展至今，經過了 MVVM 思想剛誕生一刻的瘋狂叫賣，每個框架都沿着自己的理解發展壯大；經過2-3 年的沉澱，框架思想上又趨於了一致性，這裏包括 單向數據流、虛擬DOM、狀態管理等。這樣的發展並不是不好，而是一種趨勢，所謂的“天下大勢，合久必分，分久必合”吧。也相信在一個新的技術出現之前，三大框架在思想方面會越來越靠攏~~
GraphQL
GraphQL(Graph Query Language)一種用於 API 的查詢語言也是一個滿足你數據查詢的運行時。其提供了一套易於理解的完整描述，使得客戶端能夠準確地獲得它需要的數據，而且沒有任何冗餘，也讓 API 更容易地隨着時間推移而演進，還能用於構建強大的開發者工具。
GraphQL 誕生之前，是 Restful 的天下，GraphQL 帶來了哪些重量級改觀：
- 請求你所要的數據 不多不少；通過 GraphQL 可以準確獲得你想要的數據
{
user {
name
address
}
role {
org
}
}
- 獲取多個資源只用一個請求；典型的 REST API 請求多個資源時得載入多個 URL，而 GraphQL 可以通過一次請求就獲取你應用所需的所有數據
GraphQL 除了 JavaScript 實現，已有多種編程語言（包括Go、Java、PHP、Python等）支持。
web components
當時
document.querySelector首次被瀏覽器廣泛採用，就此終結了 jQuery 的通用時代（無需強依賴，帶來了一種更好的選擇）。隨着web components被各大瀏覽器廠商的支持，圈內出現了類 Web 組件即將取代前端框架 的討論，不管是否真的替代，但發展方向上值得我們關注
現代 Web API 發展至今，使我們有能力不依賴框架來創建可複用的前端組件。我們所需創建的自定義組件就是自定義元素和影子DOM，這可以在任意地方複用。這也是第一次我們僅通過 HTML，CSS 和 JavaScript 就成功構建了可兼容任意瀏覽器的可複用組件。單從 web components 給我們帶來的其不需要依賴於任何框架，即能完成組件的複用的效果，就可以博得我們的重視！
再深入討論，目前基本任一瀏覽器都可以使用Web組件，包括移動端瀏覽器（端的概念也得到了一種原生適配模式）。
css-in-js
css-in-js 方案依舊爭論不休，雖然它確實解決了一些 CSS 語言天生的問題，但同時增加了不少成本，新手不夠友好、全局樣式覆蓋成本高漲、僞類處理複雜、與AntD（樣式使用了Less作爲開發語言）等組件庫結合有坑。與此同時 Sass/Less 社區也在飛速發展，尤其是 Stylelint 的成熟，可以通過技術約束的手段來避免 CSS 的 Bad Parts。
微前端
中臺，一個被"玩壞"的詞，現在每個公司都在搞中臺，但其方式卻千萬種。對於前端來說，靈活多變是特色，但中臺卻是要趨於強大平穩。微前端，以獨立運行、獨立開發、獨立部署爲宗旨。
注意需要前後端分離的單頁應用，這是談論微前端的基礎
微前端是一種類似於微服務的架構，它將微服務的理念應用於瀏覽器端，即將 Web 應用由單一的單體應用轉變爲多個小型前端應用聚合爲一的應用。
爲什麼微前端開始在流行
前端需要的是解耦，更需要的是解耦後的聚合！
技術沒有銀彈，採用新技術，更多不是因爲先進，而是因爲它能解決痛點。解決遺留系統，纔是人們採用微前端方案最重要的原因。
思考我們的現狀：
情況一：一系列的安全產品且歷史版本較多（這反應了我們是按業務線劃分的組織架構）。但在用戶眼裏，觀安是一家公司，其應該就是一個產品（或者說，各產品應該相通的）。我認爲這個點在未來的某一天可能是我們最大的問題！
情況二：全文檢索、規則引擎，在每個產品中都有體現，存在各種遷移的情況。如果這些模塊達到了可以獨立運行和維護，以及和主項目組合的理想方式，我們便可以節省大量的時間！
到底前端中臺（微前端）該如何實現？我們該做哪些思考呢？
所以，聚合成爲了一個趨勢，體現在前端的聚合就是微服務化架構。
微件化、微應用化、路由分發、前端微服務化等。
微前端特點
各個前端應用還可以獨立運行、獨立開發、獨立部署。
- 業務專一：領域模型更聚焦，功能更單一，產品通道業務高度內斂；
- 職責專一：誰負責產品，誰就負責微前端和專屬業務中臺建設，並保證全通道內業務的高可用；
- 隔離性：同類產品的問題修復和代碼修改在一個產品通道內，不會影響其他產品通道的業務；
- 複用性：微前端可快速加入前端集成主頁面，或將微前端直接發佈成 APP；
- 響應能力：新產品通道可以獨立開發、測試、集成和部署；
- 測試和溝通成本低：一個產品通道由一箇中臺項目團隊負責；
- 技術敏感度低：微前端只要符合規範即可快速動態加載到前端集成主頁面，前端項目在前端集成過程中不需要關注中臺的技術實現和 API 集成，降低技術敏感度。
哪些方式
- 使用 HTTP 服務器的路由來重定向多個應用
- 在不同的框架之上設計通訊、加載機制，諸如 Mooa 和 Single-SPA
- 通過組合多個獨立應用、組件來構建一個單體應用(路由) 應用分發路由 ==> 路由分發應用
微服務在這個過程中做的事情是，將調用由函數調用變成了遠程調用，諸如遠程 HTTP 調用。而微前端呢，也是類似的，它是將應用內的組件調用變成了更細粒度的應用間組件調用，即原先我們只是將路由分發到應用的組件執行，現在則需要根據路由來找到對應的應用，再由應用分發到對應的組件上。 - iFrame，使用 iFrame 及自定義消息傳遞機制
- 結合 Web Components 構建
關注問題
- 依賴獨立。即各個微前端應用的依賴是要統一管理，還是要在各個應該中自己管理。統一管理可以解決重複加載依賴的問題，獨立管理會帶來額外的流量開銷和等待時間。
- 拋開前端中臺不談，如何切割前端業務粒度呢？同一業務、頁面、組件？還是如何？
- 業務切分下去，如何聚合？大的規則和平臺的搭建原則是什麼，路由？如果一個頁面是綜合頁，該如何處理？
- UI及交互的統一問題，以及各模塊或頁面的跳轉問題？
- 微服務用到的公共組件和方式如何處理，各自引用？還是集中構建時統一提供？按需？
- 多項目、多團隊，這是一個事實也是趨勢。如何統一構建和統一處理，是關鍵！
參考鏈接
Flutter
對於移動端開發，越來越多的人關注這樣一句話：Learn once, write everywhere. Write once, use everywhere. 低成本、高複用是移動端目前的一個主要方向。
回顧整體發展階段：
- 第一階段：Native App
在系統的 framework 上面不斷的開發新功能，Android、IOS、winphone、網頁端等等需要我們維護衆多版本，成本很高。所以就有了一個迫切的需求，能否開發一套在多個平臺上運行，這樣可以大大降低開發成本。 - 第二階段： H5
H5 的誕生，市面上出現了好多 H5 將替代 Android 等原生開發，與此同時出現了很多開源框架來實現 H5 與底層的交互框架(PhoneGap、cordova等)，實現了低成本、跨平臺的效果，但是性能問題導致其只能在很少的應用上取得成功。 - 第三階段： RN/WEEX
H5 性能瓶頸之一是繪製問題，通過原聲繪製的方式來實現成爲了主流。RN、weex等跨平臺方案應用而生。這種開發帶來的便利的同時，又有了新的問題產生了，就是橋的成本太高，當涉及到頻繁的跨橋調用的時候，就會出現性能問題；維護成本甚至一度超過了Native開發，對於一些小團隊來說簡直就是噩夢。 - 第四階段： Flutter
Flutter 是谷歌的移動UI框架，可以快速在 IOS 和 Android 上構建高質量的原生用戶界面。使用 Flutter 開發的APP 可以同時運行在 IOS 與 Android 平臺上，且都感覺自然流暢。 構建真正的原生移動應用程序（無需學習Swift、ObjectiveC、Java等語言）！Flutter 是一種跨移動平臺技術。
參考地址
PWA
Flutter 闡述完成，有必要再說下 PWA。
接着上面，H5 的發展，對移動端帶來了一定的衝擊，但是 H5 很難戰勝 Native App 在性能和功能上強大。除了昂貴的開發成本、然後審覈發佈到各個商店的複雜發佈流程，使得 Native App 較 Web App 有很大的差異。因此誕生了 PWA。
PWA（Progressive Web App）是一種理念，使用多種技術來增強 Web App 的功能，可以讓網站的體驗變得更好，能夠模擬一些原生功能（PWA 在傳統 Web 應用的基礎上，通過完善Web應用的一些能力，比如離線使用、後臺加載、添加到主屏和消息推送等，達到用戶體驗提升和性能優化）。在移動端利用標準化框架，讓網頁應用呈現和原生應用相似的體驗。PWA 本質上是 Web App，藉助一些新技術也具備了 Native App 的一些特性，兼具 Web App 和 Native App 的優點（需要考量的是，某些Native功能，PWA仍然實現不了，如調取攝像頭< 出於安全考慮>）。
強調漸進式的改善站點體驗主要有下面兩個原因：
- 降低站點改造的代價，逐步支持各項新技術，不要一蹴而就
- 新技術標準的支持度還不完全，新技術的標準還未完全確定
PWA 的流行主要包含以下幾個特點：
- 可靠 - 即時加載；即使在不穩定的網絡環境下，也能瞬間加載並展現。Service Worker
- 體驗 - 快速響應，並且有平滑的動畫響應用戶的操作。app Shell 架構模型
- 粘性 - 感覺就像設備上的原生應用程序，具有沉浸式的用戶體驗，用戶可以添加到桌面
https://lavas.baidu.com/pwa/README
2016年， PWA 在google正式落地，基於 Chromium 的瀏覽器 Chrome 和 Opera 已經完全支持 PWA 了；隨着 iOS 11.3 的發佈，iOS正式開始支持PWA；Windows Edge 支持PWA。
PWA 的出現，使得 Web App 可以具備 Native App 的特性。在做開發時，多了一個選擇，也多了一種思維方式
前端未來
信息產業的第一次浪潮是以信息處理PC機爲代表；以互聯網、通信網絡爲代表的信息傳輸推動了信息產業的第二次浪潮；而以傳感網、物聯網爲代表的信息獲取或信息感知，將會推動信息產業進入第三次浪潮。現在的前端，是由於互聯網浪潮帶來的，我們對於信息的傳輸方式的演變，從門戶 => 網站 => app => 各種端；信息的傳輸導致了發展；
然而，接下來會發生變化呢？AI？IOT？前端行業依附於整個信息產業，也誕生於第二次浪潮；信息產業本質或追求的變化，必然會導致前端行業的變化，或者導致新的行業產生。如何把握脈搏的發展，是需要我們關注的重點。
變化（全部來源於信息傳輸的推動）：
- 交互的改變：PC(鍵盤/鼠標) => 手機/PAD(觸屏/攝像頭/語音)，交互越來越自然、簡單了
- 載體的改變：文本 => 圖片 => 短視頻/直播，用戶創作內容的成本越來越低了
- 信息獲取的改變：主動獲取 => 被動推送 => 智能推薦，異步 => 實時，信息已觸手可及
發展（全部爲了滿足變化，同時也推動了變化）：
- 前後端分離：全棧、全端、大前端等分工模式的創新
- 開發套件：語法、框架、工具、類庫
- 引擎：V8(Nodejs)、Hybrid容器，方式的轉變
未來：
-
AI：算法的天下，但需要關注
-
IOT：硬件及嵌入式系統，把 Node.js、瀏覽器內核移植到 IOT 設備
nodejs將 javascript推進了服務器端；同理lot，將js推進到了更廣泛的設備。從簡單的語音控制檯燈，到複雜的javascript+物聯網智能家居，js的應用範圍越來越廣。
諸如可以使用 JavaScript 作爲開發語言的 IoT.js -
智能硬件：在 AI 、自動化控制及硬件上，給前端帶來的更多是應用形態和交互方式的升級
-
Blockchain：利用全新加密認證技術和全網共識機制，維護一個完整的、分佈式的、不可篡改的連續賬本數據庫，參與者通過統一、可靠的賬本系統和‘時間戳機制。IPFS協議，利用分佈式哈希表解決數據的傳輸和定位問題，把點對點的單點傳輸改變成P2P（多點對多點）的傳輸。
-
AR/VR/MR：
- AR：現實世界上疊加由計算機生成的虛擬形象，提供一個混合的視覺(手機掃描，出現一個人物)
- VR：虛擬現實，由計算機生成的三維環境，人可以在其中探索和交互
- MR：AR+VR結合
-
Serverless
最開始，一臺單用戶的物理服務器便能滿足我們的日常所需，它快速，可靠並且安全，只對管理員負責，但是在實際中配置和擴展都很麻煩；虛擬機的出現滿足了靈活性和可擴展性的需求；之後雲服務提供商爲我們帶來了基礎架構即服務（IaaS — Infrastructure as a Servic），雲平臺自助服務也由此誕生；再之後開始了集裝箱化，帶來了**平臺即服務（PaaS — Platform as a Service）**的架構；於此同時，程序員仍想要更多的功能，如獨立於編程語言（language agnostic）的端點，服務器的水平伸縮能力，以及可以實時支付服務使用量的能力。
爲了滿足這些需求，Serverless計算應運而生，Serverless 架構大量依賴第三方服務。採用 Serverless 架構，也就意味着，我們提取出了大量的基礎設施。Serverless 是付完即走，基於實際的消費而不是基於預測的預付款進行收費的—按需使用計費。Serverless 服務器架構是傳統的雲計算平臺延申，是 PaaS 向更細粒度的BaaS和FaaS的發展，Serverless=BaaS+FaaS+…！- BaaS（Backend as a Service）即後臺即服務
- FaaS（Function as a Service）即函數即服務
對於前端而言而使用 Node.js + JavaScript 作爲膠水，來快速連接不同的服務，以形成一個快速有效的方案。Node.js 在服務端的 Runtime 和運維方式，把服務端複雜的技術細節屏蔽掉，讓Node更好的在服務端延續。並且，編寫更少的代碼，也意味着更安全、快速。除了直接基於 AWS 的 Serverless Framework 框架的方案，還有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。
-
可視化開發：通過更好的開發套件提升應用生產效率，其最大競品是成品 SaaS，畢竟拿來就用比搭建更簡單，Wix、Webflow
對於我們最重要的：多端引擎(IOT)、可視化應用開發