終於有時間把稀土開發者大會上講的「Web 開發引擎」和「低碼」話題的分享，改成文字版發出來。

現場演講中後半部分內容是脫稿講的，我重寫成了更全的內容。

「越來越龐大的應用開發需求」和「現代 Web 開發範式的紅利」這兩個部分的幻燈片，雖然在其他分享裡用過，但在這個話題裡，用途是不同的，文字內容是不同角度的，建議不要略過。

分享實錄

大家好，我是來自位元組跳動 Web Infra 的楊揚。 在位元組跳動，我們部門負責打造和發展「Web 技術中台」和「前端研發體系」。

上午的主題演講中，位元組跳動正式發佈了 Modern.js 開源專案，這個專案的目的是推動現代Web開發範式的普及，發展完整的現代Web工程體系，突破應用開發效率的瓶頸。 現在這個專場雖然是關於低代碼的，但我要分享的內容，也是完全依靠這套現代 Web 工程體系，才能夠實現。

上午有講到Modern.js是位元組內部整套現代Web研發體系的三大組成部分之一，我這次側重講的，是其中的另一個組成部分：「低代碼開發管線」。

議程

低代碼是一個很寬泛的話題，如果背景不同、需求不同，解決方案也會差別很大。 所以在這次分享的第一個部分里，我們先明確一下這套方案背後最根本的需求是什麼，然後在第二部分，我們盤點下各種低碼、零碼解決方案在這個背景下的瓶頸問題，最後第三部分來看下「全碼」通用搭建是怎樣的解決方案。 先來看看根本需求：

一、突破研發提效天花板

1.1 「越來越龐大的應用開發需求」= ？

最根本的需求就是應用開發在數量、範圍、效率上的需求，大家都知道從PC互聯網到移動互聯網，軟體應用被用於更多日常生活場景和更多企業場景，導致應用數量大幅增加，這種趨勢到現在不但沒減弱，反而還在加強，比如幻燈片上 IDC 的預測，這麼龐大的應用開發需求，是很難靠傳統的軟體開發方式和人才儲備來滿足的。

最常說的解決途徑就是靠低代碼、零代碼工具，就像幻燈片里右側這張圖，當前市場上存在非常多的這種產品，國內大廠在內部建設的這類專案也非常多。

但這些專案普遍更適合垂直、局部的場景，只支持相對有限的能力。 大幅增加的應用開發需求帶來更高的多樣性、更廣的場景和更高的品質要求，其中很多都仍然需要專業開發者的參與，而當前這些低碼零碼專案又普遍的難以跟專業研發協同工作，所以才會有我們今天的話題——如何跟研發體系結合，突破傳統低碼技術的瓶頸。

剛才說的這些場景下的應用開發需求，在初始狀態下，會完全等同於對專業開發者的需求。 我們不應該跳躍思維的直接鑽到低碼解決方案的牛角尖裡，而是應該先站回起點，看看在專業開發方面能提效到什麼程度，能滿足多少需求，有什麼瓶頸，因為低碼方案的競爭對手不是只有其他低碼方案，而是首先要跟成熟完善的專業研發體系「競爭」。

既然這些場景下的應用開發需求，最初完全等同於對專業開發者的需求，那麼顯而易見的提效方法，就是讓盡可能多的開發者能獨立、完整的開發這些應用，而前端技術棧的開發者，正是最大的開發者群體和技術社區。

所以在使用者、產品、市場這一側，一直有趨勢和壓力，需要更多「前端開發者」成為「應用開發者」或「產品開發者」，鼓勵和倒逼著技術領域，不斷產生更有利於這種需求的技術形態和基礎設施。

不是技術領域，而是商業領域，需要更多「前端開發者」成為「應用開發者」或「產品開發者」，背後的原因除了剛才說的，還有一個，就是隨著移動互聯網又重走了PC互聯網時代入口網站、瀏覽器的老路，除了少數作為領域入口的超級App，像實體、內容、服務這樣海量、高頻的需求，都更傾向用Web技術來實現，需要前端技術背景的開發者。

研發產品最初是從最接近機器的底層開始發展，從虛擬化，到容器編排，到基於容器技術的各種平臺化、服務化的研發工具形態（就像圖上綠色部分），這個階段是後端技術主導的，但整個趨勢是越來越向上層發展，越來越接近市場和商業價值最終所在的地方——也就是面向用戶的產品，因此必然會發展到前端技術主導的抽象層，讓應用開發和產品開發能更專注於使用者需求， 而越來越不需要關心伺服器端的複雜性和專業技術細節。

所以市場需求會趨向於推動應用開發方式往「專注於前端」的方向的發展，「專注於前端」就等同於「專注於使用者」，而「專注於使用者」是多數企業、產品的根本利益所在。

在這種客觀趨勢的推動下，基於 Web 技術的應用開發中，伺服器端的佔比和門檻一直在不斷下降。

