現(xiàn)代 Web 開發(fā)的現(xiàn)狀與未來（JSDC 2019 演講全文）

時間：2022-07-27 20:06:01 | 來源：網(wǎng)站運營

時間：2022-07-27 20:06:01 來源：網(wǎng)站運營

本文是我受邀在臺北的 JSDC 2019 活動中做的一次分享，從內(nèi)容上來說已經(jīng)可以算的上我的 2019 跨年演講 XD

我比較懼怕公開演講，習慣事先寫好講稿，雖然照稿念的演講效果比較差，但好處是很快就可以作為文章發(fā)出來 XD（末尾部分的內(nèi)容沒來得及寫講稿，是臨時補寫的，跟現(xiàn)場不一樣）

大家好，非常感謝主辦方邀請我參加這次 JSDC 活動，讓我第一次有機會跟臺灣的 JS 開發(fā)者社區(qū)交流

JS 能在最近十多年里爆炸式發(fā)展到今天的程度，主要原因之一就是它建立在 Open Web 技術(shù)之上，這種技術(shù)是全行業(yè)在平臺技術(shù)上最大最主要的交集和共識，JS 作為 Web 的原生語言，能力是跟 Web 本身一起不斷發(fā)展的，而在 JS 生態(tài)的影響下，Web 本身和 Web 開發(fā)也都已經(jīng)跟過去非常不同

我想通過幾個主題來說明，如果把 Modern Web —— 也就是『現(xiàn)代 Web 開發(fā)』，而非『傳統(tǒng) Web 開發(fā)』——看作一種獨立的技術(shù)范式和專業(yè)領(lǐng)域，它的現(xiàn)狀是怎樣的，有哪些重要趨勢，未來會怎樣，希望對大家有幫助

先介紹一下為什么我自己適合講這個話題，我可能屬于華語地區(qū)最早一批專業(yè)的 JS 開發(fā)者，伴隨這個技術(shù)領(lǐng)域從幾乎一無所有 —— 就是連 Firebug、開發(fā)工具甚至文檔都沒有的年代 —— 一直發(fā)展到今天，在這個過程中我既做過幾乎所有類型的基于 Web 技術(shù)的產(chǎn)品，同時也一直致力于推動社區(qū)和行業(yè)向前發(fā)展，做過一些在當時屬于前沿的基礎(chǔ)建設(shè)，目前在字節(jié)跳動也仍然在負責這方面的建設(shè)（之后會講到）

順便說一個感言，這次來臺灣對我個人還有特殊意義，因為我能進入這個技術(shù)領(lǐng)域，很大程度上要感謝臺灣的前輩

一位前輩是朱學(xué)恒先生，在大陸的游戲圈有一期影響很大的雜志是98年大眾軟件增刊，朱學(xué)恒先生為這期雜志提供的介紹歐美奇幻文學(xué)、龍與地下城游戲的文章，很大程度上成為了大陸地區(qū)相關(guān)愛好者和玩家社區(qū)的起點

然后是同樣來自臺大電機系的幾位前輩創(chuàng)立的奇幻修士會，他們的中文翻譯讓我們接觸到很多被社區(qū)奉為經(jīng)典的作品

我自己并非 CS 科班出身，正因為大學(xué)時加入了網(wǎng)上的奇幻文學(xué)和游戲社區(qū)，創(chuàng)立了個人網(wǎng)站最深的地下城，我才有機會愛上 JS 和 Web 開發(fā)，能站在這個講臺上

回到主題，其實最近幾年我在各種場合都推廣普及過『現(xiàn)代 Web 開發(fā)』的一些理念和趨勢，為了保證大家掌握一樣的上下文，我想先快速回顧之前做過的一些分享

首先是我發(fā)布過一個開源的文檔項目《Spellbook of Modern Web Dev（現(xiàn)代 Web 開發(fā)魔法全書）》，基于社區(qū)經(jīng)驗和數(shù)據(jù)統(tǒng)計，匯總了現(xiàn)代 web 開發(fā)中各個領(lǐng)域的主流項目、資源和經(jīng)典文章，做了細粒度的分類梳理

這個項目發(fā)布后在國際社區(qū)中傳播的速度非常快，可見對這些信息的需求是非常強的，會后如果有現(xiàn)代 Web 開發(fā)方面的疑問，可以看一下這個項目，既可以作為新人培訓(xùn)的自學(xué)教材來使用，也可以當作資料庫來查閱。我最近正在做一輪更新，替換里面一些過時內(nèi)容

然后是在 17 年上海的 JSConfCN 上，我做過一次叫做《理解現(xiàn)代 Web 開發(fā)》的分享，介紹了現(xiàn)代 Web 開發(fā)的發(fā)展歷史，引出幾個重要現(xiàn)象

一個現(xiàn)象是互聯(lián)網(wǎng)產(chǎn)品開發(fā)的分工模式在發(fā)生改變，傳統(tǒng)上的分工是『水平分工』，前端開發(fā)者負責開發(fā)所有產(chǎn)品或程序中的前端部分，后端開發(fā)者負責所有后端部分，在有些團隊和產(chǎn)品領(lǐng)域里，認為全棧開發(fā)者可以同時負責這兩層

新分工模式是『垂直分工』，把人類和機器看成兩個極端，在之間畫一條光譜，再把這條光譜垂直切成三個頻段，每個頻段里的開發(fā)者，掌握的技術(shù)和關(guān)心的問題，都差別非常大，每個頻段里都可能有客戶端部分和服務(wù)器端部分，但對相關(guān)技術(shù)的要求不完全一樣

一個應(yīng)用開發(fā)者可以為『面向人類』的產(chǎn)品，開發(fā)專用的服務(wù)器端 API（BFF），但通常不會同時精通 NLP 和能用最專業(yè)的姿勢開發(fā)分布式日志處理系統(tǒng)

一個分布式基礎(chǔ)設(shè)施開發(fā)者可以在工具支持下為自己的系統(tǒng)添加簡單的界面，但通常不適合開發(fā)用戶體驗要求高的大型 SaaS 應(yīng)用

這種分工模式除了要求『前端開發(fā)者』成為『應(yīng)用開發(fā)者』，使用更完善的 GUI 軟件開發(fā)技術(shù)和工具，還衍生出來一個問題是：如何提供工具讓其他垂直領(lǐng)域的開發(fā)者能自主搭建應(yīng)用，滿足這個領(lǐng)域中的簡單 UI 需求，后面的分享內(nèi)容中會再講到這個問題

新分工模式下的應(yīng)用開發(fā)者要掌握『現(xiàn)代 Web 開發(fā)』技術(shù)，這種技術(shù)的特征是：

