前言

終于有時(shí)間把稀土開(kāi)發(fā)者大會(huì)上講的「Web 開(kāi)發(fā)引擎」和「低碼」話題的分享，改成文字版發(fā)出來(lái)。

現(xiàn)場(chǎng)演講中后半部分內(nèi)容是脫稿講的，我重寫成了更全的內(nèi)容。

「越來(lái)越龐大的應(yīng)用開(kāi)發(fā)需求」和「現(xiàn)代 Web 開(kāi)發(fā)范式的紅利」這兩個(gè)部分的幻燈片，雖然在其他分享里用過(guò)，但在這個(gè)話題里，用途是不同的，文字內(nèi)容是不同角度的，建議不要略過(guò)。

分享實(shí)錄

大家好，我是來(lái)自字節(jié)跳動(dòng) Web Infra 的楊揚(yáng)。在字節(jié)跳動(dòng)，我們部門負(fù)責(zé)打造和發(fā)展「Web 技術(shù)中臺(tái)」和「前端研發(fā)體系」。

上午的主題演講中，字節(jié)跳動(dòng)正式發(fā)布了 Modern.js 開(kāi)源項(xiàng)目，這個(gè)項(xiàng)目的目的是推動(dòng)現(xiàn)代 Web 開(kāi)發(fā)范式的普及，發(fā)展完整的現(xiàn)代 Web 工程體系，突破應(yīng)用開(kāi)發(fā)效率的瓶頸?，F(xiàn)在這個(gè)專場(chǎng)雖然是關(guān)于低代碼的，但我要分享的內(nèi)容，也是完全依靠這套現(xiàn)代 Web 工程體系，才能夠?qū)崿F(xiàn)。

上午有講到 Modern.js 是字節(jié)內(nèi)部整套現(xiàn)代 Web 研發(fā)體系的三大組成部分之一，我這次側(cè)重講的，是其中的另一個(gè)組成部分：「低代碼開(kāi)發(fā)管線」。

議程

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

一、突破研發(fā)提效天花板

1.1 「越來(lái)越龐大的應(yīng)用開(kāi)發(fā)需求」= ？

最根本的需求就是應(yīng)用開(kāi)發(fā)在數(shù)量、范圍、效率上的需求，大家都知道從 PC 互聯(lián)網(wǎng)到移動(dòng)互聯(lián)網(wǎng)，軟件應(yīng)用被用于更多日常生活場(chǎng)景和更多企業(yè)場(chǎng)景，導(dǎo)致應(yīng)用數(shù)量大幅增加，這種趨勢(shì)到現(xiàn)在不但沒(méi)減弱，反而還在加強(qiáng)，比如幻燈片上 IDC 的預(yù)測(cè)，這么龐大的應(yīng)用開(kāi)發(fā)需求，是很難靠傳統(tǒng)的軟件開(kāi)發(fā)方式和人才儲(chǔ)備來(lái)滿足的。

最常說(shuō)的解決途徑就是靠低代碼、零代碼工具，就像幻燈片里右側(cè)這張圖，當(dāng)前市場(chǎng)上存在非常多的這種產(chǎn)品，國(guó)內(nèi)大廠在內(nèi)部建設(shè)的這類項(xiàng)目也非常多。

但這些項(xiàng)目普遍更適合垂直、局部的場(chǎng)景，只支持相對(duì)有限的能力。大幅增加的應(yīng)用開(kāi)發(fā)需求帶來(lái)更高的多樣性、更廣的場(chǎng)景和更高的質(zhì)量要求，其中很多都仍然需要專業(yè)開(kāi)發(fā)者的參與，而當(dāng)前這些低碼零碼項(xiàng)目又普遍的難以跟專業(yè)研發(fā)協(xié)同工作，所以才會(huì)有我們今天的話題——如何跟研發(fā)體系結(jié)合，突破傳統(tǒng)低碼技術(shù)的瓶頸。

剛才說(shuō)的這些場(chǎng)景下的應(yīng)用開(kāi)發(fā)需求，在初始狀態(tài)下，會(huì)完全等同于對(duì)專業(yè)開(kāi)發(fā)者的需求。我們不應(yīng)該跳躍思維的直接鉆到低碼解決方案的牛角尖里，而是應(yīng)該先站回起點(diǎn)，看看在專業(yè)開(kāi)發(fā)方面能提效到什么程度，能滿足多少需求，有什么瓶頸，因?yàn)榈痛a方案的競(jìng)爭(zhēng)對(duì)手不是只有其他低碼方案，而是首先要跟成熟完善的專業(yè)研發(fā)體系「競(jìng)爭(zhēng)」。

既然這些場(chǎng)景下的應(yīng)用開(kāi)發(fā)需求，最初完全等同于對(duì)專業(yè)開(kāi)發(fā)者的需求，那么顯而易見(jiàn)的提效方法，就是讓盡可能多的開(kāi)發(fā)者能獨(dú)立、完整的開(kāi)發(fā)這些應(yīng)用，而前端技術(shù)棧的開(kāi)發(fā)者，正是最大的開(kāi)發(fā)者群體和技術(shù)社區(qū)。

所以在用戶、產(chǎn)品、市場(chǎng)這一側(cè)，一直有趨勢(shì)和壓力，需要更多「前端開(kāi)發(fā)者」成為「應(yīng)用開(kāi)發(fā)者」或「產(chǎn)品開(kāi)發(fā)者」，鼓勵(lì)和倒逼著技術(shù)領(lǐng)域，不斷產(chǎn)生更有利于這種需求的技術(shù)形態(tài)和基礎(chǔ)設(shè)施。

不是技術(shù)領(lǐng)域，而是商業(yè)領(lǐng)域，需要更多「前端開(kāi)發(fā)者」成為「應(yīng)用開(kāi)發(fā)者」或「產(chǎn)品開(kāi)發(fā)者」，背后的原因除了剛才說(shuō)的，還有一個(gè)，就是隨著移動(dòng)互聯(lián)網(wǎng)又重走了 PC 互聯(lián)網(wǎng)時(shí)代門戶網(wǎng)站、瀏覽器的老路，除了少數(shù)作為領(lǐng)域入口的超級(jí) App，像實(shí)體、內(nèi)容、服務(wù)這樣海量、高頻的需求，都更傾向用 Web 技術(shù)來(lái)實(shí)現(xiàn)，需要前端技術(shù)背景的開(kāi)發(fā)者。

研發(fā)產(chǎn)品最初是從最接近機(jī)器的底層開(kāi)始發(fā)展，從虛擬化，到容器編排，到基于容器技術(shù)的各種平臺(tái)化、服務(wù)化的研發(fā)工具形態(tài)（就像圖上綠色部分），這個(gè)階段是后端技術(shù)主導(dǎo)的，但整個(gè)趨勢(shì)是越來(lái)越向上層發(fā)展，越來(lái)越接近市場(chǎng)和商業(yè)價(jià)值最終所在的地方——也就是面向用戶的產(chǎn)品，因此必然會(huì)發(fā)展到前端技術(shù)主導(dǎo)的抽象層，讓應(yīng)用開(kāi)發(fā)和產(chǎn)品開(kāi)發(fā)能更專注于用戶需求，而越來(lái)越不需要關(guān)心服務(wù)器端的復(fù)雜性和專業(yè)技術(shù)細(xì)節(jié)。