國內大廠的中台建設，提供了大量不跟特定用戶端捆綁、專注於數據需求和底層業務邏輯的 API，讓產品開發更聚焦在上層的用戶端業務邏輯。

海外流行的 Headless CMS 本質上也是一種中台，也起到同樣的作用。

還有 BaaS 和基於雲函數的後端雲 Serverless，進一步降低伺服器端的門檻，讓前端開發者能更獨立的、端到端的完成產品開發。

但要進一步降低門檻，提高效率，以上模式的一個缺陷就暴露出來，就是他們都把應用依賴的 API，放在應用專案之外維護，跟前端研發是割裂的，這樣帶來的問題和效率瓶頸很多。 還有一個缺陷就是不解決 API 之外的伺服器端需求，比如 SSR 等「Web」需求。

要克服這些缺陷，必然需要新的模式，比如明天上午專場會介紹的Modern.js中，前端工程方案覆蓋了完整全棧開發的各個環節，但同時又通過一體化、盡量無伺服器化的方式，實現「用戶端為中心」的現代 Web 開發範式。

這些開發範式、開發工具方面的發展，都創造了條件，讓更多「前端開發者」成為「應用開發者」或「產品開發者」，工作中也更關注工程，而不像傳統前端開發者更關注視覺和交互。

1.2 研發提效的天花板

但無論怎樣改進現代 Web 開發體系，改進基礎設施，都面臨提效的天花板。 因為研發效率提升到一定程度之後，就會發現效率瓶頸主要在工作內容本身上面。 只要一個前端每周有大半時間要做基礎但又繁瑣的 CRUD 中後台、臨時的活動頁面等事情，被這些緊急但不重要的事情佔據，或頻繁打斷，再怎樣在研發內部做提效，也改善不了多少。

1.3 「接力」範式

要突破這塊研發提效的天花板，就要不局限於研發內部，而要關注軟體開發的整個工作流程。 然後我們會發現，跟其他創造事物的工作，比如平面出版、攝影、遊戲、建築等，跟這些相比，軟體研發的工作流是一個另類。

在這些工作中，掌握領域知識的業務專家，都對真實產物是有瞭解的，也能直接掌控，比如平面設計師懂印刷、攝影師懂鏡頭和膠片、建築師懂材料和施工，大家都通過工具直接真實產物打交道。

而軟體研發中，開發者只在少數領域，比如開發工具等，是業務專家，在多數像電商、O2O 等領域里無論如何都是支援型的角色，但軟體研發的工作流卻是一種獨特的「接力」範式，只有開發者才能直接跟真實產品打交道，能真正掌控產品，其他業務專家用再好的工具，產出物都是假東西，比如線框圖、交互原型、高保真設計稿，都是對真實產品的一種效仿。 工作流中每個環節都有幻燈片上列出的這些痛點，研發提效的天花板，也來自這裡。

1.4 「圓桌」範式

遊戲研發是垂直領域的軟體研發，由於創新多、工作量大參與者多等特點，遊戲開發更不可能忍受剛才說的「接力」範式工作流，很值得我們學習。

遊戲研發的工作流可以稱作「圓桌」範式，真實的代碼就是中間的圓桌，所有分工都圍著這張桌子，用各種適合自己的工具，直接跟代碼交道，產出的都是最終遊戲中真實的組成部分，不需要做假東西去跟程式師溝通，等程式師把這些東西用代碼從頭實現出來。 遊戲程式師也可以專注於更有價值的事情，實現新效果、新玩法、開發提效工具等等。 遊戲程式師跟代碼交道使用的工具，跟策劃和美術使用的工具雖然差別很大，但都來自同一個遊戲引擎套件，套件中的不同工具都基於同樣的框架、架構、標準。

在位元組跳動，Web Infra 有一個「Web 開發引擎」子部門，就是致力於在軟體研發領域實現這種以代碼為中心的「圓桌」範式。

為了讓所有分工都盡可能直接跟真實代碼打交道，在同一套「研發管線」里工作，需要專業研發環節有高度抽象的、標準化的工程和工具體系，這也是我們打造和發展「現代 Web 工程體系」 Modern.js 的原因之一。

另一方面可以看到，這次分享最初提出的「越來越龐大的應用開發需求」問題，到這裡我們已經明確研發提效能到什麼程度，有什麼瓶頸，低碼解決方案能帶來什麼説明，而且更重要的是，這樣引入的低碼解決方案，是跟專業研發體系無縫結合的。

二、低/零碼宇宙之熵

接下來我們看看，為什麼需要新一代的低碼解決方案，才能滿足前面的需求，現有的各種低碼、零碼解決方案有什麼瓶頸。

2.1 RAD

我們逐個看下不同形態的方案，第一個是歷史悠久的 RAD 工具。

這種工具有點兩極化，一部分開發者把這種工具稱作「神器」，有很高的評價，一部分開發者完全不熟悉它們，覺得跟自己沒關係，這背後的重要原因是，RAD 工具是要跟特定技術棧、框架緊密結合，才能實現在研發環節中引入低碼提效的，所以對不是這個技術棧的開發者沒有意義。