不像傳統(tǒng) Web 開發(fā)以服務(wù)器端為主體、前端是后端 Web 框架中的一部分，現(xiàn)代 Web 開發(fā)是以客戶端為主體，而后端部分比如 SSR、BFF、Serverless 可以成為前端框架中的一部分

因此現(xiàn)代 Web 開發(fā)中不止有客戶端，在客戶端部分，也不止有瀏覽器，而是面向更廣泛的具備 Web Runtime 的平臺（后面的分享內(nèi)容中會再講到這個問題）

第四個特征是以 JS 為中心，幾乎會盡可能用 JS 解決一切問題

但在這種情況下，很多開發(fā)者都在抱怨另一個現(xiàn)象『JS 疲勞』，認為 JS 發(fā)展的太快，新技術(shù)、新開源項目層出不窮，用大陸的網(wǎng)絡(luò)用語來說，就是開發(fā)者覺得心很累，沒有力氣再愛了

我們通過幻燈片快速看一下如何理解這種現(xiàn)象，它有三個根源，一個是多樣性，這里說的『明年』是指 18 年

這種多樣性類似美國族群的多樣性，雖然理想中是『大熔爐』，現(xiàn)實中卻常常是『沙拉碗』，社區(qū)中來自不同技術(shù)背景和行業(yè)的開發(fā)者，互相之間的融合程度非常有限，進一步放大了社區(qū)生態(tài)的多樣性

第二個根源是需求多

第三個根源是成本低，包括語言本身的特點、API 的能力、以及社區(qū)生態(tài)的發(fā)展，帶來的低成本能力

要解決這個問題，一方面是要掌握整體圖景，前面介紹過的《現(xiàn)代 Web 開發(fā)魔法全書》正是服務(wù)于這種需求的項目

另一方面，前面說的「低成本」既是產(chǎn)生問題的原因，其實也是解決問題的方法，但前提是要普及和維護

今天我們再回頭看這個問題，仍然有很多抱怨和困惑，但已經(jīng)改善很多

一方面，我們在 17 年就能看到一個趨勢是：現(xiàn)代 Web 開發(fā)的很多主流領(lǐng)域，技術(shù)方案已經(jīng)開始穩(wěn)定下來，有了明顯的勝出者，前面說的魔法全書就非常重視挖掘和匯總這些主流項目

另一方面還有框架的幫助，后面的分享內(nèi)容中會再講到這個問題

我要分享的內(nèi)容分成兩部分，先看一些『現(xiàn)狀』，再看『未來』

大家可能知道大陸的 CCTV 在黃金時段會播出一檔很有名的、收視率很高的電視節(jié)目，叫新聞聯(lián)播，接下來我也會口播一系列 Modern Web 新聞

首先是近年來，國際社區(qū)出現(xiàn)三個重大問題，引發(fā)了很多討論

第一個重大問題，可以翻譯成『大分裂』，說的是『前端開發(fā)者』正在分裂成沒有共同語言的兩個群體、完全不同的兩個世界

參加今天這個活動的可能多數(shù)都是比較年輕的 JS 開發(fā)者，可能對這個問題感受比較少，感受最強烈的有兩類人群：一類是很多年前開始以前端開發(fā)者的身份工作，并且滿足于當時的工作方式和工作內(nèi)容，另一類是因為對用戶體驗、UI 設(shè)計、動畫、可訪問性等問題感興趣而成為前端開發(fā)者

從他們的角度來看待這個問題會更容易理解，對他們來說，『前端開發(fā)者』這個詞已經(jīng)完全變成另一種含義，對應(yīng)的是一套完全不同的技能體系和思維方式

『前端開發(fā)者』這個詞，無論在國際還是在大陸，現(xiàn)在都主要指圖中左邊的技能體系

在右邊的開發(fā)者眼里，『前端開發(fā)』現(xiàn)在變得完全以 JS 為中心，需要掌握很多以前只有后端才需要掌握的編程知識，比如架構(gòu)原則、API設(shè)計、數(shù)據(jù)模型等。曾經(jīng)只要用 HTML、CSS 和少量 JS 交互就能創(chuàng)建 Web 界面，而這種工作現(xiàn)在變得復(fù)雜到不可理解。他們不理解為什么左邊的人認為只會寫 JS 是可以的，只會寫 HTML 和 CSS 卻不可以。他們覺得自己作為專家，卻要被左邊的人指手畫腳，被強迫以左邊的方式來工作

這些困惑和分歧并不能被前面提到過的『新分工模式』解決，因為我們就算拋棄了『前端』這個過時概念，但在新分工下的『應(yīng)用開發(fā)』領(lǐng)域，仍然存在這個『大分裂』，仍然要面對如何協(xié)調(diào)左右兩種思維方式和工作領(lǐng)域的問題

第二個重大問題可以翻譯成『大困境』，指的是整個互聯(lián)網(wǎng)行業(yè)一直致力于在設(shè)計師和開發(fā)者之間『搭建橋梁』、跨越鴻溝，讓設(shè)計師的輸出物能成為互聯(lián)網(wǎng)產(chǎn)品的『唯一權(quán)威來源（Single Source of Truth?）』，讓設(shè)計能在最終產(chǎn)品中被精確的還原，因此設(shè)計工具層出不窮越來越多，從 Photoshop 發(fā)展到 Sketch 再到 Figma，還有 Zeplin、InVision、Abstract 等等，設(shè)計師跟開發(fā)者一樣要不斷學(xué)習新工具，但是為『橋梁』付出了這么多，最主要的鴻溝和問題卻始終存在

這個『大困境』的根源可能是我們的努力目標和解決方法本身有問題，也就是左側(cè)圖中的模式，大家是在現(xiàn)有的分工模式中做改進，在這種分工里，設(shè)計師的輸出物無論如何都只能是最終產(chǎn)品的一種『效仿』，跟最終產(chǎn)品之間是割裂的

也許只有當我們承認代碼才是最終產(chǎn)品本身，把代碼作為唯一權(quán)威來源，像右側(cè)圖中這樣，去解決如何讓各種分工一起圍繞著代碼來工作，才能徹底逃脫這個『大困境』

第三個重大問題可以翻譯成『大對決』，指的是『開發(fā)者體驗』（DX）和『用戶體驗』（UX）之間的矛盾