所以市場(chǎng)需求會(huì)趨向于推動(dòng)應(yīng)用開(kāi)發(fā)方式往「專注于前端」的方向的發(fā)展，「專注于前端」就等同于「專注于用戶」，而「專注于用戶」是多數(shù)企業(yè)、產(chǎn)品的根本利益所在。

在這種客觀趨勢(shì)的推動(dòng)下，基于 Web 技術(shù)的應(yīng)用開(kāi)發(fā)中，服務(wù)器端的占比和門檻一直在不斷下降。

國(guó)內(nèi)大廠的中臺(tái)建設(shè)，提供了大量不跟特定客戶端捆綁、專注于數(shù)據(jù)需求和底層業(yè)務(wù)邏輯的 API，讓產(chǎn)品開(kāi)發(fā)更聚焦在上層的客戶端業(yè)務(wù)邏輯。

海外流行的 Headless CMS 本質(zhì)上也是一種中臺(tái)，也起到同樣的作用。

還有 BaaS 和基于云函數(shù)的后端云 Serverless，進(jìn)一步降低服務(wù)器端的門檻，讓前端開(kāi)發(fā)者能更獨(dú)立的、端到端的完成產(chǎn)品開(kāi)發(fā)。

但要進(jìn)一步降低門檻，提高效率，以上模式的一個(gè)缺陷就暴露出來(lái)，就是他們都把應(yīng)用依賴的 API，放在應(yīng)用項(xiàng)目之外維護(hù)，跟前端研發(fā)是割裂的，這樣帶來(lái)的問(wèn)題和效率瓶頸很多。還有一個(gè)缺陷就是不解決 API 之外的服務(wù)器端需求，比如 SSR 等「Web」需求。

要克服這些缺陷，必然需要新的模式，比如明天上午專場(chǎng)會(huì)介紹的 Modern.js 中，前端工程方案覆蓋了完整全棧開(kāi)發(fā)的各個(gè)環(huán)節(jié)，但同時(shí)又通過(guò)一體化、盡量無(wú)服務(wù)器化的方式，實(shí)現(xiàn)「客戶端為中心」的現(xiàn)代 Web 開(kāi)發(fā)范式。

這些開(kāi)發(fā)范式、開(kāi)發(fā)工具方面的發(fā)展，都創(chuàng)造了條件，讓更多「前端開(kāi)發(fā)者」成為「應(yīng)用開(kāi)發(fā)者」或「產(chǎn)品開(kāi)發(fā)者」，工作中也更關(guān)注工程，而不像傳統(tǒng)前端開(kāi)發(fā)者更關(guān)注視覺(jué)和交互。

1.2 研發(fā)提效的天花板

但無(wú)論怎樣改進(jìn)現(xiàn)代 Web 開(kāi)發(fā)體系，改進(jìn)基礎(chǔ)設(shè)施，都面臨提效的天花板。因?yàn)檠邪l(fā)效率提升到一定程度之后，就會(huì)發(fā)現(xiàn)效率瓶頸主要在工作內(nèi)容本身上面。只要一個(gè)前端每周有大半時(shí)間要做基礎(chǔ)但又繁瑣的 CRUD 中后臺(tái)、臨時(shí)的活動(dòng)頁(yè)面等事情，被這些緊急但不重要的事情占據(jù)，或頻繁打斷，再怎樣在研發(fā)內(nèi)部做提效，也改善不了多少。

1.3 「接力」范式

要突破這塊研發(fā)提效的天花板，就要不局限于研發(fā)內(nèi)部，而要關(guān)注軟件開(kāi)發(fā)的整個(gè)工作流程。然后我們會(huì)發(fā)現(xiàn)，跟其他創(chuàng)造事物的工作，比如平面出版、攝影、游戲、建筑等，跟這些相比，軟件研發(fā)的工作流是一個(gè)另類。

在這些工作中，掌握領(lǐng)域知識(shí)的業(yè)務(wù)專家，都對(duì)真實(shí)產(chǎn)物是有了解的，也能直接掌控，比如平面設(shè)計(jì)師懂印刷、攝影師懂鏡頭和膠片、建筑師懂材料和施工，大家都通過(guò)工具直接真實(shí)產(chǎn)物打交道。

而軟件研發(fā)中，開(kāi)發(fā)者只在少數(shù)領(lǐng)域，比如開(kāi)發(fā)工具等，是業(yè)務(wù)專家，在多數(shù)像電商、O2O 等領(lǐng)域里無(wú)論如何都是支持型的角色，但軟件研發(fā)的工作流卻是一種獨(dú)特的「接力」范式，只有開(kāi)發(fā)者才能直接跟真實(shí)產(chǎn)品打交道，能真正掌控產(chǎn)品，其他業(yè)務(wù)專家用再好的工具，產(chǎn)出物都是假東西，比如線框圖、交互原型、高保真設(shè)計(jì)稿，都是對(duì)真實(shí)產(chǎn)品的一種效仿。工作流中每個(gè)環(huán)節(jié)都有幻燈片上列出的這些痛點(diǎn)，研發(fā)提效的天花板，也來(lái)自這里。

1.4 「圓桌」范式

游戲研發(fā)是垂直領(lǐng)域的軟件研發(fā)，由于創(chuàng)新多、工作量大參與者多等特點(diǎn)，游戲開(kāi)發(fā)更不可能忍受剛才說(shuō)的「接力」范式工作流，很值得我們學(xué)習(xí)。

游戲研發(fā)的工作流可以稱作「圓桌」范式，真實(shí)的代碼就是中間的圓桌，所有分工都圍著這張桌子，用各種適合自己的工具，直接跟代碼交道，產(chǎn)出的都是最終游戲中真實(shí)的組成部分，不需要做假東西去跟程序員溝通，等程序員把這些東西用代碼從頭實(shí)現(xiàn)出來(lái)。游戲程序員也可以專注于更有價(jià)值的事情，實(shí)現(xiàn)新效果、新玩法、開(kāi)發(fā)提效工具等等。游戲程序員跟代碼交道使用的工具，跟策劃和美術(shù)使用的工具雖然差別很大，但都來(lái)自同一個(gè)游戲引擎套件，套件中的不同工具都基于同樣的框架、架構(gòu)、標(biāo)準(zhǔn)。

在字節(jié)跳動(dòng)，Web Infra 有一個(gè)「Web 開(kāi)發(fā)引擎」子部門，就是致力于在軟件研發(fā)領(lǐng)域?qū)崿F(xiàn)這種以代碼為中心的「圓桌」范式。

為了讓所有分工都盡可能直接跟真實(shí)代碼打交道，在同一套「研發(fā)管線」里工作，需要專業(yè)研發(fā)環(huán)節(jié)有高度抽象的、標(biāo)準(zhǔn)化的工程和工具體系，這也是我們打造和發(fā)展「現(xiàn)代 Web 工程體系」 Modern.js 的原因之一。

另一方面可以看到，這次分享最初提出的「越來(lái)越龐大的應(yīng)用開(kāi)發(fā)需求」問(wèn)題，到這里我們已經(jīng)明確研發(fā)提效能到什么程度，有什么瓶頸，低碼解決方案能帶來(lái)什么幫助，而且更重要的是，這樣引入的低碼解決方案，是跟專業(yè)研發(fā)體系無(wú)縫結(jié)合的。