這也體現了 RAD 的瓶頸，就是只能面向開發者，無法服務更多不懂技術的使用者，滿足越來越多的應用開發需求。

2.2 CMS

第二個形態是同樣歷史悠久的CMS。

如今 CMS 不但沒過時，反而被發揚光大，國內大廠的很多中後台，本質都是 CMS，疫情期間發展很好的美國電商平臺 Shopify，也是 CMS。

這種模式的瓶頸問題有兩個，一個是更適合配置「內容」，難以解決更多應用開發需求，另一個問題是 CMS 是需要基於範本的，配置的是範本中的可變部分，也跟具體的用戶端和伺服器端的實現捆綁在一起，讓它不可能靈活滿足各種需求。

2.3 Website/H5 Builder

第三種形態是近十年來興起的，由於國內外的差別，在國外流行的是網站搭建，在國內流行的是活動搭建。

他們本質上都相當於 RAD 中偏設計的部分，跟 CMS 的結合體。 這種模式突破了 RAD 的瓶頸，讓非技術用戶能夠使用。

但仍然跟 CMS 一樣，需要基於範本，基於平臺第一方提供的元件庫，以及伺服器端。 這樣一方面跟專業研發是割裂的，研發很難提供優化、定製方面的支援，另一方面也是平台鎖定的。

2.4 Headless CMS

第四種形態，是同樣從CMS發展而來的HeadlessCMS。

去掉了跟特定用戶端和範本的捆綁，只輸出 API，可以比較靈活的建模。

瓶頸是，只解決了應用開發的一半，沒有客戶端，本質上更類似 BaaS 服務。

2.5 aPaaS

第五種形態是近年來大名鼎鼎的 aPaaS。

它是從 SaaS 發展出來的，傾向作為特定 SaaS 的配套，滿足企業定製需求，相當於替代了盒裝軟體時代，像 SAP 這樣的企業軟體需要專門到企業現場去做的定製開發和實施。

aPaaS 要實現對特定 SaaS 做定製，本質上靠的是後端配置化：把 SaaS 後端業務邏輯的局部做成可配置，幻燈片上的建模和編排是最常見的。 所以在 aPaaS 裡創建出來的定製版 SaaS，跟原版 SaaS 其實還是同一個應用，後端實現、資料庫都在一起。

這些也構成了 aPaaS 的瓶頸：通用性不強，跟特定 SaaS 或 垂直場景捆綁在一起，適合企業軟體領域。

2.6 BPM

第六種是 aPaaS 中流程編排的放大版。

BPM 不再跟特定 SaaS 捆綁，而是作為連接器串聯大量的 SaaS 和服務。 適合企業流程定製。

瓶頸是只能滿足這種模式的應用開發需求。

2.7 No Code

第七種是 SaaS 的另一種發展。

像 Airtable 這樣的 No Code SaaS，不是在 SaaS 的外部做配置，而是直接在 SaaS 自身的使用中做配置，滿足各種需求，把消費和搭建混合在一個介面裡。 Excel 其實也是這種模式的應用。

這種模式的瓶頸是，在數據能力和介面能力上，都是相對範本化的，不能實現任意應用。

2.8 Design Tools

第八種形態是新一代設計工具，比如Webflow、Framer等。

不需要設計稿轉代碼環節，設計過程本身就在編輯代碼產出代碼。

這種工具的瓶頸是編輯過程中包含大量設計細節和決策，繁瑣，對用戶的設計能力有高要求，更適合設計師。 但設計師的設計過程是偏探索、隨意的，這種工具的編輯器過程更結構化、有更多約束，在設計師中推廣也有難度。

2.9 前端可視化搭建

第九種形態不是產品形態，而是國內技術領域常見的概念，「前端可視化搭建」跟「元件庫」、「腳手架」，可以並稱為國內前端技術團隊最常建設的三件套。

就像 aPaaS 是跟特定 SaaS 緊密結合、在這個領域做建模、把 SaaS 的後端業務邏輯做「配置化」，前端可視化搭建也是對垂直領域的前端需求做建模，把前端開發工作「配置化」。

包含「前端可視化搭建」在內的「傳統前端技術棧」，可以表示成幻燈片上這樣（之前的分享中介紹過），從下往上表示抽象層不斷提高，藍色部分都是前端代碼、工程化相關的要素，可以看到「前端可視化搭建」這個紅色的方塊，跟藍色部分一樣，是從下到上「端到端」的。

這裡想表達的意思是，「可視化搭建」的一大瓶頸問題，就是跟專業的前端研發方式彼此割裂。

前面說過「前端可視化搭建」的本質，是把部分前端開發工作轉變成「做配置」，所以物料生態、物料開發方式、產物的預覽方式、運行方式、發佈方式等，都是圍繞這種「配置」方式，重新建設一套，跟專業前端的開發方式和基礎設施，是彼此割裂的。