在『大分裂』問題中，提到過一部分前端開發(fā)者認為現(xiàn)在的工具鏈已經(jīng)復(fù)雜到不可理解、難以使用，而對另一部分前端開發(fā)者來說，這些現(xiàn)代 Web 開發(fā)領(lǐng)域中的工具反而極大的增強了他們的能力，也大幅提升了他們的開發(fā)者體驗，但與此同時，用戶體驗的很多方面卻沒有以同樣的速度發(fā)生進步，有的甚至倒退了，比如 Web 項目的依賴龐大，訪問 Web 產(chǎn)品時需要下載的文件尺寸越來越大，等等，而如果我們要在每個局部都應(yīng)用最佳實踐，兼顧開發(fā)者體驗和用戶體驗，卻反過來會導(dǎo)致需要大量配置和調(diào)優(yōu)，開發(fā)工作變得復(fù)雜，開發(fā)者體驗受損

接下來，我們看下應(yīng)用形態(tài)發(fā)展成了什么樣子

早在移動互聯(lián)網(wǎng)爆炸式發(fā)展之前，連線雜志就指出傳統(tǒng) Web 已死，而互聯(lián)網(wǎng)會永生

既然 Web 是過時模式，App 才是未來，業(yè)界就開發(fā)了海量的 App 來解決線上線下方方面面大大小小的需求，我所在的公司字節(jié)跳動就非常擅長開發(fā) App，被稱作『App 工廠』（這張圖是隨便找來的，內(nèi)容過時，分類也不正確）

但大家知道，幾乎所有市場調(diào)查都表明，平均每個用戶的手機上，大概只會保持安裝 35個左右的 App，也就是說，并沒有充分享受到移動互聯(lián)網(wǎng)爆炸式發(fā)展帶來的紅利，而是只能接觸其中很小一個局部，或只能跟很小一個局部保持聯(lián)系

如果一個用戶要充分享受到這些紅利，要能夠隨時使用這些 app 來滿足自己各方面的需求，他的生活會是什么樣子呢

多年來，我一直在拿自己做實驗，我的手機上常年保持 2000 多個 App ，幻燈片上就是前年我手機上 15 個屏幕的截屏

如果要記住這 2000個 App，在有需要的時候，快速找到最能滿足需求的app，必然會造成很大的『認知負擔』，所以我在實踐中形成了一套方法

這種方法類似對生物物種的分類

我對所有 App 做了多級的樹狀分類，手機每一屏是一個『一級類別』，比如第二屏是『線下生活』，第三屏是『消費』，第四屏是『金融』

然后每一屏由『二級類別』組成，按從左到右、從上到下的流式順序，每個類別都占據(jù)一個連續(xù)的空間，有一個自己的目錄放在最后，而最常用的 App 會從目錄中拖出來放到目錄前面，相當于快捷入口，功能接近的 App 會連續(xù)排列在一起，形成『三級類別』

最后就形成這種結(jié)構(gòu)，比如，我現(xiàn)在有了一個需求是買菜做飯，我要買鱈魚，就打開手機先進入『線下生活』這個一級類別所在的第二屏，在找到『飲食到家』這個二級類別，然后打開最合適的 App，查找鱈魚

這種使用 App 的方法，實際上重現(xiàn)了 Web 的早期發(fā)展：2000年前后的時候，門戶網(wǎng)站正是用這種多級樹狀分類的方法，成為了互聯(lián)網(wǎng)的入口

但區(qū)別是，在那個年代，可以由門戶網(wǎng)站來統(tǒng)一維護這些分類，把大量網(wǎng)站都收錄和連接起來，而現(xiàn)在市場上扮演類似角色的『超級 App』，并不能把大量 App 連接起來，只能把這些 App 的功能都自己做一遍，做到自己內(nèi)部。如果要享受到市場上各種獨立 App 帶來的好處，只能像我這樣對它們做手動管理

所以如果要充分利用這些 App 的能力，就會形成一套像物種分類一樣層級很深的分類系統(tǒng)

幻燈片上藍色部分是個人維護的層級，綠色部分是 App 內(nèi)部維護的層級，越往下越靠近頂層

這樣就會出現(xiàn)一個問題：最理想的用戶入口在哪里

傳統(tǒng)上，是以『品牌』為入口，比如圖上中間的京東到家 App

但很多時候用戶只有粗略的需求，比如我就是要吃飯，并不會刻意尋找某個品牌，這種時候，理想的入口是靠近層級頂部的，現(xiàn)在市場的『超級 App』，就都在向這個方向發(fā)展，讓自己成為盡可能靠近層級頂部的平臺，不過它們越是朝這個方向發(fā)展，其實也會越接近桌面時代的瀏覽器，成為一個『Web 平臺』——瀏覽器是最頂層的平臺，最大的超級 App

然后還有另一種場景，比如有同事推薦我買一種鱈魚，這個時候理想的入口是靠近層級底部，能直接抵達『內(nèi)容』或『服務(wù)』本身，而不用先打開 App，再一層層找下去，最好也不需要事先安裝這個 App

所以現(xiàn)在大家可以發(fā)現(xiàn)：實際上 Web 沒有死

市場上有海量的商家，包括各種提供『服務(wù)』的商家和提供『內(nèi)容』的商家，它們自己開發(fā)的 App 很難成為用戶的入口，入口通常是它們提供的『服務(wù)』或『內(nèi)容』本身，而這種入口，其實就是 Web 的本質(zhì)，想要提供這種入口能力，要么使用或發(fā)展標準的 Web 技術(shù)，要么暫時用非標準的私有實現(xiàn)，但隨著發(fā)展演化，注定還是會向 Web 標準靠攏

一個例子是，在國際市場的兩種主流方案：PWA 側(cè)重提供『服務(wù)』，使用和發(fā)展了標準的 Web 技術(shù)，而 AMP 側(cè)重提供『內(nèi)容』，它使用了部分非標準的私有實現(xiàn)

AMP 這種模式引起了很多爭議，Google 已經(jīng)在逐步把 AMP 的能力引入到 Web 標準里，讓標準 Web 具備 AMP 的能力

另一個例子是大陸市場上流行的小程序，小程序其實也是 Web 的一種非標準的私有實現(xiàn)，但它更針對那些提供『服務(wù)』的商家（特別是中小商家、線下商家），直接捆綁了上層的 MVVM 開發(fā)框架和工具，讓這些商家可以輕易開發(fā)出能提供原生 App 體驗的『Web』

隨著發(fā)展演進，小程序也注定要向 web 標準靠攏，今年在北京就組織了這樣的標準化研討會

活動產(chǎn)出了一份 W3C 的工作草案，雖然在內(nèi)容方面距離 PWA 和 AMP 的標準化還有點遠，但是向 Web 標準靠攏的客觀趨勢是不會變的：要么把私有技術(shù)替換成已有的標準技術(shù)，要么把私有技術(shù)標準化，讓標準技術(shù)具備同樣的能力