二、低/零碼宇宙之熵

接下來(lái)我們看看，為什么需要新一代的低碼解決方案，才能滿足前面的需求，現(xiàn)有的各種低碼、零碼解決方案有什么瓶頸。

2.1 RAD

我們逐個(gè)看下不同形態(tài)的方案，第一個(gè)是歷史悠久的 RAD 工具。

這種工具有點(diǎn)兩極化，一部分開(kāi)發(fā)者把這種工具稱作「神器」，有很高的評(píng)價(jià)，一部分開(kāi)發(fā)者完全不熟悉它們，覺(jué)得跟自己沒(méi)關(guān)系，這背后的重要原因是，RAD 工具是要跟特定技術(shù)棧、框架緊密結(jié)合，才能實(shí)現(xiàn)在研發(fā)環(huán)節(jié)中引入低碼提效的，所以對(duì)不是這個(gè)技術(shù)棧的開(kāi)發(fā)者沒(méi)有意義。

這也體現(xiàn)了 RAD 的瓶頸，就是只能面向開(kāi)發(fā)者，無(wú)法服務(wù)更多不懂技術(shù)的用戶，滿足越來(lái)越多的應(yīng)用開(kāi)發(fā)需求。

2.2 CMS

第二個(gè)形態(tài)是同樣歷史悠久的 CMS。

如今 CMS 不但沒(méi)過(guò)時(shí)，反而被發(fā)揚(yáng)光大，國(guó)內(nèi)大廠的很多中后臺(tái)，本質(zhì)都是 CMS，疫情期間發(fā)展很好的美國(guó)電商平臺(tái) Shopify，也是 CMS。

這種模式的瓶頸問(wèn)題有兩個(gè)，一個(gè)是更適合配置「內(nèi)容」，難以解決更多應(yīng)用開(kāi)發(fā)需求，另一個(gè)問(wèn)題是 CMS 是需要基于模板的，配置的是模板中的可變部分，也跟具體的客戶端和服務(wù)器端的實(shí)現(xiàn)捆綁在一起，讓它不可能靈活滿足各種需求。

2.3 Website/H5 Builder

第三種形態(tài)是近十年來(lái)興起的，由于國(guó)內(nèi)外的差別，在國(guó)外流行的是網(wǎng)站搭建，在國(guó)內(nèi)流行的是活動(dòng)搭建。

他們本質(zhì)上都相當(dāng)于 RAD 中偏設(shè)計(jì)的部分，跟 CMS 的結(jié)合體。這種模式突破了 RAD 的瓶頸，讓非技術(shù)用戶能夠使用。

但仍然跟 CMS 一樣，需要基于模板，基于平臺(tái)第一方提供的組件庫(kù)，以及服務(wù)器端。這樣一方面跟專業(yè)研發(fā)是割裂的，研發(fā)很難提供優(yōu)化、定制方面的支持，另一方面也是平臺(tái)鎖定的。

2.4 Headless CMS

第四種形態(tài)，是同樣從 CMS 發(fā)展而來(lái)的 Headless CMS。

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

瓶頸是，只解決了應(yīng)用開(kāi)發(fā)的一半，沒(méi)有客戶端，本質(zhì)上更類似 BaaS 服務(wù)。

2.5 aPaaS

第五種形態(tài)是近年來(lái)大名鼎鼎的 aPaaS。

它是從 SaaS 發(fā)展出來(lái)的，傾向作為特定 SaaS 的配套，滿足企業(yè)定制需求，相當(dāng)于替代了盒裝軟件時(shí)代，像 SAP 這樣的企業(yè)軟件需要專門到企業(yè)現(xiàn)場(chǎng)去做的定制開(kāi)發(fā)和實(shí)施。

aPaaS 要實(shí)現(xiàn)對(duì)特定 SaaS 做定制，本質(zhì)上靠的是后端配置化：把 SaaS 后端業(yè)務(wù)邏輯的局部做成可配置，幻燈片上的建模和編排是最常見(jiàn)的。所以在 aPaaS 里創(chuàng)建出來(lái)的定制版 SaaS，跟原版 SaaS 其實(shí)還是同一個(gè)應(yīng)用，后端實(shí)現(xiàn)、數(shù)據(jù)庫(kù)都在一起。

這些也構(gòu)成了 aPaaS 的瓶頸：通用性不強(qiáng)，跟特定 SaaS 或垂直場(chǎng)景捆綁在一起，適合企業(yè)軟件領(lǐng)域。

2.6 BPM

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

BPM 不再跟特定 SaaS 捆綁，而是作為連接器串聯(lián)大量的 SaaS 和服務(wù)。適合企業(yè)流程定制。

瓶頸是只能滿足這種模式的應(yīng)用開(kāi)發(fā)需求。

2.7 No Code

第七種是 SaaS 的另一種發(fā)展。

像 Airtable 這樣的 No Code SaaS，不是在 SaaS 的外部做配置，而是直接在 SaaS 自身的使用中做配置，滿足各種需求，把消費(fèi)和搭建混合在一個(gè)界面里。Excel 其實(shí)也是這種模式的應(yīng)用。

這種模式的瓶頸是，在數(shù)據(jù)能力和界面能力上，都是相對(duì)模板化的，不能實(shí)現(xiàn)任意應(yīng)用。

2.8 Design Tools

第八種形態(tài)是新一代設(shè)計(jì)工具，比如 Webflow、Framer 等。

不需要設(shè)計(jì)稿轉(zhuǎn)代碼環(huán)節(jié)，設(shè)計(jì)過(guò)程本身就在編輯代碼產(chǎn)出代碼。

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

2.9 前端可視化搭建

第九種形態(tài)不是產(chǎn)品形態(tài)，而是國(guó)內(nèi)技術(shù)領(lǐng)域常見(jiàn)的概念，「前端可視化搭建」跟「組件庫(kù)」、「腳手架」，可以并稱為國(guó)內(nèi)前端技術(shù)團(tuán)隊(duì)最常建設(shè)的三件套。

就像 aPaaS 是跟特定 SaaS 緊密結(jié)合、在這個(gè)領(lǐng)域做建模、把 SaaS 的后端業(yè)務(wù)邏輯做「配置化」，前端可視化搭建也是對(duì)垂直領(lǐng)域的前端需求做建模，把前端開(kāi)發(fā)工作「配置化」。

包含「前端可視化搭建」在內(nèi)的「?jìng)鹘y(tǒng)前端技術(shù)?！?，可以表示成幻燈片上這樣（之前的分享中介紹過(guò)），從下往上表示抽象層不斷提高，藍(lán)色部分都是前端代碼、工程化相關(guān)的要素，可以看到「前端可視化搭建」這個(gè)紅色的方塊，跟藍(lán)色部分一樣，是從下到上「端到端」的。

這里想表達(dá)的意思是，「可視化搭建」的一大瓶頸問(wèn)題，就是跟專業(yè)的前端研發(fā)方式彼此割裂。