很多前端可視化搭建專案，也會設計和開放出來一套「Pro Code」方案，滿足使用者在搭建中的自定義需求，但這種「Pro Code」跟專業前端真正的 Pro Code 仍然是割裂的。

核心原因跟前面說的一樣，為了把前端從「做開發」變成「做配置」，總是需要先針對垂直領域做建模，形成一套配置檔，或配置風格的代碼，這裡統稱為「DSL」，用這套 DSL 替代正常的代碼實現，實現能運行這套 DSL 的渲染器，再基於 DSL 實現可視化編輯器。

這種可視化搭建的實現方式，設計和實現都相對簡單，門檻低，而付出的代價之一，就是必然跟專業前端的日常研發體系割裂。

圍繞這種 DSL 的可視化搭建，在物料環節，必然存在平臺鎖定的問題。 用於可視化搭建的元件，跟專業前端日常開發中沉澱的元件，彼此不互通，降低了元件建設的 ROI。 為了在編輯器里對元件做配置，需要為每個元件都去額外開發維護一套配置介面，不管是範本專案的形式、JSON form schema 還是其他形式，都提高了元件的維護成本。 以上這些反過來也影響了沉澱和維護改進業務元件的積極性，導致無論專業代碼開發還是可視化搭建，物料積累都比較少。

另一方面在渲染、部署環節，不但要專門維護渲染器和平台設施，也導致業務的前端開發同學難以支援和掌控。

物料積累少，建設難，對性能穩定和功能難以支援，都局限了可視化搭建的使用範圍和效果。

「前端可視化搭建」跟 aPaaS 一樣，都面臨兩難選擇，無論選擇專注特定業務和領域，還是追求通用，都會有不同的瓶頸問題，最終結果都是 ROI 不高。

2.10 應用開發領域的「關卡編輯器」現象

前面我們已經盤點了九種低碼、零碼項目的形態，最後這種不是特定的專案，而是一種普遍現象。

在遊戲開發中，關卡編輯器是創作大部分遊戲內容的工具，遊戲引擎通常自帶關卡編輯功能，但很多遊戲都會針對自己的獨特玩法開發專用的關卡編輯器，一方面滿足獨有需求，一方面讓編輯器更垂直化，提高效率。

低碼搭建領域也有同樣的現象，很多業務場景都會開發自己專用的低碼搭建。

瓶頸問題一方面當然是海量（特別是在國內）的重複建設和彼此割裂，另一方面，在國內（特別是大廠）有很多讓這些專案基於一套通用「協定」的嘗試，目前為止還沒有真正意義上成功的例子，背後的根本原因，也跟前面說的「DSL」模式有關，在這種模式里，「DSL」是天然傾向跟垂直領域緊密結合的，難以通用化。

三、奇點：「全碼」通用搭建

盤點了現有的各種低碼、零碼解決方案的瓶頸。 最後來看下現代 Web 研發體系裡的「全碼」通用搭建，是怎樣的解決方案。

在位元組內部我們把這套解決方案稱作「星夜」。 星夜是作為「Web 開發引擎」的一部分，在位元組內部驗證、發展出來的，適用於任意應用的搭建，它從最初就被設計為完全基於全功能的專業代碼，跟包括Modern.js在內的現代Web研發體系能夠無縫結合。

星夜針對的消費者，既有專業的現代 Web 開發者，也有懂技術但不擅長前端開發、現代 Web 開發的人，以及不懂技術的需求方（比如運營、銷售等角色）。

3.1 上帝的歸上帝，凱撒的歸凱撒：解耦「複雜度」

星夜做的事情，首先本質上是在解決軟體開發的複雜度問題，對複雜度本身做抽象和解耦，把不可避免的複雜度留給專業開發體系，讓低碼平臺能專注於「業務邏輯的最後一公里」，只負責不需要專業開發者介入的膠水代碼。

3.2 「現代 Web 開發」範式的紅利

另一方面，星夜也把自己完全建立在現代 Web 研發體系之上，把問題盡可能都交給專業研發體系去解決、抽象，自己只在上層做低碼領域的額外建設。 研發體系的提效做的越好，星夜就越不需要在上層去用非專業的方法重複解決問題。

實際上這種「全碼」通用搭建，也是因為有現代 Web 開發範式的紅利，才能夠實現的，明天上午的專場會專門介紹 Modern.js，我們這裡快速看一下這套現代 Web 工程體系是怎樣為「全碼」通用搭建帶來可能。

3.2.1 從「前後端分離」到「前後端一體化」

在 Web 研發中，最初前端代碼「寄居」在「伺服器端 Web 框架專案」的裡面，隨著之後的發展，出現我們稱作「前後端分離」的變化，但「分離」出來的「前端專案」本質上有兩種，一種是大家都熟悉的 MERN 技術棧，一種在國外經常稱作「JAMstack」。