所有這些解決方案，可以通稱為 Web Runtime 解決方案，目前有這么幾類：

第一類是 Open Web 平臺，提供最標準化的技術(shù)，包括 Web 引擎（JS 和 WebAssembly 是 Web 引擎的原生語言）、Web API 和渲染引擎

第二類是『增強版 WebView（Enhanced WebView）』，在第一類的基礎(chǔ)上，提供自定義的 API 和自定義的 UI 渲染后端

第三類可以稱作『加速版移動 Web（Accelerated Mobile Web）』，AMP 和小程序表面上差別很大，本質(zhì)上都屬于這個類別

前三類都是基于平臺級別 App 的，比如瀏覽器、微信、google 等超級 App，四類和第五類是基于開發(fā)工具的解決方案：

一種是 React Native 風格，基于 bridge 和 JS 線程，另一種是 Flutter 風格，基于 AOT 編譯。

第六類是適合桌面平臺的解決方案，把 Node.js Runtime 和 Web 平臺打包在一起

前面說的應(yīng)用形態(tài)、App 和 Web 的關(guān)系，都主要側(cè)重移動平臺，而在發(fā)展時間更長的桌面平臺上，已經(jīng)幾乎不存在這些問題：Web 平臺和 Web 技術(shù)都是絕對的統(tǒng)治者

而且雖然移動互聯(lián)網(wǎng)的市場規(guī)模遠遠超過桌面互聯(lián)網(wǎng)時代，但桌面平臺上的應(yīng)用開發(fā)需求不但沒有衰弱，反而也大幅增加了

在大陸，對這些需求有一個獨特的稱呼，叫做『中臺應(yīng)用』，這個詞其實一定程度上能體現(xiàn)這種需求增加的本質(zhì)：就是我們開始把面向消費者用戶的產(chǎn)品背后的各個方面的基礎(chǔ)能力，做成更通用的服務(wù)提供出來復(fù)用，并且通過桌面端的應(yīng)用提供用戶界面

幻燈片上是我隨便搜的一張阿里的中臺架構(gòu)圖，在字節(jié)跳動內(nèi)部同樣有大量中臺應(yīng)用項目，其實比起『App 工廠』，字節(jié)跳動更像是『超級 App 工廠 + 工具 App 工廠 + Web 工廠 + SaaS 工廠 + 中臺應(yīng)用工廠』

桌面應(yīng)用需求的穩(wěn)定和增加，還有一個原因是：我們在生活、工作和創(chuàng)造活動中使用的生產(chǎn)力應(yīng)用，需要效率更高、更沉浸式的用戶界面，所以需要類似桌面電腦、平板這樣的平臺

幻燈片上就是字節(jié)跳動開發(fā)的一站式工作平臺『飛書』，它的移動 App 非常好用，但日常工作中我們使用更多的是桌面 App，這個 App 是基于 Electron 用 JS 開發(fā)的

這種對沉浸式用戶界面的需求，不會因為移動設(shè)備的流行而減弱，而且如果這種 UI 足夠強大，它會不但適合工作，也適合社交和娛樂

今年 Facebook 發(fā)布了 Horizon，是一個 VR 社交應(yīng)用，能讓我們看到應(yīng)用形態(tài)的一些新的可能性

但這種類似《黑客帝國》的產(chǎn)品，也容易引發(fā)不信任，很多人擔心由 Facebook 這樣的科技巨頭控制的產(chǎn)品，越是包羅萬象無處不在，越是能替代真實世界，就越容易獲取個人隱私，會強迫用戶看到更多廣告，等等

最后來看一下開發(fā)工具有什么發(fā)展，這個領(lǐng)域在近幾年其實已經(jīng)發(fā)展成一個熱門投資領(lǐng)域，涌現(xiàn)出很多基于開源項目、Web App 或云服務(wù)的初創(chuàng)公司，我想通過幾個典型的融資事件來體現(xiàn)這種發(fā)展

去年 5 月，Prisma 獲得種子輪 450 萬美元的投資，Prisma 能為各種數(shù)據(jù)庫自動生成 GraphQL API Gateway，讓應(yīng)用開發(fā)者可以直接在客戶端或者 BFF 中編寫業(yè)務(wù)邏輯，不需要依賴專業(yè)后端開發(fā)者提供圍繞數(shù)據(jù)層的微服務(wù)

接下來 10 月，Netlify 融到 B 輪 3000萬美元，Netlify 已經(jīng)發(fā)展成國際上最主流的靜態(tài) Web 部署平臺，既提供便捷、Serverless 的開發(fā)者體驗，也為用戶提供最快的訪問速度

同樣在 10 月，Replit 獲得種子輪 450 萬美元的投資，這是一個在線開發(fā)環(huán)境，為 60 多種語言或框架提供 WebIDE、終端甚至在線開發(fā)原生圖形界面的功能，開發(fā)者可以不用在本地機器上安裝這些開發(fā)環(huán)境和調(diào)試工具

再看今年 7 月，同樣提供在線開發(fā)環(huán)境的 CodeSandbox 獲得種子輪 240 萬美元的投資，這個平臺只支持 JS 和 Web 開發(fā)，但是提供了更好的框架集成，現(xiàn)代 Web 開發(fā)者可以打開瀏覽器就直接編寫基于框架和編譯工具的代碼，立刻看到效果，不用搭建和配置環(huán)境

同樣在 7 月，Glitch 也獲得 A 輪 3000 萬美元的投資，Glitch 也是一個專注于 JS 和 Web 開發(fā)的在線開發(fā)環(huán)境，致力于降低現(xiàn)代 web 開發(fā)的門檻，讓寫現(xiàn)代 Web 像以前寫 HTML、CSS 一樣方便直觀

到了 9 月，Gatsby 獲得 A 輪 1500 萬美元的投資，Gatsby 已經(jīng)發(fā)展成目前國際上最主流的建站解決方案，對傳統(tǒng)的基于 CMS 的解決方案比如 Wordpress 造成嚴重威脅

所以 Wordpress 今年也做了巨大的革新

傳統(tǒng) CMS 在衰弱，Headless CMS 卻越來越流行，這個月提供 Headless CMS 服務(wù)的 Strapi 剛剛獲得種子輪 400 萬美元的投資

我們剛才看了很多現(xiàn)狀，包括三個重大問題、應(yīng)用形態(tài)的發(fā)展、開發(fā)工具的發(fā)展，這些現(xiàn)狀既是進步，給我們帶來很多能力，解決很多問題，同時也提出了很多新問題

目前涌現(xiàn)的幾個趨勢中已經(jīng)包含這些問題的解決辦法，這些趨勢都已經(jīng)在發(fā)展中，是正在發(fā)生的未來