前面說(shuō)過(guò)「前端可視化搭建」的本質(zhì)，是把部分前端開(kāi)發(fā)工作轉(zhuǎn)變成「做配置」，所以物料生態(tài)、物料開(kāi)發(fā)方式、產(chǎn)物的預(yù)覽方式、運(yùn)行方式、發(fā)布方式等，都是圍繞這種「配置」方式，重新建設(shè)一套，跟專業(yè)前端的開(kāi)發(fā)方式和基礎(chǔ)設(shè)施，是彼此割裂的。

很多前端可視化搭建項(xiàng)目，也會(huì)設(shè)計(jì)和開(kāi)放出來(lái)一套「Pro Code」方案，滿足用戶在搭建中的自定義需求，但這種「Pro Code」跟專業(yè)前端真正的 Pro Code 仍然是割裂的。

核心原因跟前面說(shuō)的一樣，為了把前端從「做開(kāi)發(fā)」變成「做配置」，總是需要先針對(duì)垂直領(lǐng)域做建模，形成一套配置文件，或配置風(fēng)格的代碼，這里統(tǒng)稱為「DSL」，用這套 DSL 替代正常的代碼實(shí)現(xiàn)，實(shí)現(xiàn)能運(yùn)行這套 DSL 的渲染器，再基于 DSL 實(shí)現(xiàn)可視化編輯器。

這種可視化搭建的實(shí)現(xiàn)方式，設(shè)計(jì)和實(shí)現(xiàn)都相對(duì)簡(jiǎn)單，門檻低，而付出的代價(jià)之一，就是必然跟專業(yè)前端的日常研發(fā)體系割裂。

圍繞這種 DSL 的可視化搭建，在物料環(huán)節(jié)，必然存在平臺(tái)鎖定的問(wèn)題。用于可視化搭建的組件，跟專業(yè)前端日常開(kāi)發(fā)中沉淀的組件，彼此不互通，降低了組件建設(shè)的 ROI。為了在編輯器里對(duì)組件做配置，需要為每個(gè)組件都去額外開(kāi)發(fā)維護(hù)一套配置界面，不管是模板項(xiàng)目的形式、JSON form schema 還是其他形式，都提高了組件的維護(hù)成本。以上這些反過(guò)來(lái)也影響了沉淀和維護(hù)改進(jìn)業(yè)務(wù)組件的積極性，導(dǎo)致無(wú)論專業(yè)代碼開(kāi)發(fā)還是可視化搭建，物料積累都比較少。

另一方面在渲染、部署環(huán)節(jié)，不但要專門維護(hù)渲染器和平臺(tái)設(shè)施，也導(dǎo)致業(yè)務(wù)的前端開(kāi)發(fā)同學(xué)難以支持和掌控。

物料積累少，建設(shè)難，對(duì)性能穩(wěn)定和功能難以支持，都局限了可視化搭建的使用范圍和效果。

「前端可視化搭建」跟 aPaaS 一樣，都面臨兩難選擇，無(wú)論選擇專注特定業(yè)務(wù)和領(lǐng)域，還是追求通用，都會(huì)有不同的瓶頸問(wèn)題，最終結(jié)果都是 ROI 不高。

2.10 應(yīng)用開(kāi)發(fā)領(lǐng)域的「關(guān)卡編輯器」現(xiàn)象

前面我們已經(jīng)盤點(diǎn)了九種低碼、零碼項(xiàng)目的形態(tài)，最后這種不是特定的項(xiàng)目，而是一種普遍現(xiàn)象。

在游戲開(kāi)發(fā)中，關(guān)卡編輯器是創(chuàng)作大部分游戲內(nèi)容的工具，游戲引擎通常自帶關(guān)卡編輯功能，但很多游戲都會(huì)針對(duì)自己的獨(dú)特玩法開(kāi)發(fā)專用的關(guān)卡編輯器，一方面滿足獨(dú)有需求，一方面讓編輯器更垂直化，提高效率。

低碼搭建領(lǐng)域也有同樣的現(xiàn)象，很多業(yè)務(wù)場(chǎng)景都會(huì)開(kāi)發(fā)自己專用的低碼搭建。

瓶頸問(wèn)題一方面當(dāng)然是海量（特別是在國(guó)內(nèi)）的重復(fù)建設(shè)和彼此割裂，另一方面，在國(guó)內(nèi)（特別是大廠）有很多讓這些項(xiàng)目基于一套通用「協(xié)議」的嘗試，目前為止還沒(méi)有真正意義上成功的例子，背后的根本原因，也跟前面說(shuō)的「DSL」模式有關(guān)，在這種模式里，「DSL」是天然傾向跟垂直領(lǐng)域緊密結(jié)合的，難以通用化。

三、奇點(diǎn)：「全碼」通用搭建

盤點(diǎn)了現(xiàn)有的各種低碼、零碼解決方案的瓶頸。最后來(lái)看下現(xiàn)代 Web 研發(fā)體系里的「全碼」通用搭建，是怎樣的解決方案。

在字節(jié)內(nèi)部我們把這套解決方案稱作「星夜」。星夜是作為「Web 開(kāi)發(fā)引擎」的一部分，在字節(jié)內(nèi)部驗(yàn)證、發(fā)展出來(lái)的，適用于任意應(yīng)用的搭建，它從最初就被設(shè)計(jì)為完全基于全功能的專業(yè)代碼，跟包括 Modern.js 在內(nèi)的現(xiàn)代 Web 研發(fā)體系能夠無(wú)縫結(jié)合。

星夜針對(duì)的使用者，既有專業(yè)的現(xiàn)代 Web 開(kāi)發(fā)者，也有懂技術(shù)但不擅長(zhǎng)前端開(kāi)發(fā)、現(xiàn)代 Web 開(kāi)發(fā)的人，以及不懂技術(shù)的需求方（比如運(yùn)營(yíng)、銷售等角色）。

3.1 上帝的歸上帝，凱撒的歸凱撒：解耦「復(fù)雜度」

星夜做的事情，首先本質(zhì)上是在解決軟件開(kāi)發(fā)的復(fù)雜度問(wèn)題，對(duì)復(fù)雜度本身做抽象和解耦，把不可避免的復(fù)雜度留給專業(yè)開(kāi)發(fā)體系，讓低碼平臺(tái)能專注于「業(yè)務(wù)邏輯的最后一公里」，只負(fù)責(zé)不需要專業(yè)開(kāi)發(fā)者介入的膠水代碼。

3.2 「現(xiàn)代 Web 開(kāi)發(fā)」范式的紅利

另一方面，星夜也把自己完全建立在現(xiàn)代 Web 研發(fā)體系之上，把問(wèn)題盡可能都交給專業(yè)研發(fā)體系去解決、抽象，自己只在上層做低碼領(lǐng)域的額外建設(shè)。研發(fā)體系的提效做的越好，星夜就越不需要在上層去用非專業(yè)的方法重復(fù)解決問(wèn)題。

實(shí)際上這種「全碼」通用搭建，也是因?yàn)橛鞋F(xiàn)代 Web 開(kāi)發(fā)范式的紅利，才能夠?qū)崿F(xiàn)的，明天上午的專場(chǎng)會(huì)專門介紹 Modern.js，我們這里快速看一下這套現(xiàn)代 Web 工程體系是怎樣為「全碼」通用搭建帶來(lái)可能。

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

