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