一個趨勢是『內(nèi)容開發(fā)』和『應(yīng)用開發(fā)』之間的融合

前面提到過『前端開發(fā)』發(fā)生了『大分裂』，這種分裂的根源之一是：

『前端開發(fā)』原本是在傳統(tǒng) Web 開發(fā)中，為偏重『內(nèi)容』的部分寫代碼，這些『內(nèi)容』是后端 Web 應(yīng)用的『輸出物』，因為主要業(yè)務(wù)邏輯在后端，所以原始的 HTML、CSS 和少量 JS 就能滿足需求，要考慮的問題也圍繞『內(nèi)容』，比如可訪問性等等

而在現(xiàn)代 Web 開發(fā)中，『前端開發(fā)者』是負責寫應(yīng)用的人，要考慮整個 GUI 軟件完整生命周期中所有問題，而且由于這些應(yīng)用已經(jīng)是客戶端應(yīng)用，不可能再向其他地方輸出『內(nèi)容』，需要在自己內(nèi)部展現(xiàn)『內(nèi)容』，所以『前端開發(fā)者』也仍然要負責『內(nèi)容』的視覺、交互、可訪問性等問題

『大分裂』的本質(zhì)是：把『前端開發(fā)者』這個分工，照搬到『現(xiàn)代 Web 開發(fā)』中，導(dǎo)致這個分工需要同時負責『應(yīng)用』和『內(nèi)容』兩方面的事情，而事實上，多數(shù)人只會擅長和偏好其中一種，要么成為嚴肅的『軟件開發(fā)工程師（SDE）』，要么成為用戶體驗和內(nèi)容方面的專家

身為設(shè)計師和前端開發(fā)者的 Brad Frost 提出一種方法，在設(shè)計和開發(fā)這兩個分工之間，增加第三個分工，叫做『前端設(shè)計（Frontend Design）』

表面上看，這個方法好像是要倒退回過去，在設(shè)計師和以服務(wù)器端開發(fā)為主的工程師之間，增加一個『前端開發(fā)』的分工，但換個角度來看，這種方法其實反映了『大分裂』的本質(zhì)，就是被照搬到『現(xiàn)代 Web 開發(fā)』中的『前端開發(fā)』，根本就不是一個工種，而是兩個工種

近幾年的技術(shù)發(fā)展和生態(tài)建設(shè)，都是圍繞如何讓『應(yīng)用開發(fā)者』做好自己的工作，取得了很大進步，現(xiàn)在的問題是，不能把這套東西照搬給其他工種，同時也不能只是維持他們過時的工作方式，需要提供新工具，讓他們?nèi)谌氲健含F(xiàn)代 Web 開發(fā)』的新范式中

Brad Frost 指出其中一個工具就是現(xiàn)在發(fā)展相對成熟的『UI 組件』，我們可以對組件做分層，把偏視覺、交互、內(nèi)容、可訪問性的這一層交給其他分工去產(chǎn)出，成為『可消費的 UI 組件』，這種組件可以成為『大分裂』中的橋梁

現(xiàn)代 Web 開發(fā)的發(fā)展，也在為這種新分工、新工具提供支持，前面提到的 Gatsby 之所以能成為主流解決方案，拿到大筆融資，很大程度上是因為它體現(xiàn)了 Content Mesh 這個趨勢，可以翻譯成『內(nèi)容網(wǎng)格化』或『網(wǎng)狀內(nèi)容』

在傳統(tǒng) Web 開發(fā)喜歡采用的 CMS 架構(gòu)中，數(shù)據(jù)、內(nèi)容編輯、內(nèi)容展現(xiàn)、業(yè)務(wù)邏輯、托管交付，都是混在一起的，必須用一套方法來提供，就好像用了 Wordpress，技術(shù)棧和部署托管都避不開 php，客戶端部分也必須基于 Wordpress 主題

而在現(xiàn)代 Web 開發(fā)里，每個不同的部分都有各自最合適的解決方案，其中很多都有可復(fù)用的、更專業(yè)的服務(wù)，類似大陸常說的『中臺』的概念，只不過這些『中臺』不僅限于在大型企業(yè)內(nèi)部復(fù)用，而是面向公開市場提供服務(wù)

比如表單問卷需求可以用 BaaS 服務(wù) TypeForm 解決，用戶授權(quán)鑒權(quán)可以用 BaaS 服務(wù) Auth0，圖文內(nèi)容可以直接用 Markdown，支付可以用 Stripe，所以現(xiàn)代 Web 開發(fā)中的應(yīng)用，不是一套技術(shù)解決方案，是多種混搭在一起的，在每個問題上，都應(yīng)該能用最合適的方案和工具

雖然是混搭，但從架構(gòu)上看，發(fā)展趨勢是簡化成兩大塊：

一塊是現(xiàn)代 Web 應(yīng)用本體

一塊是 Serverless 平臺，其中又可以簡化為兩大塊：『交付云』和『后端云』

『交付云』支持靜態(tài) Web 部署，支持邊緣計算，也可以支持 SSR 部署，SPR 部署等

『后端云』由 BaaS + FaaS 組成，既可以取代現(xiàn)代 Web 項目中的 BFF 部分，簡化開發(fā)，也可以直接取代很多微服務(wù)的開發(fā)需求，而 GraphQL API 可以讓它的能力和適用面大幅增強

在字節(jié)跳動，前端工程師的服務(wù)器端開發(fā)工作已經(jīng)越來越多的在『后端云』上完成，不再需要自己開發(fā)部署運維 Node.js 服務(wù)

現(xiàn)代 Web 應(yīng)用的本體中，核心是『應(yīng)用架構(gòu)』，假如一個 Web 項目只有 React 組件代碼，它就只是一個 UI 和內(nèi)容展現(xiàn)，正是因為加上了『應(yīng)用架構(gòu)』，才從 UI 和內(nèi)容變成了 GUI 軟件應(yīng)用，后面還會提到『應(yīng)用架構(gòu)』里應(yīng)該有哪些東西

最后我們再看 UI 組件這個部分，經(jīng)過這些抽象之后，相當大的一部分 UI 組件都可以成為前面說的『消費型 UI 組件』，可以由外部提供

要讓其他分工可以更高效的獨立提供這些 UI 組件，需要進一步的工具支持

直接讓這些同學(xué)使用依賴管理、編譯工具、CLI 工具等面向軟件開發(fā)工程師的工具鏈，是門檻很高、很痛苦的，所以我們需要從圖上的『語言和框架』這個點之后開始提供工具