在 Web 研發(fā)中，最初前端代碼「寄居」在「服務(wù)器端 Web 框架項(xiàng)目」的里面，隨著之后的發(fā)展，出現(xiàn)我們稱作「前后端分離」的變化，但「分離」出來(lái)的「前端項(xiàng)目」本質(zhì)上有兩種，一種是大家都熟悉的 MERN 技術(shù)棧，一種在國(guó)外經(jīng)常稱作「JAMstack」。

MERN 的字面意思，是 MongoDB、Express、React、Node.js 組合成的技術(shù)棧，但這四大組成要素其實(shí)都分別代表了更根本的東西，除了 MongoDB 代表的傳統(tǒng) IaaS 和 PaaS，其他三大要素就像圖上標(biāo)注的，都在項(xiàng)目代碼內(nèi)。

可以看到這種項(xiàng)目，本質(zhì)上是讓「分離」出來(lái)的「前端項(xiàng)目」，圍繞 Node.js 框架去建設(shè)，其實(shí)還是讓整個(gè)項(xiàng)目回歸成了「服務(wù)器端 Web 框架項(xiàng)目」，前端代碼還是「寄居」在里面。

這種「前后端分離」并不是真正在技術(shù)架構(gòu)上做了「分離」，而是在「分工」上做「分離」，整個(gè)項(xiàng)目是前端開(kāi)發(fā)者自己掌控，但開(kāi)發(fā)方式仍然是以服務(wù)器端為中心的。

基于這種工程方案去做剛才說(shuō)的「全碼」通用搭建，就會(huì)有大量障礙和成本，比如業(yè)務(wù)邏輯在前后端重復(fù)實(shí)現(xiàn)、難以所見(jiàn)即所得的在瀏覽器端修改和運(yùn)行完整的代碼，等等。這也是「全碼」模式以前沒(méi)有發(fā)展出來(lái)的原因之一。

另一種類型 JAMstack 的三大組成要素同樣不能只看字面意思，就像圖上標(biāo)注的，項(xiàng)目代碼內(nèi)只有純粹的前端部分，A 代表的 BFF 等服務(wù)器端業(yè)務(wù)邏輯，都在項(xiàng)目之外。

這就決定了對(duì)于「全碼」通用搭建來(lái)說(shuō)，傳統(tǒng) JAMstack 工程方案的瓶頸問(wèn)題，除了抽象程度不夠，更重要的是「不完整」，服務(wù)器端方面的需求，都需要通過(guò)在項(xiàng)目之外維護(hù)云函數(shù)，或自己用服務(wù)器端框架開(kāi)發(fā) BFF 服務(wù)。整個(gè)應(yīng)用的業(yè)務(wù)需求，無(wú)法作為一個(gè)整體去實(shí)現(xiàn)「低碼化 / 無(wú)碼化」。

「現(xiàn)代 Web 開(kāi)發(fā)」的發(fā)展趨勢(shì)，帶來(lái)了從「前后端分離」到「前后端一體化」的變化，「前后端分離」時(shí)期的兩種前端工程方案，合并成了一種，可以稱作「新一代 JAMstack」，它仍然由三大要素組成，但就像圖中綠色高亮出來(lái)的部分，這三個(gè)組成要素代表的東西，已經(jīng)發(fā)生了變化。

「以 JS 為中心」意味著更成熟的基于編程語(yǔ)言的軟件開(kāi)發(fā)方式，而不是圍繞「內(nèi)容」的傳統(tǒng)前端開(kāi)發(fā)方式。「一體化 BFF」意味著工程方案現(xiàn)在是「完整」的，可以讓應(yīng)用的業(yè)務(wù)需求作為一個(gè)整體來(lái)實(shí)現(xiàn)。M 代表的「前端 Serverless」、「一體化 SSR」等，提高了代碼部分的抽象層級(jí)，讓代碼更專注于業(yè)務(wù)需求，減少大量服務(wù)器端實(shí)現(xiàn)細(xì)節(jié)。這些變化都有利于「全碼」通用搭建的實(shí)現(xiàn)。

以一個(gè) Modern.js 的「應(yīng)用」項(xiàng)目為例，項(xiàng)目是以 src 對(duì)應(yīng)的客戶端應(yīng)用代碼為中心來(lái)開(kāi)發(fā)的，盡最大可能讓開(kāi)發(fā)者不用感知到服務(wù)器，不止是部署運(yùn)維環(huán)節(jié)，也包括開(kāi)發(fā)環(huán)節(jié)。

比如這個(gè)更簡(jiǎn)單的 Modern.js 「應(yīng)用」項(xiàng)目。api 目錄對(duì)應(yīng)的 BFF 實(shí)現(xiàn)，看上去幾乎沒(méi)有任何服務(wù)器端代碼的痕跡，可以像普通函數(shù)一樣設(shè)計(jì)和實(shí)現(xiàn)，像普通函數(shù)一樣在應(yīng)用代碼里調(diào)用（有充分的抽象），但這種代碼能實(shí)現(xiàn)任意的 REST API，能滿足任意的 BFF 開(kāi)發(fā)需求。這也是我們前面提到的「一體化 BFF」。

這個(gè)項(xiàng)目中這段包含在 useLoader API 中的代碼，體現(xiàn)了前面說(shuō)的「一體化 SSR」，同一塊業(yè)務(wù)邏輯，只需要一次代碼實(shí)現(xiàn)，會(huì)自動(dòng)在 CSR、SSR、SSG 等不同情況下運(yùn)行。并且由于是基于足夠抽象的 API 來(lái)實(shí)現(xiàn)，會(huì)在這些情況下自動(dòng)優(yōu)化。比如這段代碼在獨(dú)立 SSR Server 中運(yùn)行的時(shí)候，會(huì)自動(dòng)切換成內(nèi)網(wǎng)方式來(lái)請(qǐng)求 BFF Server 的 API，如果 SSR 和 BFF 運(yùn)行于同一個(gè) Server 進(jìn)程，會(huì)自動(dòng)切換成真正的函數(shù)調(diào)用，沒(méi)有網(wǎng)絡(luò)請(qǐng)求。

3.2.2 新一代「前端三劍客」

「現(xiàn)代 Web 開(kāi)發(fā)」范式的紅利，在「前端三劍客」的演變上也有體現(xiàn)。

「前端三劍客」這個(gè)詞起源自 Dreamweaver、Fireworks、Flash，對(duì)于現(xiàn)在很多前端開(kāi)發(fā)者來(lái)說(shuō)可能已經(jīng)很陌生了。隨著 Web 標(biāo)準(zhǔn)的普及，Open Web 技術(shù)中的三個(gè)核心要素，HTML、CSS、JS 成為了第 2 代的「前端三劍客」。而自從 Node.js 的出現(xiàn)為前端技術(shù)棧普及編譯構(gòu)建工具鏈、補(bǔ)充服務(wù)器端開(kāi)發(fā)能力，前端開(kāi)發(fā)就一直是圖上第 3 代「前端三劍客」的模式。

從最早使用字符串模板的 jQuery，到后來(lái)的雙向綁定、FP 范式的函數(shù)組件，都屬于第 3 代「前端三劍客」中的視圖框架，而三劍客中第二個(gè)要素「Node.js CLI」代表了工程化相關(guān)，第三個(gè)要素是服務(wù)器端 Node.js 框架。