MERN 的字面意思，是 MongoDB、Express、React、Node.js 組合成的技術棧，但這四大組成要素其實都分別代表了更根本的東西，除了 MongoDB 代表的傳統 IaaS 和 PaaS，其他三大要素就像圖上標註的，都在專案代碼內。

可以看到這種項目，本質上是讓「分離」出來的「前端專案」，圍繞 Node.js 框架去建設，其實還是讓整個項目回歸成了「伺服器端 Web 框架專案」，前端代碼還是「寄居」在裡面。

這種「前後端分離」並不是真正在技術架構上做了「分離」，而是在「分工」上做「分離」，整個專案是前端開發者自己掌控，但開發方式仍然是以伺服器端為中心的。

基於這種工程方案去做剛才說的「全碼」通用搭建，就會有大量障礙和成本，比如業務邏輯在前後端重複實現、難以所見即所得的在瀏覽器端修改和運行完整的代碼，等等。 這也是「全碼」模式以前沒有發展出來的原因之一。

另一種類型 JAMstack 的三大組成要素同樣不能只看字面意思，就像圖上標註的，專案代碼內只有純粹的前端部分，A 代表的 BFF 等伺服器端業務邏輯，都在專案之外。

這就決定了對於「全碼」通用搭建來說，傳統 JAMstack 工程方案的瓶頸問題，除了抽象程度不夠，更重要的是「不完整」，伺服器端方面的需求，都需要通過在專案之外維護雲函數，或自己用伺服器端框架開發 BFF 服務。 整個應用的業務需求，無法作為一個整體去實現「低碼化 / 無碼化」。

「現代 Web 開發」的發展趨勢，帶來了從「前後端分離」到「前後端一體化」的變化，「前後端分離」時期的兩種前端工程方案，合併成了一種，可以稱作「新一代 JAMstack」，它仍然由三大要素組成，但就像圖中綠色高亮出來的部分，這三個組成要素代表的東西，已經發生了變化。

「以 JS 為中心」意味著更成熟的基於程式設計語言的軟體開發方式，而不是圍繞「內容」的傳統前端開發方式。 「一體化 BFF」意味著工程方案現在是「完整」的，可以讓應用的業務需求作為一個整體來實現。 M 代表的「前端 Serverless」、「一體化 SSR」等，提高了代碼部分的抽象層級，讓代碼更專注於業務需求，減少大量伺服器端實現細節。 這些變化都有利於「全碼」通用搭建的實現。

以一個Modern.js的「應用」專案為例，專案是以 src 對應的用戶端應用代碼為中心來開發的，盡最大可能讓開發者不用感知到伺服器，不止是部署運維環節，也包括開發環節。

比如這個更簡單的Modern.js 「應用」專案。 api 目錄對應的 BFF 實現，看上去幾乎沒有任何伺服器端代碼的痕跡，可以像普通函數一樣設計和實現，像普通函數一樣在應用代碼里調用（有充分的抽象），但這種代碼能實現任意的 REST API，能滿足任意的 BFF 開發需求。 這也是我們前面提到的「一體化 BFF」。

這個專案中這段包含在 useLoader API 中的代碼，體現了前面說的「一體化 SSR」，同一塊業務邏輯，只需要一次代碼實現，會自動在 CSR、SSR、SSG 等不同情況下運行。 並且由於是基於足夠抽象的 API 來實現，會在這些情況下自動優化。 比如這段代碼在獨立 SSR Server 中運行的時候，會自動切換成內網方式來請求 BFF Server 的 API，如果 SSR 和 BFF 運行於同一個 Server 進程，會自動切換成真正的函數調用，沒有網路請求。

3.2.2 新一代「前端三劍客」

「現代 Web 開發」範式的紅利，在「前端三劍客」的演變上也有體現。

「前端三劍客」這個詞起源自 Dreamweaver、Fireworks、Flash，對於現在很多前端開發者來說可能已經很陌生了。 隨著 Web 標準的普及，Open Web 技術中的三個核心要素，HTML、CSS、JS 成為了第 2 代的「前端三劍客」。 而自從 Node.js 的出現為前端技術棧普及編譯構建工具鏈、補充伺服器端開發能力，前端開發就一直是圖上第 3 代「前端三劍客」的模式。

從最早使用字串範本的 jQuery，到後來的雙向綁定、FP 範式的函數位件，都屬於第 3 代「前端三劍客」中的檢視框架，而三劍客中第二個要素「Node.js CLI」代表了工程化相關，第三個要素是伺服器端 Node.js 框架。

而「現代 Web 開發」範式的基礎，已經轉移到了第 4 代「前端三劍客」。 可以看到Modern.js正是起到了第4代中「元框架」的作用，而「全碼」通用搭建，包括我們之前說的星夜，本質上也是在滿足第4代「前端三劍客」中低代碼部分的需求。

可以看到「前端三劍客」的每一代，跟上一代之間恰好都是「包含關係」，每一代中都會有一個要素，把上一代的三大要素包含在自己內部。