首先是 CASE 工具（Computer Aided Software Engineering，也就是『計算機輔助軟件工程』），把工程和軟件設(shè)計中的最佳實踐、數(shù)據(jù)可視化和常用操作，封裝到圖形界面、免安裝的工具里，屏蔽底層技術(shù)細節(jié)的復(fù)雜性

更進一步是提供低代碼工具（Low-code），讓有些工作不需要寫代碼也能完成

從這里開始，就已經(jīng)進入了前面說過的『設(shè)計工具』的范疇，開始同時解決『大困境』問題，我們這里提供的不再是傳統(tǒng)上基于圖像的設(shè)計工具，不再是只能設(shè)計出『效仿』最終產(chǎn)品的輸出物，不再需要『在設(shè)計和開發(fā)之間架設(shè)橋梁』，而是把代碼作為『唯一權(quán)威來源』，讓各個分工都圍繞著代碼來協(xié)作

最理想的解決方案是提供無代碼工具（No-code），即使不懂技術(shù)、寫不了任何代碼，也能融入到工作流中

在這個方面，游戲開發(fā)作為一種垂直領(lǐng)域的應(yīng)用軟件開發(fā)，比通用的應(yīng)用軟件開發(fā)要領(lǐng)先數(shù)年，游戲設(shè)計師可以用『關(guān)卡編輯器』這樣的工具，低代碼或無代碼的產(chǎn)出最終產(chǎn)品的代碼，跟工程師寫的代碼無縫集成，所有分工都圍繞著同一套最終產(chǎn)品的代碼來協(xié)作

現(xiàn)代 Web 開發(fā)要實現(xiàn)像游戲開發(fā)領(lǐng)域這樣高效、順暢的工作流，趨勢上一定會發(fā)展出像游戲引擎一樣的工具套件，形成新的分工模式，所有分工都圍繞著同一套工具、同一套代碼來協(xié)作

我在字節(jié)跳動負責的 Web Dev Engine 部門，就在專門推進這方面的工作，套件中的 Meta-framework 部分，跟我們要看的第二個趨勢有關(guān)

第二個趨勢解決的是『開發(fā)者體驗』（DX）和『用戶體驗』（UX）之間關(guān)系的問題

大家都很熟悉『庫』的概念，JS 擁有所有語言中最龐大最繁榮的 npm 生態(tài)，有海量的『庫』可以在我們自己寫的代碼里調(diào)用，這些庫通常會專注于單一目的，提供強大靈活的 API，在實現(xiàn)目的的同時，滿足需求和場景的各種變化

這些庫提供的是單塊積木，可以自由組裝成我們想要的樣子

而『框架』是另一種類型的基礎(chǔ)生態(tài)，可以說一個現(xiàn)代 web 應(yīng)用的框架，就是應(yīng)用本身，框架不是積木，而是很多底層積木組裝出來的整個拼圖，只是需要在特定位置或環(huán)節(jié)，插入我們自己寫的代碼或提供配置，滿足特定需求

無論庫還是框架，如果要把 DX 和 UX 同時做到最優(yōu)，組裝、配置、開發(fā)工作都會變得很繁瑣低效，大量注意力不能放在真正的業(yè)務(wù)需求上，而是被庫和框架的底層技術(shù)細節(jié)占用，由于成本高，相關(guān)的基礎(chǔ)建設(shè)也很容易在技術(shù)選型和排優(yōu)先級的時候被忽略或推遲

這是 JS 生態(tài)在主流問題域里的積木穩(wěn)定之后，面臨的一個主要問題，Meta-framework（元框架），也就是『框架的框架』，正是為此而生

接下來我們看幾個元框架功能上的趨勢

第一個功能是支持『混合語言開發(fā)』

近年來非常明顯的趨勢是，TypeScript 已經(jīng)成為主流語言，TypeScript 雖然解決了很多重要問題，但現(xiàn)代 web 開發(fā)領(lǐng)域中還有很多問題，解決方案都在 TypeScript 社區(qū)之外，由于以前 TypeScript 社區(qū)跟 JS 社區(qū)是有些割裂的，所以有人形容用 TypeScript 做項目是要交 『TypeScript 稅』的，比如無法使用 JS 生態(tài)中的某些方案，總體來算，ROI 甚至可能是負的

TypeScript 官方自己也能認識到這個問題，開始積極跟 JS 社區(qū)融合，比如廢棄 TSLint 項目，跟 ESLint 合并，為 Babel 開發(fā)語法插件支持 TypeScript 編譯等

我們看近兩年來的使用數(shù)據(jù)，Babel 的 TypeScript 插件增長速度基本跟 TypeScript 本身一樣，ESLint 的 TypeScript 解析器即將超過 TSLint，而 Babel 不但使用量比 TypeScript 大，增長速度甚至更快

所以在現(xiàn)代 Web 開發(fā)的項目中，JS 和 TS 正在融合過程中，不可能完全排除其中一種，甚至很多時候需要混用

混合語言開發(fā)的需求的增長，同時受到了來自 DX 和 UX 兩個方向的驅(qū)動，比如：

需要考慮到 Node.js 特有的一些語言特性（DX 驅(qū)動）

需要用 Rust 開發(fā) CPU 敏感的模塊生成 WebAssembly 集成到項目中（UX 驅(qū)動）

需要在局部模塊引入 Reason/OCaml 的函數(shù)式編程能力（DX 驅(qū)動）

等等

元框架可以隱藏混合語言開發(fā)的復(fù)雜性，推動最佳實踐的普及

第二個功能是 CSS 開發(fā)解決方案

CSS 開發(fā)的發(fā)展趨勢就像圖上時間軸中列舉的這樣，是從『面向文檔』向『面向組件』發(fā)展，『面向組件的 CSS』是一種同時改進 DX 和 UX 的模式，在給 CSS 帶來完善工程能力的同時，能生成盡可能高效的 CSS 靜態(tài)文件

CSS Modules、styled-components、Functional CSS，這三個方案表面上看差別很大，一個是預(yù)編譯 CSS 文件，一個是 CSS in JS，一個是全局的 utility class，但本質(zhì)上這三個方案都是在實現(xiàn)『面向組件的 CSS』

如果我們把 Functional CSS 提供的 utility class 看成組件的名稱和屬性，添加一個 class name 就像把組件上的同名屬性設(shè)成 true，那么它跟 styled-components 沒有本質(zhì)區(qū)別，在真實項目中，混用這兩種方案的收益最大

從今年的 CSS 普查報告上，也能看到 Functional CSS 的流行

第三個功能是對 monorepo 的支持

