自從angular/react/vue的出現(xiàn)顛覆了前端開(kāi)發(fā)者開(kāi)發(fā)模式以來(lái)，雖然新的前端框架依然不斷涌現(xiàn)，但是遲遲沒(méi)有一個(gè)新的前端框架進(jìn)入廣大前端開(kāi)發(fā)者的視野。本文會(huì)從近兩年越來(lái)越火的lowcode/微前端出發(fā)，探討在傳統(tǒng)前端領(lǐng)域，下一代前端工程/框架的可能方向。
一、lowcode
lowcode 其實(shí)一點(diǎn)也不新，通過(guò) GUI、配置化的方式代替?zhèn)鹘y(tǒng)的手寫(xiě)代碼編程，從sql語(yǔ)句到dreamweaver,基于模型驅(qū)動(dòng)的可視化的編程工具層出不窮。而近兩年lowcode的興起，筆者認(rèn)為主要有以下原因：1.前端技術(shù)體系及工程化體系成熟，許多有追求的工程師渴望用新的輪子追求變革式的生產(chǎn)效率突破；
2.前端開(kāi)發(fā)者依舊稀缺；
3.B端業(yè)務(wù)興起，大廠提前布局，希望在未來(lái)能夠商業(yè)化從中獲利；而和歷史上諸多嘗試相比，這次前端lowcode平臺(tái)的興起最大的不同: 大多數(shù)平臺(tái)的目的是為了解決普通人的編程問(wèn)題，而不再是開(kāi)發(fā)者的編程效率問(wèn)題。
1.1 國(guó)內(nèi)lowcode平臺(tái)
目前應(yīng)用比較廣泛的：
易企秀、淘寶天馬 這樣的基于頁(yè)面模板搭建，開(kāi)發(fā)人員開(kāi)發(fā)模板（或者開(kāi)發(fā)人員開(kāi)發(fā)模塊和模板），運(yùn)營(yíng)人員配置頁(yè)面；阿里云鳳蝶、百度愛(ài)速搭這樣的組件配置平臺(tái)（可以通過(guò)配置組件實(shí)現(xiàn)模板功能）。這些平臺(tái)都一定程度滿足了用戶快速建站的需求，特別是時(shí)間緊、沒(méi)有開(kāi)發(fā)人力時(shí)。
1.2 lowcode可以解決所有問(wèn)題嗎？
lowcode平臺(tái)是為了提升一部分交互簡(jiǎn)單的前端開(kāi)發(fā)場(chǎng)景開(kāi)發(fā)效率的，這也就是說(shuō)對(duì)于使用者來(lái)說(shuō)最大的問(wèn)題在于使用場(chǎng)景及時(shí)機(jī)的判斷上：誰(shuí)來(lái)判斷使用哪個(gè)lowcode的平臺(tái)，研發(fā)還是產(chǎn)品經(jīng)理？找到平臺(tái)后，誰(shuí)來(lái)判斷哪些業(yè)務(wù)可以使用平臺(tái)搭建？誰(shuí)來(lái)搭建？當(dāng)平臺(tái)只能滿足99%需求時(shí)怎么辦？所以很多時(shí)候，我們找到了平臺(tái)，配置了頁(yè)面，最后發(fā)現(xiàn)某個(gè)需求完成不了而不了了之。當(dāng)然，許多平臺(tái)支持開(kāi)發(fā)人員開(kāi)發(fā)定制模板或者自定義組件，但是，當(dāng)你有了自定義組件需求時(shí)，基于平臺(tái)開(kāi)發(fā)還會(huì)比自行開(kāi)發(fā)效率高嗎？
1.3 場(chǎng)景舉例
我們孵化了一款新的APP，希望配置一個(gè)簡(jiǎn)單宣傳頁(yè)，頁(yè)面內(nèi)容就是一張背景圖，一個(gè)下載按鈕。
我們使用平臺(tái)配置好了頁(yè)面，也配置好了按鈕的下載鏈接，此時(shí)PM提出了新需求，當(dāng)用戶已經(jīng)安裝了APP時(shí)不再下載而是直接打開(kāi)APP，我應(yīng)該基于平臺(tái)開(kāi)發(fā)一個(gè)自定義的action還是自己線下開(kāi)發(fā)下呢？？？
1.4 serverless
當(dāng)然，lowcode平臺(tái)也提供了一些serverless的功能，但還是那個(gè)問(wèn)題，誰(shuí)來(lái)評(píng)估要不要用serverless？誰(shuí)來(lái)使用？遇到不支持的問(wèn)題該怎么辦？
二、微前端要解決什么問(wèn)題
微前端是一種從后端微服務(wù)借鑒過(guò)來(lái)的架構(gòu)方式。市面上微前端的方案層出不窮，我就不列了，我們只需要明確下，微前端、前端微服務(wù)到底要解決什么問(wèn)題：利用服務(wù)化、微服務(wù)的概念，有效的拆分應(yīng)用，實(shí)現(xiàn)敏捷開(kāi)發(fā)和部署，解決大型項(xiàng)目的管理問(wèn)題。
2.1 場(chǎng)景舉例
兩個(gè)不同團(tuán)隊(duì)的業(yè)務(wù)，需要合成一個(gè)：電商平臺(tái)、視頻PC發(fā)布平臺(tái)，需要統(tǒng)一到同一個(gè)站點(diǎn)，讓用戶實(shí)現(xiàn)發(fā)布視頻、掛接商品一條路徑走通。
當(dāng)業(yè)務(wù)簡(jiǎn)單時(shí)，可以讓兩個(gè)團(tuán)隊(duì)協(xié)助工作，但是當(dāng)各自業(yè)務(wù)越來(lái)越復(fù)雜，會(huì)有越來(lái)多的問(wèn)題出現(xiàn)：技術(shù)棧必須統(tǒng)一開(kāi)發(fā)、部署耦合運(yùn)行時(shí)一個(gè)業(yè)務(wù)的BUG可能帶崩整個(gè)系統(tǒng)
2.2 為什么提到微前端
微前端的興起，說(shuō)明前端工程復(fù)雜度的提升，越來(lái)越多的人遇到類似的架構(gòu)問(wèn)題，說(shuō)明我們需要一個(gè)更上層的應(yīng)用框架來(lái)幫助我們解決類似應(yīng)用拆分隔離這樣的架構(gòu)問(wèn)題。
三、前端框架及前端工程化
3.1 前端框架
我們思考 jQuery/React/Vue 這幾個(gè)劃時(shí)代框架/類庫(kù)的共性，會(huì)發(fā)現(xiàn)他們都是為了解決視圖層的問(wèn)題而誕生的。
這不難理解，傳統(tǒng)前端的核心就是視圖，如何更快的幫助前端開(kāi)發(fā)者更好的完成視圖開(kāi)發(fā)工作，是大部分前端框架要解決的核心問(wèn)題。
jQuery簡(jiǎn)化了視圖層開(kāi)發(fā)的DOM API，React/Vue 更是繞開(kāi)了API，顛覆了頁(yè)面的開(kāi)發(fā)模式。這個(gè)過(guò)程中，隨著前端技術(shù)的發(fā)展，工程化在框架應(yīng)用中所占比重越來(lái)越大，大多數(shù)vue使用者創(chuàng)建項(xiàng)目都是通過(guò)vue cli創(chuàng)建。
3.2 什么是前端工程化？
工程化是一種思想，主要目的是為了提效，即提高開(kāi)發(fā)效率，減少不必要的重復(fù)工作。工程化常見(jiàn)的方向有模塊化、組件化、規(guī)范化、自動(dòng)化4個(gè)方面。
回顧前端框架的發(fā)展，會(huì)發(fā)現(xiàn)前端框架的發(fā)展其實(shí)和工程化發(fā)展相輔相成，繞開(kāi)DOM API、通過(guò)工程化實(shí)現(xiàn)更低的上手成本 是vue/react成功的根本，而vue/react在代碼運(yùn)行側(cè)已經(jīng)解決了足夠多的問(wèn)題，前端框架后續(xù)的發(fā)展焦點(diǎn)需要更多的偏向工程化。
四、下一代前端應(yīng)用框架
使用高度工程化的應(yīng)用框架進(jìn)一步推動(dòng)組件化發(fā)展，再度重塑開(kāi)發(fā)模式，這是我認(rèn)為下一代前端應(yīng)用框架需要做的事！
換句話說(shuō)，它需要更容易的讓開(kāi)發(fā)者解決組件化、自動(dòng)化、規(guī)范化等工程化的問(wèn)題，可以快速讓開(kāi)發(fā)者實(shí)現(xiàn)一個(gè)lowcode、procode、微