背後的原因之一是，隨著需求和技術的發展，上一代的「前端三劍客」會越來越難以應對，複雜性不斷增加，而新一代三劍客會把這些複雜性和細節隱藏、遮罩到自己的一個要素中，而這個要素也因此成為新的基礎底層，支撐三劍客中另外兩個要素，支援各種業務專案的基礎建設。

因此第 4 代「前端三劍客」中的「元框架」，起到了第 3 代中 Webpack、React 的作用。 而第 4 代中的「低代碼」可以在「元框架」的支援下，不再需要跟大量工程細節打交道，更容易實現「全碼」通用搭建。

3.2.3 基於「前端技術」的成熟 GUI 軟體研發體系

在「現代 Web 開發」範式的趨勢下，能形成基於「前端技術」的成熟 GUI 軟體研發體系，這對於「全碼」通用搭建來說，是非常必要的條件。

傳統前端開發中，「DX」和「UX」是不可兼得的。 在這種情況下，如果把「低/無碼化」做的足夠好，提升了 DX，UX 必然受損，導致搭建結果的性能、能力等，跟專業開發的結果有較大差距，或者不夠「通用」，無法滿足專業開發能滿足的所有場景。 反之如果保障了UX，「低/無碼化」的目標就會受損，比如無法給不懂技術的使用者使用，或搭建過程非常複雜繁瑣。

以前面提到過的、極簡的Modern.js「應用」專案為例，只需要配置開啟功能，就能實現：

1. 自動 SSR
2. 根據 UA 自動裁剪 Polyfill
3. 根據 UA 自動差異化分發（Differencial Loading）面向現代瀏覽器的 ES6+ 代碼和面向歷史遺留瀏覽器的 ES5 代碼

在檔很少、代碼量很少、DX 足夠好的情況下，也同時實現了很多傳統專案中自己寫大量代碼也沒有實現的UX。

在Modern.js的支援下，「全碼」通用搭建能針對最少量的、最抽象的專業代碼做「低/無碼化」，而搭建產物自動獲得產品級的能力和性能，不需要自身去解決這些 DX 和UX的問題，當然也更不需要圍繞垂直場景來解決它們。

要實現 DX 和 UX 的同時最大化，從根本上來說，需要「充分的抽象」，需要「框架」模式。

就像圖中左側，傳統前端開發的 DX 和 UX 之所以不可兼得，原因之一是它是基於「庫」、「工具」來開發的。 最外層的大方塊表示整個專案，是藍色的，代表開發者自己要寫的代碼，其中嵌入的綠色方塊，代表被作為「積木」來組裝、在自己的代碼中調用的「庫」和「工具」。

要支援「全碼」通用搭建，需要基於圖中右側體現的「框架」來開發，可以看到整個專案是紅色的，是框架本身，而藍色方塊代表的開發者自己寫的代碼，反而被嵌入在框架的「插槽」中，被框架來調用和組裝，開發者自己寫的代碼成了「積木」。

在專業研發中有了這種程度的抽象，才有可能實現完全基於專業研發體系和真實代碼的「全碼」通用搭建。

「充分的抽象」也意味著要像Modern.js 一樣，盡可能在所有環節做抽象，不止傳統前端開發中常見的運行時環節的抽象（比如DSL渲染就是一種運行時抽象），也要在編譯時、伺服器端運行時、甚至寫代碼的「編寫時」做抽象。

工程方案的收斂和標準化，對「充分的抽象」來說也是必須和必然的，就像以前分享裡指出的海量範本問題，如果任意維度有任意變化，都會產生新的樣板代碼和「範本」，那麼基於真實代碼去實現「通用」搭建，幾乎不可能。

工程方案的收斂和標準化也是Modern.js的主要目標之一，目前已經把工程方案收斂到最少的三個，其中的「應用」工程方案，又稱作「MWA（Modern Web App）」，是「全碼」通用搭建中實現「對複雜度本身做抽象和解耦」的基礎之一。

3.2.4 「MWA」：從 Universal JS 到 Universal App

MWA 實現了 Universal App 模式。

就像圖上梳理的，不論是 SPA 和 MPA 相關的差異，還是實現 CSR、SSR、SSG 之間一體化和混合共存要解決的差異，還是 BFF 業務邏輯跟用戶端業務邏輯之間的差異、Node.js 框架之間的差異，以及常規 web、微前端子應用、基於 Electron 的桌面應用、小程式等之間的差異，都被 MWA 抹平，把這些需求統一成同一個「Universal」的 「應用」工程方案。

用同一個「範本」就能開發任意需求，同一個「應用」專案，也能以靜態 web、SSR、微前端、Electron 等不同方式運行，能同時部署不同形態的版本。

因此「全碼」通用搭建只需要實現「MWA」的低/零碼搭建，就可以實現微前端、桌面應用、小程式等各種應用的搭建能力。

幻燈片上這個例子，展示的是，任意 MWA 都可以隨時成為微前端主應用，並且自動滿足其中的 UX 需求。