而「現(xiàn)代 Web 開(kāi)發(fā)」范式的基礎(chǔ)，已經(jīng)轉(zhuǎn)移到了第 4 代「前端三劍客」?？梢钥吹?Modern.js 正是起到了第 4 代中「元框架」的作用，而「全碼」通用搭建，包括我們之前說(shuō)的星夜，本質(zhì)上也是在滿足第 4 代「前端三劍客」中低代碼部分的需求。

可以看到「前端三劍客」的每一代，跟上一代之間恰好都是「包含關(guān)系」，每一代中都會(huì)有一個(gè)要素，把上一代的三大要素包含在自己內(nèi)部。

背后的原因之一是，隨著需求和技術(shù)的發(fā)展，上一代的「前端三劍客」會(huì)越來(lái)越難以應(yīng)對(duì)，復(fù)雜性不斷增加，而新一代三劍客會(huì)把這些復(fù)雜性和細(xì)節(jié)隱藏、屏蔽到自己的一個(gè)要素中，而這個(gè)要素也因此成為新的基礎(chǔ)底層，支撐三劍客中另外兩個(gè)要素，支持各種業(yè)務(wù)項(xiàng)目的基礎(chǔ)建設(shè)。

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

3.2.3 基于「前端技術(shù)」的成熟 GUI 軟件研發(fā)體系

在「現(xiàn)代 Web 開(kāi)發(fā)」范式的趨勢(shì)下，能形成基于「前端技術(shù)」的成熟 GUI 軟件研發(fā)體系，這對(duì)于「全碼」通用搭建來(lái)說(shuō)，是非常必要的條件。

傳統(tǒng)前端開(kāi)發(fā)中，「DX」和「UX」是不可兼得的。在這種情況下，如果把「低/無(wú)碼化」做的足夠好，提升了 DX，UX 必然受損，導(dǎo)致搭建結(jié)果的性能、能力等，跟專業(yè)開(kāi)發(fā)的結(jié)果有較大差距，或者不夠「通用」，無(wú)法滿足專業(yè)開(kāi)發(fā)能滿足的所有場(chǎng)景。反之如果保障了 UX，「低/無(wú)碼化」的目標(biāo)就會(huì)受損，比如無(wú)法給不懂技術(shù)的用戶使用，或搭建過(guò)程非常復(fù)雜繁瑣。

以前面提到過(guò)的、極簡(jiǎn)的 Modern.js「應(yīng)用」項(xiàng)目為例，只需要配置開(kāi)啟功能，就能實(shí)現(xiàn)：

自動(dòng) SSR
根據(jù) UA 自動(dòng)裁剪 Polyfill
根據(jù) UA 自動(dòng)差異化分發(fā)（Differencial Loading）面向現(xiàn)代瀏覽器的 ES6+ 代碼和面向歷史遺留瀏覽器的 ES5 代碼

在文件很少、代碼量很少、DX 足夠好的情況下，也同時(shí)實(shí)現(xiàn)了很多傳統(tǒng)項(xiàng)目中自己寫大量代碼也沒(méi)有實(shí)現(xiàn)的 UX。

在 Modern.js 的支持下，「全碼」通用搭建能針對(duì)最少量的、最抽象的專業(yè)代碼做「低/無(wú)碼化」，而搭建產(chǎn)物自動(dòng)獲得產(chǎn)品級(jí)的能力和性能，不需要自身去解決這些 DX 和 UX 的問(wèn)題，當(dāng)然也更不需要圍繞垂直場(chǎng)景來(lái)解決它們。

要實(shí)現(xiàn) DX 和 UX 的同時(shí)最大化，從根本上來(lái)說(shuō)，需要「充分的抽象」，需要「框架」模式。

就像圖中左側(cè)，傳統(tǒng)前端開(kāi)發(fā)的 DX 和 UX 之所以不可兼得，原因之一是它是基于「庫(kù)」、「工具」來(lái)開(kāi)發(fā)的。最外層的大方塊表示整個(gè)項(xiàng)目，是藍(lán)色的，代表開(kāi)發(fā)者自己要寫的代碼，其中嵌入的綠色方塊，代表被作為「積木」來(lái)組裝、在自己的代碼中調(diào)用的「庫(kù)」和「工具」。

要支持「全碼」通用搭建，需要基于圖中右側(cè)體現(xiàn)的「框架」來(lái)開(kāi)發(fā)，可以看到整個(gè)項(xiàng)目是紅色的，是框架本身，而藍(lán)色方塊代表的開(kāi)發(fā)者自己寫的代碼，反而被嵌入在框架的「插槽」中，被框架來(lái)調(diào)用和組裝，開(kāi)發(fā)者自己寫的代碼成了「積木」。

在專業(yè)研發(fā)中有了這種程度的抽象，才有可能實(shí)現(xiàn)完全基于專業(yè)研發(fā)體系和真實(shí)代碼的「全碼」通用搭建。

「充分的抽象」也意味著要像 Modern.js 一樣，盡可能在所有環(huán)節(jié)做抽象，不止傳統(tǒng)前端開(kāi)發(fā)中常見(jiàn)的運(yùn)行時(shí)環(huán)節(jié)的抽象（比如 DSL 渲染就是一種運(yùn)行時(shí)抽象），也要在編譯時(shí)、服務(wù)器端運(yùn)行時(shí)、甚至寫代碼的「編寫時(shí)」做抽象。

工程方案的收斂和標(biāo)準(zhǔn)化，對(duì)「充分的抽象」來(lái)說(shuō)也是必須和必然的，就像以前分享里指出的海量模板問(wèn)題，如果任意維度有任意變化，都會(huì)產(chǎn)生新的樣板代碼和「模板」，那么基于真實(shí)代碼去實(shí)現(xiàn)「通用」搭建，幾乎不可能。

工程方案的收斂和標(biāo)準(zhǔn)化也是 Modern.js 的主要目標(biāo)之一，目前已經(jīng)把工程方案收斂到最少的三個(gè)，其中的「應(yīng)用」工程方案，又稱作「MWA（Modern Web App）」，是「全碼」通用搭建中實(shí)現(xiàn)「對(duì)復(fù)雜度本身做抽象和解耦」的基礎(chǔ)之一。

3.2.4 「MWA」：從 Universal JS 到 Universal App

MWA 實(shí)現(xiàn)了 Universal App 模式。

就像圖上梳理的，不論是 SPA 和 MPA 相關(guān)的差異，還是實(shí)現(xiàn) CSR、SSR、SSG 之間一體化和混合共存要解決的差異，還是 BFF 業(yè)務(wù)邏輯跟客戶端業(yè)務(wù)邏輯之間的差異、Node.js 框架之間的差異，以及常規(guī) web、微前端子應(yīng)用、基于 Electron 的桌面應(yīng)用、小程序等之間的差異，都被 MWA 抹平，把這些需求統(tǒng)一成同一個(gè)「Universal」的「應(yīng)用」工程方案。

用同一個(gè)「模板」就能開(kāi)發(fā)任意需求，同一個(gè)「應(yīng)用」項(xiàng)目，也能以靜態(tài) web、SSR、微前端、Electron 等不同方式運(yùn)行，能同時(shí)部署不同形態(tài)的版本。