monorepo 這種模式目前還主要用在庫的開發(fā)中，比如 Babel 這樣有大量子項目的倉庫，但其實現(xiàn)代 Web 開發(fā)中的多數(shù)項目，都能從中受益

比如幻燈片上是我們團隊的倉庫，同一個產(chǎn)品的多個組成部分，比如多個 SPA 應(yīng)用、多頁網(wǎng)站、落地頁和活動頁，可以在一個倉庫里共享工程環(huán)境，方便的復(fù)用代碼，而 BFF 的開發(fā)也可以在同一個倉庫，跟客戶端共用一些代碼

第四個功能是對微前端的支持，微前端正好是一種兼顧 DX 和 UX 的設(shè)計模式：

在用戶體驗這邊，可以做到完全無感知無差別，仍然是一個完整的 SPA 應(yīng)用

第一屏無論包含多少微前端，都可以通過 SSR/SPR 和邊緣計算提供最好的加載速度和體驗

而第一屏不包含的微前端，可以按需加載，不會影響跟自己不相關(guān)的其他微前端

不同微前端之間可能彼此獨立，也可能有數(shù)據(jù)交互，需要打通應(yīng)用狀態(tài)

以上用戶體驗雖然都能夠?qū)崿F(xiàn)，但如果沒有元框架的支持，成本會比較高，容易顧此失彼，解決方案之間的不一致也會影響效果

在開發(fā)者體驗這邊，恰好可以為前面說的「垂直分工模式」提供支持，不是由同一個項目同一批前端開發(fā)者來負責所有業(yè)務(wù)、所有不同類型需求的前端部分，而是每個業(yè)務(wù)、每個垂直領(lǐng)域有自己獨立的團隊（或開發(fā)者）負責，開發(fā)環(huán)境、開發(fā)過程、部署流程等完全彼此獨立自己掌控，但最終交付給用戶的時候仍然是一個完整單一體驗的應(yīng)用

第五個功能就是前面說過的「應(yīng)用架構(gòu)」

初級的現(xiàn)代 Web 項目只是在視圖層之外增加了應(yīng)用狀態(tài)管理，比如 React 社區(qū)中主流的 Redux

但 Redux 實際上是一種「底層 API」，主要提供「機制」，并不提供「架構(gòu)」的設(shè)計和實現(xiàn)，「架構(gòu)」本身是一種頂層抽象，而 Redux 恰好是缺乏抽象的

近年社區(qū)里流行的「Rethinking Redux」、「Replacing Redux」的根源之一其實也是這個問題

元框架無論是否借助上游項目，都要負責提供頂層抽象，比如 Component、 Model、Container 鐵三角加上 App 入口，既為開發(fā)者提供開箱即用的應(yīng)用架構(gòu)，反過來也掌握了關(guān)于應(yīng)用項目代碼的「架構(gòu)知識」，能從抽象角度理解代碼，進一步提供有利于 UX 和 DX 的能力

元框架還可以從更高的項目視角來看待「應(yīng)用架構(gòu)」，結(jié)合框架其他部分提供更強能力，比如把項目入口的運行和部署方式、微前端模式和基礎(chǔ)設(shè)施跟應(yīng)用架構(gòu)打通

第六個功能可以稱作「智能助手」

軟件開發(fā)方式已經(jīng)經(jīng)歷了「基于文本」和「基于結(jié)構(gòu)」兩個發(fā)展階段，在第一階段，開發(fā)工具能理解和處理的是文件、行和文本流，第二階段，開發(fā)工具能更多的把代碼理解為結(jié)構(gòu)化的信息

當前正在發(fā)展中的「第三階段」是「基于智能」，開發(fā)工具能更智能的理解代碼、查看代碼和生成代碼，最終會趨向于一個「智能助手」，我們做開發(fā)的過程越來越不再是直接用源代碼跟機器打交道，而是跟「智能助手」溝通，獲得最好的 DX，智能助手再去跟機器打交道，實現(xiàn)最好的 UX

這種范式轉(zhuǎn)變已經(jīng)在發(fā)生，如果在開發(fā)流程中引入了 Prettier，你手寫的代碼就不再是源代碼本身，而是用來跟 Prettier 溝通的代碼，最終保存在硬盤上，提交到倉庫的源代碼，是 Prettier 重新「寫」出來的

ESLint 社區(qū)也把 autofix 作為最重要的發(fā)展方向來推進，能自動修復(fù)的規(guī)則已經(jīng)越來越多，但是跟 Prettier 相比還是有范式上的差別：

幻燈片上有一個例子，如果設(shè)置了 80 字符的最大行寬，ESLint 和 Prettier 都能修改代碼自動換行，但經(jīng)過 ESLint 自動修復(fù)后，代碼還是可以有多種寫法，只有不觸發(fā) ESLint 規(guī)則報錯就行，而 Prettier 處理后的代碼只可能有一種寫法，因為代碼是它「寫」的

所以 Prettier 以及「智能助手」是一種「有偏見」的范式，對于 Prettier 怎樣「寫」代碼，開發(fā)者的話語權(quán)很少（能配置的地方很少），如果你先憑空寫好一套代碼規(guī)范，再用 Prettier 來實現(xiàn)，是不可能的。但正是這種「偏見」才能給 DX 和 UX 同時帶來最大化的收益

「智能助手」的發(fā)展需要一個過程，在這個過程中，最佳實踐是把新舊范式整合在一起使用，隨著相關(guān)工具的進步，逐步在越來越多的地方把舊范式切換成新范式

比如使用 Prettier 的最佳實踐就是把它作為規(guī)則插件整合在 ESLint 中，跟 ESLint 的 autofix 一起執(zhí)行，對于所有 Prettier 能決定怎么寫的代碼問題，相關(guān)的 ESLint 規(guī)則都失去意義，要關(guān)掉。隨著「智能助手」的能力越來越強，需要關(guān)掉的 ESLint 規(guī)則也越來越多，直到完全不需要 Lint

「智能助手」的使用應(yīng)該是基于即時反饋的，因此這種范式最佳的使用場景是在開發(fā)環(huán)節(jié)，而不是在編譯構(gòu)建、提交倉庫、CI/CD 等環(huán)節(jié)

幻燈片左側(cè)是 VSCode 相關(guān)配置的最佳實踐，每次保存代碼都是跟智能助手的一次「溝通」，立刻看到它生成的代碼，在這些代碼基礎(chǔ)上繼續(xù)再做「溝通」，這樣的過程是符合直覺的，不會帶來「驚喜」，也不會有失控感

幻燈片右側(cè)是另一個最佳實踐，可以稱作「全量規(guī)則集」：