3.2.5 應用架構

MWA 提供開箱即用的、以用戶端為中心的應用架構，對「全碼」通用搭建來說，也非常重要。 如果沒有應用架構提供的標準化抽象，要基於真實代碼做低/零碼搭建，就要跟粒度非常細、非常原子的、瑣碎的底層代碼打交道，難以實現好的效果。

MWA 的應用架構讓一個「應用」可以由「Universal App Shell」、視圖元件、業務模型、容器元件組成，可以基於這些最粗粒度的「物料」來實現「全碼」通用搭建。

解耦出來的視圖元件和業務模型，可以有多種適合不同場景的「生產方式」，而「消費方式」是標準化的。

容器元件起到 Controller 作用，能用標準化的方式、很薄的膠水代碼，來連接視圖元件和業務模型。

這些都有助於「全碼」通用搭建直接使用專業研發體系的代碼，不需要做任何建模和設計 DSL，專業代碼本身就可以跟「配置化」的 DSL 一樣易於「低/無碼化」的編輯和使用，而且具備「圖靈完備」的通用能力。

前面提到的「業務模型」（Model），在「全碼」通用搭建中是跟 UI 元件一樣廣泛使用的基礎「物料」，可以封裝用戶端中 UI 無關的業務邏輯，標準化的使用。

3.2.6 「模組」工程方案

「全碼」通用搭建中實現「對複雜度本身做抽象和解耦」的另一個基礎，是「模組」工程方案。

Modern.js 中的「模組」工程方案讓前面提到的視圖元件、容器元件（也可以稱作「業務元件」）、業務模型（Model）可以獨立開發、調試、測試和複用。

Modern.js 也支援「模組」工程方案中的代碼，無縫的使用跟「應用」（MWA）工程方案中一樣的 Runtime API 標準庫。 比如創建和使用 Model 的 API、支援「動靜一體」的 API 等等。 讓「模組」工程中的元件不局限於封裝純 UI 邏輯，不局限於「原子元件」，鼓勵更多「不同粒度」的業務元件的複用和沉澱，也讓「全碼」通用搭建在各種場景下都能提供合適的搭建能力和用法。

「模組」工程方案封裝了產物方面的主流需求和最佳實踐，跟前面說的「Universal App」模式一樣，讓開發者只需要關心業務邏輯的複用和沉澱，讓同一份代碼自動適用於各種場景，自動具備各種運行模式（比如 Modern.js 即將提供的類似微前端的「微模組」用法），自動能用於低/無碼搭建。

3.3 「全碼」：與專業研發體系無縫結合的「低/無碼」

前面介紹了為實現「全碼」通用搭建創造條件的「現代Web開發」範式和Modern.js工程體系。 星夜作為「全碼」通用搭建解決方案，跟前面說的工程體系是無縫結合的，

星夜不需要像傳統「前端可視化搭建」一樣，通過DSL 「協定」來做領域建模，因為Modern.js 本身就是對Web開發的最大化的抽象和標準化，這套工程體系和其中的「Pro Code」，本身就已經是一個「協定」。

星夜也不需要另起爐灶搞一套平台鎖定的專用 Pro Code 方案，而是跟專業開發者的日常研發完全保持一致。 這也讓星夜不需要跟特定的 Design System 和元件體系捆綁在一起，可以支援任意 Design System 和任意元件。 因此物料的沉澱積累和生態建設也是共通的，避免前面說過的ROI問題。

就像幻燈片上畫的，這種「全碼」模式，不僅解決「輸入」側（比如物料）的問題、帶來新能力，也在「輸出」側帶來新能力。 由於星夜的輸出就是前面說的「MWA」，跟專業開發者手寫的 MWA 一致，所以除了前面講過的「Universal App」能力，還帶來了新的低/零碼提效路徑：一個業務專案不用在專業開發和低碼搭建之間二選一，不用修改技術棧和舊代碼，可以按需漸進的引入低碼提效。 比如對一些新需求（比如局部頁面、局部區域）嘗試用星夜來搭建，讓開發者逐步從這些需求中解放出去，也逐步積累物料和新工作流的經驗，為進一步的低碼提效和解放開發資源做準備。

3.4 Code In, Code Out

星夜作為「全碼」通用搭建，是「專業代碼進，專業代碼出」的。 不像傳統「前端可視化搭建」一樣圍繞 DSL 設計，而是從一開始就完全圍繞真實專業的代碼來實現。

在編輯和運行環節，不需要 DSL 運行時、渲染器等，星夜編輯器本質上就是 Web IDE（包括瀏覽器端沙盒的 Web IDE 和伺服器端沙盒的 Web IDE），編輯過程跟 Web IDE 一樣載入代碼、運行代碼、修改代碼、生成代碼。