因此「全碼」通用搭建只需要實(shí)現(xiàn)「MWA」的低/零碼搭建，就可以實(shí)現(xiàn)微前端、桌面應(yīng)用、小程序等各種應(yīng)用的搭建能力。

幻燈片上這個(gè)例子，展示的是，任意 MWA 都可以隨時(shí)成為微前端主應(yīng)用，并且自動(dòng)滿足其中的 UX 需求。

3.2.5 應(yīng)用架構(gòu)

MWA 提供開(kāi)箱即用的、以客戶端為中心的應(yīng)用架構(gòu)，對(duì)「全碼」通用搭建來(lái)說(shuō)，也非常重要。如果沒(méi)有應(yīng)用架構(gòu)提供的標(biāo)準(zhǔn)化抽象，要基于真實(shí)代碼做低/零碼搭建，就要跟粒度非常細(xì)、非常原子的、瑣碎的底層代碼打交道，難以實(shí)現(xiàn)好的效果。

MWA 的應(yīng)用架構(gòu)讓一個(gè)「應(yīng)用」可以由「Universal App Shell」、視圖組件、業(yè)務(wù)模型、容器組件組成，可以基于這些最粗粒度的「物料」來(lái)實(shí)現(xiàn)「全碼」通用搭建。

解耦出來(lái)的視圖組件和業(yè)務(wù)模型，可以有多種適合不同場(chǎng)景的「生產(chǎn)方式」，而「消費(fèi)方式」是標(biāo)準(zhǔn)化的。

容器組件起到 Controller 作用，能用標(biāo)準(zhǔn)化的方式、很薄的膠水代碼，來(lái)連接視圖組件和業(yè)務(wù)模型。

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

前面提到的「業(yè)務(wù)模型」（Model），在「全碼」通用搭建中是跟 UI 組件一樣廣泛使用的基礎(chǔ)「物料」，可以封裝客戶端中 UI 無(wú)關(guān)的業(yè)務(wù)邏輯，標(biāo)準(zhǔn)化的使用。

3.2.6 「模塊」工程方案

「全碼」通用搭建中實(shí)現(xiàn)「對(duì)復(fù)雜度本身做抽象和解耦」的另一個(gè)基礎(chǔ)，是「模塊」工程方案。

Modern.js 中的「模塊」工程方案讓前面提到的視圖組件、容器組件（也可以稱作「業(yè)務(wù)組件」）、業(yè)務(wù)模型（Model）可以獨(dú)立開(kāi)發(fā)、調(diào)試、測(cè)試和復(fù)用。

Modern.js 也支持「模塊」工程方案中的代碼，無(wú)縫的使用跟「應(yīng)用」（MWA）工程方案中一樣的 Runtime API 標(biāo)準(zhǔn)庫(kù)。比如創(chuàng)建和使用 Model 的 API、支持「動(dòng)靜一體」的 API 等等。讓「模塊」工程中的組件不局限于封裝純 UI 邏輯，不局限于「原子組件」，鼓勵(lì)更多「不同粒度」的業(yè)務(wù)組件的復(fù)用和沉淀，也讓「全碼」通用搭建在各種場(chǎng)景下都能提供合適的搭建能力和用法。

「模塊」工程方案封裝了產(chǎn)物方面的主流需求和最佳實(shí)踐，跟前面說(shuō)的「Universal App」模式一樣，讓開(kāi)發(fā)者只需要關(guān)心業(yè)務(wù)邏輯的復(fù)用和沉淀，讓同一份代碼自動(dòng)適用于各種場(chǎng)景，自動(dòng)具備各種運(yùn)行模式（比如 Modern.js 即將提供的類似微前端的「微模塊」用法），自動(dòng)能用于低/無(wú)碼搭建。

3.3 「全碼」：與專業(yè)研發(fā)體系無(wú)縫結(jié)合的「低/無(wú)碼」

前面介紹了為實(shí)現(xiàn)「全碼」通用搭建創(chuàng)造條件的「現(xiàn)代 Web 開(kāi)發(fā)」范式和 Modern.js 工程體系。星夜作為「全碼」通用搭建解決方案，跟前面說(shuō)的工程體系是無(wú)縫結(jié)合的，

星夜不需要像傳統(tǒng)「前端可視化搭建」一樣，通過(guò) DSL 「協(xié)議」來(lái)做領(lǐng)域建模，因?yàn)?Modern.js 本身就是對(duì) Web 開(kāi)發(fā)的最大化的抽象和標(biāo)準(zhǔn)化，這套工程體系和其中的「Pro Code」，本身就已經(jīng)是一個(gè)「協(xié)議」。

星夜也不需要另起爐灶搞一套平臺(tái)鎖定的專用 Pro Code 方案，而是跟專業(yè)開(kāi)發(fā)者的日常研發(fā)完全保持一致。這也讓星夜不需要跟特定的 Design System 和組件體系捆綁在一起，可以支持任意 Design System 和任意組件。因此物料的沉淀積累和生態(tài)建設(shè)也是共通的，避免前面說(shuō)過(guò)的 ROI 問(wèn)題。

就像幻燈片上畫的，這種「全碼」模式，不僅解決「輸入」側(cè)（比如物料）的問(wèn)題、帶來(lái)新能力，也在「輸出」側(cè)帶來(lái)新能力。由于星夜的輸出就是前面說(shuō)的「MWA」，跟專業(yè)開(kāi)發(fā)者手寫的 MWA 一致，所以除了前面講過(guò)的「Universal App」能力，還帶來(lái)了新的低/零碼提效路徑：一個(gè)業(yè)務(wù)項(xiàng)目不用在專業(yè)開(kāi)發(fā)和低碼搭建之間二選一，不用修改技術(shù)棧和舊代碼，可以按需漸進(jìn)的引入低碼提效。比如對(duì)一些新需求（比如局部頁(yè)面、局部區(qū)域）嘗試用星夜來(lái)搭建，讓開(kāi)發(fā)者逐步從這些需求中解放出去，也逐步積累物料和新工作流的經(jīng)驗(yàn)，為進(jìn)一步的低碼提效和解放開(kāi)發(fā)資源做準(zhǔn)備。

3.4 Code In, Code Out

星夜作為「全碼」通用搭建，是「專業(yè)代碼進(jìn)，專業(yè)代碼出」的。不像傳統(tǒng)「前端可視化搭建」一樣圍繞 DSL 設(shè)計(jì)，而是從一開(kāi)始就完全圍繞真實(shí)專業(yè)的代碼來(lái)實(shí)現(xiàn)。

在編輯和運(yùn)行環(huán)節(jié)，不需要 DSL 運(yùn)行時(shí)、渲染器等，星夜編輯器本質(zhì)上就是 Web IDE（包括瀏覽器端沙盒的 Web IDE 和服務(wù)器端沙盒的 Web IDE），編輯過(guò)程跟 Web IDE 一樣加載代碼、運(yùn)行代碼、修改代碼、生成代碼。