傳統(tǒng)上使用 ESLint 的方法是「白名單」模式，我有哪些代碼規(guī)范上的需求，就開啟和配置哪條規(guī)則，

而「智能助手」范式是「黑名單」模式，默認開啟所有規(guī)則（包括ESLint 核心和所有主流插件），對于沒有偏好或根本還沒聽說過的規(guī)則，都使用主流推薦配置，只把自己了解且明確不想用的規(guī)則關(guān)掉

這種「全量規(guī)則集」跟 Prettier 一樣可以提供最大化的「約束」和「偏見」，給 DX 和 UX 帶來最大化的收益

第七個功能是對設(shè)計系統(tǒng)的支持

設(shè)計系統(tǒng)不止要提供「組件庫」，還需要提供組件之間的關(guān)系（包括組件的用法，設(shè)計規(guī)范等等）

用 Atomic Design 的概念來說，不可拆分的「原子組件」、以及由「原子組件」組合成的「分子組件」，共同構(gòu)成「組件庫」，但整套系統(tǒng)還包含了建立在組件庫之上、包含組件之間關(guān)系的「有機體」

在設(shè)計系統(tǒng)成熟的情況下，前面說過的「可消費 UI 組件」主要都會是「有機體」

元框架需要為「有機體」的開發(fā)和使用提供支持

近年來，設(shè)計系統(tǒng)的設(shè)計和實現(xiàn)中開始流行 Design Token 的概念，就是發(fā)現(xiàn)「原子組件」并不是不可拆分，可以由作為更小單位的一系列變量取值來組成，換一套不同的取值，設(shè)計系統(tǒng)就能支持不同的視覺風格和品牌形象，既降低開發(fā)成本，也提升用戶體驗

第三個趨勢是 Web 形態(tài)的一個發(fā)展方向

今天的互聯(lián)網(wǎng)技術(shù)是 80 年代設(shè)計的，這套技術(shù)非常簡單成功，但因為缺少一些重要元素，導(dǎo)致今天的互聯(lián)網(wǎng)面臨很多難以解決的問題

其中一個重要缺失就是沒有「持有狀態(tài)」和「轉(zhuǎn)移狀態(tài)」的原生機制，導(dǎo)致狀態(tài)只能存儲在少數(shù)中心節(jié)點，由這些節(jié)點在黑箱中處理狀態(tài)轉(zhuǎn)移

于是互聯(lián)網(wǎng)越來越「多中心化」，從開放互聯(lián)的狀態(tài)，收斂成少數(shù)幾個中心，由不同的科技巨頭控制，彼此難以聯(lián)通或直接敵對，前面提到的對科技巨頭產(chǎn)品的不信任也由此而來

用戶對自己的個人數(shù)據(jù)（狀態(tài)的一種）缺乏掌控，無法參與由數(shù)據(jù)產(chǎn)生的越來越多財富的分配，缺少激勵或補償，減少了在生活中使用互聯(lián)網(wǎng)產(chǎn)品的積極性（大陸很多面向下沉市場的產(chǎn)品會人為提供游戲化的激勵或補償，因此能飛速增長），同時因為對黑箱缺乏信任，也進一步降低了積極性，或人為增加監(jiān)管和限制。

這種扭曲最終反噬互聯(lián)網(wǎng)產(chǎn)品和科技公司，讓他們難以為用戶創(chuàng)造價值，也就是說，這個話題看上去很大，但是跟現(xiàn)代 Web 開發(fā)者是有關(guān)系的

所以 Web 形態(tài)的發(fā)展，有很大動力引入像智能合約和區(qū)塊鏈這樣的架構(gòu)和范式上的轉(zhuǎn)變

圖中是新范式的一個例子，現(xiàn)代 Web 應(yīng)用的后端不再是中心化的服務(wù)器端 API，而是部署和運行在區(qū)塊鏈上的智能合約 API，狀態(tài)存儲在去中心化基礎(chǔ)設(shè)施（區(qū)塊鏈）上，由去中心化程序（智能合約）負責狀態(tài)轉(zhuǎn)移，這個現(xiàn)代 Web 應(yīng)用也就成為了去中心化應(yīng)用（DApp）

對現(xiàn)代 Web 開發(fā)來說，這種范式轉(zhuǎn)變不但不會顛覆當前的發(fā)展和積累，反而會促進原有的趨勢更快發(fā)展

比如基于智能合約的應(yīng)用架構(gòu)就是一種 Serverless 架構(gòu)

但是產(chǎn)品的形態(tài)和機制會有很大改變

最后講一個案例

開頭部分的幻燈片提到過，我做過的產(chǎn)品里，最喜歡是 2011 年在豆瓣做的阿爾法城 2.0，這是一個讓線上的興趣社群像城市空間一樣有地理關(guān)系，根據(jù)用戶行為自然生長的新形態(tài)社區(qū)產(chǎn)品，有 2D Metaverse（虛擬世界）的形態(tài)

向 Immersive Metaverse （3D 沉浸式虛擬世界）發(fā)展也不難

這個產(chǎn)品的開發(fā)只持續(xù)了一年，團隊就解散了，運行四年后下線

失敗的原因之一是：用戶方想要的，企業(yè)和產(chǎn)品方想要的，兩者之間有距離。就好像你想給用戶 A，結(jié)果只做到了 B，而 B 的用戶在使用過程中真正想要的是 C，但你只想要 A，所以把 B 關(guān)了

這里面有一個嚴重問題是：用戶決定不了任何事情

用戶像開發(fā)團隊一樣，在產(chǎn)品中投入了時間、注意力、技能、情感，創(chuàng)造了價值（UGC），但即使在這樣一個主打「自然生長」的產(chǎn)品里，用戶決定不了自己貢獻的數(shù)據(jù)何去何從，決定不了自己喜歡的產(chǎn)品功能的命運，決定不了產(chǎn)品的走向和生死

正在演化中的新一代 Web 技術(shù)和市場環(huán)境，已經(jīng)提供了比阿爾法城那個年代更好的條件和手段來解決這些問題

我相信在 Web 上創(chuàng)造出新世界的那一天距離現(xiàn)在并不遙遠

如果你對以上問題有興趣，想直接穿越到它們發(fā)展完善的那一天，或是想體驗親手把它們發(fā)展完善的過程，甚至感受到使命感，歡迎加入字節(jié)跳動的 Web Dev Engine 部門一起努力，目前我們的 8 個虛擬團隊由來自北京、上海、深圳、廈門的同學(xué)組成，而字節(jié)跳動在大陸主要城市和全球很多地方都有研發(fā)中心，總有一個地方適合你加入我們 XD，可以掃二維碼提交簡歷或直接聯(lián)系我