編輯器的內部實現中，像 IDE 的實現一樣用到各種數據結構和存儲，對於「全碼」通用搭建，要注意這些內部實現是不應該讓專業代碼被整體「配置化」的，不能降級成一種領域模型，成為變相的 DSL（這種內部 DSL 也很容易「洩露」出去變成 API）。

星夜編輯器載入和運行的，是全量、完整的項目代碼，而「修改」的物件和方式有兩類。 一類雖然也是項目代碼的一部分，但本質是模式化、標準化的膠水代碼，專業開發者需要從這種代碼的開發工作中解脫出去，這種代碼的實現過程是適合「低/無碼化」的。 還有一類屬於「不可避免的複雜性」，應該讓專業開發者可以完全掌控，用專業研發體系的完整能力，在 Web IDE 或本地開發環境裡手工實現和維護。

3.5 搭建任意應用

「全碼」通用搭建帶來的最重要的新能力，就是真正能做到「通用」，可以用於實現「任意應用」。

以星夜為例，首先星夜不止是「前端搭建」，既支援「介面驅動」，也支援「模型驅動」（比如 CMS 建模、流程編排、引導搭建等），由於 MWA 是前後端一體化的全棧工程方案，星夜生成的應用代碼裡同時包含後端和前端業務邏輯，可以獨立部署和運維。

另一方面，星夜編輯器就像 Web IDE 一樣，只是提供了一個「舞臺」，只提供「機制」而不提供「策略」，也就是說編輯器本身具備各種能力，但不決定具體的搭建用法，而是由「物料」（比如 UI 元件）來決定用法。 編輯器會根據「物料」的代碼、介面描述等訊息，自動生成不同的UI和互動。

因此任何前端開發者都可以通過開發和維護不同的「物料」體系（比如不同的業務元件庫），在星夜上提供針對不同使用者類型、不同垂直場景、不同複雜程度的搭建能力、用法、工作流。

由於「全碼」通用搭建跟專業研發體系無縫結合，所以專業研發體系能做什麼，星夜就能做什麼。 前端開發者也可以隨時直接「介入」星夜中的應用，直接自定義代碼滿足任意非模式化的、一次性的需求。

列舉幾個在位元組內部支援不同場景的例子。

第一個例子是網站場景，火山引擎官網讓產品經理和供應商使用星夜自助搭建和維護自己的產品頁面，發佈時自動作為微前端子應用，嵌入到前端團隊維護的 MWA 工程裡，自動用 SSR 方式運行。 在星夜中和 MWA 工程中使用相同的官網業務元件庫，元件在星夜中的用法，面向不寫代碼的產品人員設計。

第二個例子是活動場景，運營用星夜編輯器搭建今日頭條和西瓜視頻端內端外的活動和 Hybrid 介面。 使用的元件庫、元件的用法都完全不一樣，元件中包含跟 CMS（運營平臺）相關的業務邏輯。 可以看到編輯器本身也有面向這個垂直場景的自定義。

第三個例子是中後台場景，由後端開發者搭建，涉及更靈活的邏輯編排、大型的 CRUD 業務元件，連接自己實現的伺服器端 API 等。

第四個例子是數據大屏場景。 這些例子中的用法，都是營業單位的前端開發者自己提供的，針對自己工作中的垂直場景做提效，形成解放開發者的新工作流。 而星夜這種「全碼」通用搭建解決方案，除了普及這種提效能力和工作方式，也追求把這種工作的成本降到跟開發者原本在專業開發工作中做沉澱積累的成本一樣（或更低，比如通過物料生態建設的支援）。

3.6 「低碼中臺」

最後講一下「全碼」通用搭建能實現的「低碼中台」模式。

前面講「應用開發領域的關卡編輯器現象」時有提到過，很多業務場景下開發自己專用的低碼搭建平臺或在自己的平臺里提供搭建功能，是很正常、不可避免的需求。 有很多讓這些專案基於一套通用「協定」的嘗試，目前為止還沒有真正意義上成功的例子。 「全碼」通用搭建由於不受領域建模的限制，基於標準化的專業工程體系，工程體系本身就是「協定」，所以從一開始就能實現「低碼中台」能力。

所以星夜的設計、實現和實踐驗證過程，本身也是在做「全碼」通用搭建這種模式的中台化工作和生態建設工作，降低採納這種模式的成本。

總結

這次分享介紹了現代 Web 研發體系中的「低碼 Web 開發管線」和「低碼搭建」部分，在研發體系的支撐下，「低碼搭建」的新模式和新能力，可以稱作「全碼」通用搭建。

而圖上左邊藍色部分，已經作為Modern.js專案開源出來，既希望能加快「現代Web開發」中「元框架」和工程體系的發展，也希望通過支援「全碼」通用搭建，一方面為專業開發者「賦能」突破提效天花板，一方面推動越來越多有軟體需求的全民開發者（Citizen Developer）們獲得 「賦權」，在這個「軟體統治世界」的時代， 讓更多人能掌控和解決自己的需求。

Modern.js 目前剛起步，還有很多地方要做到位，期待更多人參與建設和實踐。