編輯器的內(nèi)部實(shí)現(xiàn)中，像 IDE 的實(shí)現(xiàn)一樣用到各種數(shù)據(jù)結(jié)構(gòu)和存儲(chǔ)，對(duì)于「全碼」通用搭建，要注意這些內(nèi)部實(shí)現(xiàn)是不應(yīng)該讓專業(yè)代碼被整體「配置化」的，不能降級(jí)成一種領(lǐng)域模型，成為變相的 DSL（這種內(nèi)部 DSL 也很容易「泄露」出去變成 API）。

星夜編輯器加載和運(yùn)行的，是全量、完整的項(xiàng)目代碼，而「修改」的對(duì)象和方式有兩類。一類雖然也是項(xiàng)目代碼的一部分，但本質(zhì)是模式化、標(biāo)準(zhǔn)化的膠水代碼，專業(yè)開(kāi)發(fā)者需要從這種代碼的開(kāi)發(fā)工作中解脫出去，這種代碼的實(shí)現(xiàn)過(guò)程是適合「低/無(wú)碼化」的。還有一類屬于「不可避免的復(fù)雜性」，應(yīng)該讓專業(yè)開(kāi)發(fā)者可以完全掌控，用專業(yè)研發(fā)體系的完整能力，在 Web IDE 或本地開(kāi)發(fā)環(huán)境里手工實(shí)現(xiàn)和維護(hù)。

3.5 搭建任意應(yīng)用

「全碼」通用搭建帶來(lái)的最重要的新能力，就是真正能做到「通用」，可以用于實(shí)現(xiàn)「任意應(yīng)用」。

以星夜為例，首先星夜不止是「前端搭建」，既支持「界面驅(qū)動(dòng)」，也支持「模型驅(qū)動(dòng)」（比如 CMS 建模、流程編排、引導(dǎo)搭建等），由于 MWA 是前后端一體化的全棧工程方案，星夜生成的應(yīng)用代碼里同時(shí)包含后端和前端業(yè)務(wù)邏輯，可以獨(dú)立部署和運(yùn)維。

另一方面，星夜編輯器就像 Web IDE 一樣，只是提供了一個(gè)「舞臺(tái)」，只提供「機(jī)制」而不提供「策略」，也就是說(shuō)編輯器本身具備各種能力，但不決定具體的搭建用法，而是由「物料」（比如 UI 組件）來(lái)決定用法。編輯器會(huì)根據(jù)「物料」的代碼、接口描述等信息，自動(dòng)生成不同的 UI 和交互。

因此任何前端開(kāi)發(fā)者都可以通過(guò)開(kāi)發(fā)和維護(hù)不同的「物料」體系（比如不同的業(yè)務(wù)組件庫(kù)），在星夜上提供針對(duì)不同用戶類型、不同垂直場(chǎng)景、不同復(fù)雜程度的搭建能力、用法、工作流。

由于「全碼」通用搭建跟專業(yè)研發(fā)體系無(wú)縫結(jié)合，所以專業(yè)研發(fā)體系能做什么，星夜就能做什么。前端開(kāi)發(fā)者也可以隨時(shí)直接「介入」星夜中的應(yīng)用，直接自定義代碼滿足任意非模式化的、一次性的需求。

列舉幾個(gè)在字節(jié)內(nèi)部支持不同場(chǎng)景的例子。

第一個(gè)例子是網(wǎng)站場(chǎng)景，火山引擎官網(wǎng)讓產(chǎn)品經(jīng)理和供應(yīng)商使用星夜自助搭建和維護(hù)自己的產(chǎn)品頁(yè)面，發(fā)布時(shí)自動(dòng)作為微前端子應(yīng)用，嵌入到前端團(tuán)隊(duì)維護(hù)的 MWA 工程里，自動(dòng)用 SSR 方式運(yùn)行。在星夜中和 MWA 工程中使用相同的官網(wǎng)業(yè)務(wù)組件庫(kù)，組件在星夜中的用法，面向不寫代碼的產(chǎn)品人員設(shè)計(jì)。

第二個(gè)例子是活動(dòng)場(chǎng)景，運(yùn)營(yíng)用星夜編輯器搭建今日頭條和西瓜視頻端內(nèi)端外的活動(dòng)和 Hybrid 界面。使用的組件庫(kù)、組件的用法都完全不一樣，組件中包含跟 CMS（運(yùn)營(yíng)平臺(tái)）相關(guān)的業(yè)務(wù)邏輯?？梢钥吹骄庉嬈鞅旧硪灿忻嫦蜻@個(gè)垂直場(chǎng)景的自定義。

第三個(gè)例子是中后臺(tái)場(chǎng)景，由后端開(kāi)發(fā)者搭建，涉及更靈活的邏輯編排、大型的 CRUD 業(yè)務(wù)組件，連接自己實(shí)現(xiàn)的服務(wù)器端 API 等。

第四個(gè)例子是數(shù)據(jù)大屏場(chǎng)景。這些例子中的用法，都是業(yè)務(wù)部門的前端開(kāi)發(fā)者自己提供的，針對(duì)自己工作中的垂直場(chǎng)景做提效，形成解放開(kāi)發(fā)者的新工作流。而星夜這種「全碼」通用搭建解決方案，除了普及這種提效能力和工作方式，也追求把這種工作的成本降到跟開(kāi)發(fā)者原本在專業(yè)開(kāi)發(fā)工作中做沉淀積累的成本一樣（或更低，比如通過(guò)物料生態(tài)建設(shè)的支持）。

3.6 「低碼中臺(tái)」

最后講一下「全碼」通用搭建能實(shí)現(xiàn)的「低碼中臺(tái)」模式。

前面講「應(yīng)用開(kāi)發(fā)領(lǐng)域的關(guān)卡編輯器現(xiàn)象」時(shí)有提到過(guò)，很多業(yè)務(wù)場(chǎng)景下開(kāi)發(fā)自己專用的低碼搭建平臺(tái)或在自己的平臺(tái)里提供搭建功能，是很正常、不可避免的需求。有很多讓這些項(xiàng)目基于一套通用「協(xié)議」的嘗試，目前為止還沒(méi)有真正意義上成功的例子。「全碼」通用搭建由于不受領(lǐng)域建模的限制，基于標(biāo)準(zhǔn)化的專業(yè)工程體系，工程體系本身就是「協(xié)議」，所以從一開(kāi)始就能實(shí)現(xiàn)「低碼中臺(tái)」能力。

所以星夜的設(shè)計(jì)、實(shí)現(xiàn)和實(shí)踐驗(yàn)證過(guò)程，本身也是在做「全碼」通用搭建這種模式的中臺(tái)化工作和生態(tài)建設(shè)工作，降低采納這種模式的成本。

總結(jié)

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

而圖上左邊藍(lán)色部分，已經(jīng)作為 Modern.js 項(xiàng)目開(kāi)源出來(lái)，既希望能加快「現(xiàn)代 Web 開(kāi)發(fā)」中「元框架」和工程體系的發(fā)展，也希望通過(guò)支持「全碼」通用搭建，一方面為專業(yè)開(kāi)發(fā)者「賦能」突破提效天花板，一方面推動(dòng)越來(lái)越多有軟件需求的全民開(kāi)發(fā)者（Citizen Developer）們獲得「賦權(quán)」，在這個(gè)「軟件統(tǒng)治世界」的時(shí)代，讓更多人能掌控和解決自己的需求。

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