到底什么是 Web？要回答這個問題，需要先理解 Web 的三要素：

Web Runtime

前端技術

URL

1.1 Web Runtime

第一個核心要素是「Web Runtime」，基于 Web 的內容或應用，本質上都是一種用高度抽象的方式來實現、分發和運行的客戶端軟件，需要建立在一個非常 high level 的軟件抽象層（abstraction layer）上，這個抽象層就是「Web Runtime」。

提供「Web Runtime」的客戶端技術，可以分為這么四類：

傳統瀏覽器：一種應用層的 Web 平臺，在桌面平臺上是主流，比如 Chrome、Safari、Edge。

PWA（Progressive Web App）：基于 OS 層的 Web 平臺，在全球是主流，比如 YouTube 的桌面應用和 Premium 離線訪問、BBC 的 UAP 等。

WebView：在 OS 層提供的 Web 能力 API，在移動平臺上是主流，比如 iOS 的 WKWebView、Android 的 WebView、Windows 的 WebView2。

跨端（Hybrid）容器：在應用層提供的 Web 能力 API，在國內是主流，比如小程序、Kun、Weex 等技術。

在傳統瀏覽器里，「Web Runtime」被稱作「瀏覽器引擎」，由于 2D 互聯網中的瀏覽器傳統上主要用來渲染帶交互能力的 2D 圖文內容，所以「瀏覽器引擎」也經常稱作「渲染引擎」。

1.1.1 瀏覽器

瀏覽器引擎對用戶來說是「無形的」，像是一副展示內容或軟件界面的「空白畫布」，用戶能感知到的「有形的瀏覽器」相當于是「畫框」，是地址欄、收藏夾、標簽頁這些用戶使用 Web 的「輔助工具」。

「有形的瀏覽器」可以是其他的形態，提供不同的「輔助工具」，不一定有地址欄，比如：

1、Visual Search 應用（比如 Google Lens、Snapshot、抖音）：用攝像頭畫面替代地址欄，用視覺搜索（基于 CV、AR 技術）來找到要訪問的 Web。

2、Chatbot 應用（比如微信、飛書、Messenger）：用聊天對話窗口替代地址欄，通過指令或自然語言（NLP）對話來找到要訪問的 Web（以卡片形式推送到對話信息流中）。

3、信息流應用（比如今日頭條、微博、Facebook、Twitter）：通過信息流的推薦算法來訪問 Web。

對于以上三種類型，Snapchat 的 Snap Minis 是一個典型案例

用戶跟好友互動的地方，就是 Mini 運行的地方（對話信息流、相機鏡頭）。

Mini 基于 Web 的 HTML5 和 JS 技術，創建一個 Mini 就像構建一個 HTML5 網站，能用來實現從小工具到實時社交游戲的各種應用。

4、Web OS（比如 Chrome OS）：像獨立原生應用一樣，在 OS 的應用商店、全局搜索等地方找到 Web 應用，「安裝」到 OS 的 dock 上，點擊應用圖標打開對應的 Web 應用。

5、其他超級應用或跨端容器應用（比如美團、Google Maps、…）：通過黃頁導航、地圖上的 POI 等各種方式來找到要訪問的 Web。

我們平時說的「瀏覽器」專指那種有地址欄的傳統瀏覽器應用，是延續了桌面平臺的習慣和理解，因為在桌面時代，這種形態的瀏覽器幾乎是唯一的「超級應用」。

從移動互聯網時代開始，它們就已經不再是唯一的「瀏覽器」了（不是唯一提供 Web Runtime、提供 Web 應用平臺能力的超級應用）。

以上五種應用形態本質上都是瀏覽器，其中有的就是更現代的瀏覽器，有的是為垂直領域做專門優化的瀏覽器。

Web Runtime 本身（「畫布」部分）就是一個最基本的「Web 平臺」。

以上這些提供 Web Runtime 的平臺級軟件（Chrome、Chrome OS、微信、頭條、飛書們），也都是「Web 平臺」，它們在「畫布」基礎上增加了各自的「畫框」部分，形成了更實用的、更貼近業務領域和用戶群體的「Web 平臺」。

反過來說，一個平臺越是跟 Web Runtime 緊密結合，就越具備「Web 平臺」的能力和特點（比如 Chromebook 相對于同樣在系統層面集成了瀏覽器引擎的 iPad）。

1.1.2 應用平臺

Web Runtime 作為最基本的「Web 平臺」，是一種標準化（稱作「Web 標準」）的軟件應用平臺，隱藏了更下層軟件平臺的差異（比如不同硬件、不同 OS、不同底層 API），提供了跨平臺的、抽象程度更高的、開發成本和門檻通常都更低的軟件開發能力。

傳統 Web 是以超文本文檔（可交互的 2D 圖文）內容為中心的。

HTML 這樣標準化的「標記語言」（負責實現內容和結構），加上 CSS 這樣的「樣式聲明語言」（負責實現外觀），是這種軟件開發能力的核心。

Web Runtime 為此提供：

布局引擎：按照 Web 標準，把 HTML 從純文本，解析成文檔節點對象（DOM 對象）組成的樹狀數據結構（稱作 Content Tree），結合 CSS 中的聲明，生成由矩形（盒狀模型）組成的樹狀數據結構（稱作 Render Tree 或 Frame Tree），經過自動布局（Layout，也稱作 Reflow，簡單的情況下相當于做圖文排版），最后「繪制」（Paint）出網頁內容。

網頁內容由各種媒體形式組成：純文本、「超文本」（包含鏈接的文本）、圖片、視頻音頻、動畫等

網頁內容的默認交互行為：鏈接和錨點的跳轉，表單輸入和提交

https://web.dev/howbrowserswork/

如果 Web Runtime 僅限于這種能力，就只是一種內容閱讀器或播放器（雖然這方面能力也很重要）。

但在現代的 Web 開發中，不僅不止這方面能力，而且這部分能力由于抽象程度太高、太垂直化（原本是為「內容」開發而設計的）、不夠靈活強大、不一定適應「應用」開發的需求，經常被邊緣化或隱藏。

更現代的 Web 是以程序語言為中心的。

軟件開發能力的核心是 JS（JavaScript） 和 WebAssembly 這兩種標準化的 Web 原生語言。

JS 側重「生產側」和「DX（開發者體驗）」

用于業務需求的實現。

JS 還包含 TypeScript 等變體。

WebAssembly 側重「消費側」和「UX（用戶體驗）」

用于性能優化、跟底層打交道和非 Web 程序的移植。

Web Runtime 中為此提供：

JS 引擎：能標準化的執行 Web 原生語言的虛擬機，讓語言既可以做計算，也可以調用 Web API

內部包含實時編譯成原生機器代碼、根據運行結果自動優化代碼、垃圾回收等能力。

宿主環境：不斷運行著事件循環，通過各種事件（比如頁面加載、鍵鼠點擊、XR 設備交互）來驅動 JS 引擎中的 Web 程序

Web API：宿主環境也提供可被編程語言調用的、標準化的 API，讓 Web 程序能實現各種：

「輸入」功能：監聽人機交互事件、監聽網絡通信事件、監聽本地讀寫事件等

「輸出」功能：UI 布局、動畫、2D 或 3D 的圖形渲染、音頻視頻、本地存儲、網絡通信等

為了理解 Web Runtime，還必須同時理解里面跑的 Web 應用：

1.1.3 Web 應用

為了避免「Web 應用」這個詞跟下文中狹義的「Web App」混淆，在下文里改稱為「Web 軟件」。

標準化的 Web 軟件在分發的時候，是一堆不同格式的 Web 文件，可以被 Web Runtime 通過標準化的網絡、用標準化的方式按需獲取，再標準化的解析和運行。

Web 文件包括：

HTML 文檔：類似一個容器，可以承載內容和代碼

這種「文檔」文件需要獨立于 Web 軟件的版本，能自主變化，比如：

更新內容

對不同用戶提供不同內容

把代碼更新到不同的 Web 軟件版本

靜態文件：在同一個 Web 軟件版本中保持不變。包括：

代碼文件：會被 Web Runtime 解析和運行。

JS 文件、WASM 文件（WebAssembly 代碼）、CSS 文件

資源文件：會被文檔和代碼使用到。

圖片、字體、視頻、音頻、數據等。

Web 軟件包括

標準化的 Web 軟件

獨立網頁：

側重「內容」

沒有子頁面（比如很多 H5 營銷活動只有一個頁面）。

多頁網站：

側重「內容」

由多個頁面組成，通過鏈接組織到一起（這里說「頁面」是業務和用戶體驗上的概念，不是技術概念，所以并不一定對應到 HTML 文檔）。

Web App（狹義）：

側重「功能」，更類似應用軟件

組織的粒度可以比頁面更細。

PWA（Progressive Web App）：

Offline First、可安裝的 Web App。

運行在瀏覽器中，但在外觀和用法上可以獨立于瀏覽器。

既能實現跟獨立原生應用一致的體驗，也能保持 Web App 的獨特能力（具體能力見后文）。

以上全是通過完全標準化方式實現。

非標準的 Web 軟件

跨端界面（HybridUI）：

原生客戶端里基于 Web 技術的界面。

通常運行在客戶端的 WebView 里（這種 Web Runtime 是標準化的，但客戶端經常會在標準基礎上做非標準的自定義擴展）

也有的會以完全非標準的方式運行（比如運行在非標準的 Runtime，也就是「跨端容器」里，比如部分或全部以原生方式運行）

分發方式經常是非標準的（比如打包在客戶端里、用自定義方式下發）

通常跟特定產品的客戶端需求、非標準化的客戶端能力綁定在一起，無法獨立使用

典型例子有端上內嵌 H5 界面、小程序。

打包應用（Packaged App）：

類似 Hybrid UI，但不是單一界面，整個 Web App 都運行在基于原生客戶端技術的容器里，只不過這個容器是通用的「空殼」，本身不含業務邏輯，只負責給 Web 軟件：

提供能力（包括標準化的能力，和在標準基礎上增強的非標準能力）

也有的打包應用會完全編譯成原生應用。

標準化的 Web 軟件需要運行在瀏覽器里，或運行在其他跟瀏覽器一樣具備完全標準化 Web Runtime 的客戶端里（如前文所述，這種客戶端實際上已經是一種瀏覽器，只是形態和功能跟傳統瀏覽器不同）。

PWA 在「標準化的 Web 軟件」中具備獨有的能力，能「看上去」獨立于瀏覽器、像獨立應用一樣安裝和運行。

標準化的 Web 軟件都一定具備全部 Web 的獨特能力（具體能力見后文）。

非標準的 Web 軟件完全獨立于瀏覽器，運行方式通常有非標準的部分，或是完全非標準。分發方式通常完全非標準。

非標準的 Web 軟件不具備很多 Web 的獨特能力。

注意上圖的含義：「標準化的 Web 軟件」在分發、實現、運行這三個環節一定都必須是「標準」的，而「非標準的 Web 軟件」可以在這三個中的任一環節引入「非標準」，也就是說，「非標準的 Web 軟件」并不一定在所有環節都是「非標準」的，可以在某些環節保持「標準」。

1.1.4 標準化

可以看到 Web Runtime 的本質和關鍵在于：

以上描述的所有架構設計

方方面面的標準化

這種架構設計帶來了 Web 面向 end user、面向開發者的很多能力（其中很多能力是獨有的，見后文），而標準化確保了這些獨特能力在不同平臺上的一致性，這種跨平臺一致性本身也是 Web 獨特能力的核心部分。

包含架構設計在內的這些標準化，并不是教條和瓶頸，可以圍繞業務需求，有選擇的、務實的做 trade-off 做取舍，引入非標準。但由于會損失 Web 獨特能力，必須能換來更大的利益，才值得去搞非標準，而且最好是在一個逐步通向或兼顧標準化的長期戰略中去搞非標準。

1.2 前端技術

第二個核心要素是「前端技術」。

「Web Runtime」強調的是「消費側」（應用的運行和使用）的 Web 技術，「前端技術」強調的則是「生產側」（應用的開發實現）的 Web 技術。

前端技術幾乎是在 Web Runtime 之上做開發所必須的壟斷技術（一些來自其他技術棧的、小眾的或歷史遺留的解決方案和開發場景除外）。

反過來說，前端技術又不等同于 Web Runtime 的開發技術，也不等同于做 Web 應用的技術，而是一個可以說包羅萬象無所不能紛繁復雜的大雜燴。

1.2.1 起源和分裂

雖然是大雜燴，前端技術仍然可以追溯到兩個根本的古老起源：

1、編寫和維護符合 Web 標準的超文本文檔的技術。

來自這個起源的后續發展，更側重「內容」場景，更關注結構語義、外觀、視覺效果、UI、UX。這個方向的前端開發者，更趨向 Designer 和創意內容制作者。

?

2、基于 Web 標準中涌現的兩類重要 API（異步讀寫數據的 API、操作文檔對象的 API）實現和維護「富 Web 應用」的技術。

來自這個起源的后續發展，更側重「功能」場景，更關注業務復雜性、代碼復雜性和開發效率，也因此專注于代碼復用、應用架構、工程化和基礎建設。這個方向的前端開發者，更趨向軟件工程師和應用開發者。

區分這兩個方向的技術、開發者需求與偏好，是很重要的。如果搞混或以偏概全，就很容易誤解 Web 技術和 Web 場景。

1.2.2 吞噬世界

更新：注意「吞噬世界」和下面的圖都是業界老生常談的梗，不是我生造的，放在這里含調侃意味。如果你之前沒見過，可以爬一下我標注的鏈接，擴大下視野。

前端程序最初不是一種獨立的應用程序，而是以服務器端為中心的 Web 程序中的「前端部分」（所以現在仍然延續習慣稱作「前端」）。能力很有限，技術需求也簡單。早期很多前端開發者寫的都不是真正的、產品級的代碼，而是跟設計師一樣做「假」的輸出物（比如模擬實際效果的網頁），交給「真正」的程序員和產品開發者去改寫成真正的、產品級的代碼。

只用短短幾年時間，前端技術就發展成了獨立的應用軟件開發技術，并且以大致每五年就換代的速度快速發展，不但在幾乎所有方面都追平了其他歷史底蘊深厚、有老牌大廠和獨占平臺支持的、成熟系統的軟件開發技術棧，還在很多方面跑到了更前面，被其他技術棧反向學習。

典型例子：

大家都在抄的 React：前端技術中演化出的 React 引領了 GUI 編程的變革，被 Apple、Google 等老牌 GUI 平臺廠商學習，支撐自己的次世代應用開發方案（SwiftUI、Jetpack Compose、Flutter、Omniverse UI）。

獨有的前后端一體化技術：前端技術能讓一個 Web App 成為同時跑在客戶端和服務器端（指客戶端 App 本身在服務器端跑）的一體化應用，能同時發揮 Web 客戶端和服務器端的優勢（比如實現「無限」大小的應用、利用邊緣計算技術等），這是其他 GUI 軟件技術都不具備的，想學都學不了。

強大的 JS 運行環境：JS 擁有業界性能最頂級、場景最多樣的運行環境，光是其他很多動態語言求而不得的工業級的、頂級性能的虛擬機就有好多個，在巨頭們（比如 Google、Apple、Microsoft、Facebook、三星）和各種開源組織（比如 Mozilla、Igalia、OpenJS）長年累月的重度投入下，引入所有新技術和奇技淫巧，讓最初為寫腳本而設計、身為動態語言的 JS，性能被強行抬高到靜態系統編程語言的水平，在服務器端、邊緣計算、跨端技術、物聯網、腳本環境等各種垂直場景都有專門打造的選擇。

https://zhuanlan.zhihu.com/p/453354202

如今前端技術棧和前端技術社區是最龐大的技術生態（包括最龐大的開源生態）。

前端技術是使用最廣泛、需求量最大的技術。

JS 開發者是最大的開發者群體，在全球所有軟件開發者中占比超過60%。

?

?

https://en.wikipedia.org/wiki/Jeff_Atwood

http://brendaneich.github.io/ModernWeb.tw-2015

https://twitter.com/lexfridman/status/1360373028912300040

前端技術在變強大的同時，也保持了直觀、輕量、抽象、高效、關注產品和用戶（面向人，而不是面向機器，obsessive customer focus）的開發體驗，以及更低的上手和實踐門檻。

典型例子除了前面說的最大開源生態的支持，還有一個是「即時反饋」：

修改了代碼，很快可以看到效果。

在有編譯構建環節的情況下，推送到真機做測試的過程也可以輕量簡單。

前端開發者對編譯構建等待時間更敏感、要求更高，社區在這方面不懈的優化改進。

免編譯或按需做增量編譯、自動推送、熱更新應用中有變化的部分，接近 Live coding 的體驗，是前端技術的慣例和文化。

很多時候可以實現真正的 Live coding，包括無編譯，直接運行。包括所見即所得的低代碼（Low-Code）開發方式。

1.2.3 底層邏輯

前端技術的這種「既要又要還要」的特點、目不暇接的發展速度和龐大生態，很大程度上是因為以下三個獨一無二的特點：

1、全行業實際需求推動

根本推動力并非像其他技術一樣，來自學術研究、文化理念或特定商業目標，而是完全來自互聯網全行業（特別是前沿行業）產品需求的發展，自己不想動都會被實際需求推著走。

前端技術是 Web（萬維網）的原生技術。跟整個互聯網產業緊密結合在一起，隨之一起不斷成長。

前端技術的發展，不斷為互聯網產品形態和商業模式，帶來可能性和進步，這反過來又促進了產品需求的發展被第一時間轉變成前端技術的完善和演進，彼此是正循環的關系。

2、標準化和開放

建立在 Open Web 技術（Web 標準）之上，這種技術是全行業在平臺技術上最大、最主要的交集和共識。

因此能得到幾乎所有大小企業和個人的采納、投資和實踐。

新的交集和共識要么以行業協作的形式，在委員會的主導下被謹慎嚴謹的添加到 Open Web 里，要么以 de facto（事實標準）的形式在實際應用中被快速落地、驗證和普及，最終被采納和融入到 Open Web 技術中。

3、抽象程度最高

JS 技術棧和 Web Runtime，都是位于最高抽象層級上的軟件技術，最接近終端用戶和產品需求，也最接近技術發展（本質是在不斷壘加抽象層）的前沿，需求變化最快，抽象程度高又帶來成本低，能專注于用戶和業務的需求。兩者加起來，就讓迭代發展達到最快。

反之，如果在有些領域里建設不足，導致抽象程度暫時不夠高，發展就會遲緩，比如在獨立移動應用開發領域，跟小程序、SwiftUI（從一開始就面向這個垂直領域的 high level 需求去設計）相比。

1.3 URL 的魔法和 Web 的獨特能力

第三個核心要素「URL」。

URL 全稱是「Uniform Resource Locator（統一資源定位符）」，中文里經常稱作「網址」、「地址」。它的本體是一段文本，長這個樣子：

Web 的獨特能力可以歸納為以下 8 個

分發能力

解綁能力

混搭能力

即用能力

動態能力

共創能力

跨平臺能力

協作能力

這些能力都是「Web 三要素」帶來的，其中 URL 起到了最多的作用。

1.3.1 真名魔法

如果把 Web 看成虛擬世界，URL 相當于世上一切事物的「真名」。萬事萬物都可以有獨一無二的「真名」。

這里說的有「真名」的「萬事萬物」，不僅包括嚴格意義上的網頁（HTML 文檔）、代碼文件、各種格式的媒體文件比如圖片視頻音頻、各種數據文件等「真實存在」的、「看得見摸著」的「資源」，還包括：

程序實時自動生成的「資源」

有些程序在不同條件下會生成不同的「資源」，有不同的「真名」，這種情況下，不同資源對應的「條件」會需要直接包含在「真名」里。

有些程序生成的「資源」，在不同條件下會發生變化，但仍然是同一個「資源」，只有一個「真名」。

Web 應用運行過程中的某個「狀態」比如：

Web 應用的初始狀態。相當于「入口」、「首頁」、「首屏」的「真名」。

Web 應用顯示某個功能界面或顯示某個內容時的狀態。相當于這個「功能」或「內容」的「真名」。

當顯示某個「內容」的「子內容」時，Web 應用進入的不同狀態。比如「子應用」從折疊變成展開、從屏幕外變成屏幕內。相當于這個「子內容」可以有自己的「真名」。

當在某個「功能」中抵達某個「中間環節」，或取得某種「結果」時，Web 應用進入的不同狀態。比如按引導完成了第一個步驟、在地圖里搜索了關鍵詞、在游戲里抵達了某個位置。相當于這些「中間環節」、「結果」都可以有自己的「真名」。

掌握了任何事物的「真名」，就對這個事物擁有了魔法般的力量：

可以「瞬間傳送」去訪問這個事物

如果這個事物是網頁資源，就會直接訪問這個網頁。

如果這個事物是 Web 應用的某個狀態，就會運行這個應用，「還原」或「直接跳到」到這個狀態。

如果這個事物是代碼資源、多媒體資源、數據資源，你可以直接查看這些資源的內容。

可以在 Web 代碼里「召喚」這個事物

如果這個事物是代碼資源、多媒體資源、數據資源，在滿足安全要求的情況下，可以不受限于它們的來源，用它們實現其他 Web 應用中不同的內容或功能。

如果這個事物是網頁資源，或Web 應用的某個狀態，在滿足安全要求的情況下，可以通過「爬蟲技術」抓取和解析到對應的內容和功能信息，用于其他 Web 應用，也可以直接把它們嵌入到其他 Web 應用。

可以在 Web 內容或代碼里開啟通往這個事物的「傳送門」

比如在發表的文章里引用其他 Web 內容的 URL。

比如把某個 Web 應用的狀態轉發到聊天群里。

可以通過在「真名」中做細微的調整，讓原本的事物「變化」成另一個事物

比如有些攝影平臺上的照片，你可以通過調整照片的 URL，把它變成不同尺寸、格式

比如你能訪問某個店鋪商品列表的第一頁，通常也能訪問它的第二頁、第一百頁（除非該店鋪不想讓你順藤摸瓜）

URL 的這些設計和能力意味著什么呢？

1.3.2 分發能力

首先，URL 的本質之一，是 Web 應用和內容的分發。

常說的「鏈接」，是「Hyperlink」的簡稱，在 Web 里的本意是指 HTML 里面對 URL 的引用。鏈接本質上也是分發入口。

對 end user 來說，無論 URL 還是鏈接，這種入口都不必保持「硬核」的文本形式。

可以是圖文并茂的卡片，在信息流、聊天窗口、推廣位、AR 鏡頭、圖文內容中出現。

可以是一種錨點，在視頻、鏡頭、圖片中出現。

可以作為一種可互動的對象，比如對話式卡片中的選項、按鈕，比如游戲中的門、水晶球、地磚、廣告牌。

可以是應用圖標，像原生應用一樣管理、搜索和打開。

?

?

越是現代的 Web 平臺設計，越趨向弱化和隱藏地址欄、URL 文本這類「硬核」細節，讓 Web 潤物細無聲的支撐起更直觀的用戶體驗。

不過產品設計中還是需要留出「逃逸口」，在有需要的時候可以獲取 URL 文本，否則不利于下文提到的用戶再利用。

1.3.3 解綁能力和混搭能力

URL 這種分發方式，是細粒度的，不是只能分發整個應用，可以分發里面具體的內容（比如一個用戶的 Profile），可以分發一個具體的功能（比如某份點到一半的外賣訂單）。

這也意味著 URL 的另一種本質：App Unbundling（應用解綁）。

Web 應用不像原生應用一樣以單一入口為主，要從最頂層的入口進入，一級一級深入進入各種內容和功能。

Web 應用是多入口為主的，很多內容和功能可以直達（所以設計的時候要提供上下文，不能假設用戶都是經過上層入口抵達這里）。

Web 應用的每個內容和功能，天然是可以獨立使用的，且使用方式比原生應用的 Deep LInk 更多樣靈活（Deep Link 本來就是為了緩解原生應用沒有 URL 帶來的弊病）：

更容易被文本/語音/視覺搜索發現、理解、組織、推送。

能「混搭（Mashup）」。

更容易用類似 IFTTT、RPA（機器人流程自動化）的方式串聯起來，實現新的功能。

可以像閱讀器、Reddit 一樣做聚合和 curation。

更容易實現不同應用之間的 Interoperability（互操作性）。

更容易為應用的每個狀態、運行過程中的每個「snapshot」都提供 URL。

普通用戶也能輕易的、無代碼（No-Code）的再利用 URL，類似「二次創作」和「共創」。

URL 實際上是讓 Web 應用被拆分成很多小應用，反過來，也讓一個 Web 應用可以由很多應用組成，讓應用可以組成新的應用。

由此帶來一種更移動互聯網的產品設計原則：Creating systems not destinations

這種解綁需求和趨勢，也導致移動互聯網剛起步時「Web 已死」的說法逐漸被遺忘。如今的原生應用變得「超級應用化」——也就是「瀏覽器化」，應用中大量 Unbundling 的內容和功能，都用 Web 技術來實現（H5 或跨端技術）。

?

?

1.3.4 即用能力

URL 這種分發方式，還是免安裝的，可以按需訪問。

漏斗更淺，可以把流量直接轉化成用戶（且永遠是應用最新版本的用戶）。而這種流量可以來自 Open Web 生態的各個角落（不需要像原生應用一樣做專門的建設和合作）。包括各種「私域流量」，因為對普通用戶來說 URL 也是開放免費低門檻的工具。

不但拉新成本低，召回成本也更低。

雖然移動應用有幾百萬個，但研究表明，智能手機上平均只會安裝 80 多個應用。

即使只是這 80 個應用，大多數之后都沒有使用，或很快就不再使用。

早在 17 年，智能手機用戶平均每天使用的應用就只有 10 個，每月只有 30 個（如今隨著超級應用的發展和應用增長停滯，數字會更低。另外以下特意選擇美國市場的數據，因為國外的超級應用相對更少，數據更分散）。

25% 的應用在下載后只使用一次，然后就再也沒有使用過。

https://www.statista.com/statistics/271628/percentage-of-apps-used-once-in-the-us/

大部分用戶在下載應用后一段時間就流失了。

根本原因是大部分用戶需求都是在特定條件下（比如時間、場景、人、上下文、興趣、關注點等）才存在的，導致：

條件不具備時，拉新和召回都非常低效，不但轉化率低，還容易損害用戶體驗和品牌形象。

在條件具備之前安裝和維持應用，會在用戶側帶來高成本，包括占用存儲資源、拖慢速度（在用戶感知中），增加認識負擔（除了無形的，也包括有形的，比如耗費精力組織管理）。

條件具備時，安裝帶來的成本打斷了原本自然連貫的需求轉化和用戶行為，容易減弱或破壞這次轉化。

多數需求的條件是低頻出現的。即使對于少數高頻的需求，用戶愿意提前安裝，當條件具備時，用戶經常還是需要離開當前的上下文，主動查找和喚起所需的應用，同樣有打斷。

原生應用不得不「報團取暖」，建立圍墻花園（超級應用），希望能把用戶關在自家花園里，讓用戶需求的條件總是在自家花園里出現，或在條件出現時，讓用戶無他處可去。

Web 應用不是必須這么做，有其他路可走。

Web 應用的 URL 可以「放」在所有「有條件」的地方，伴隨著這些條件的出現而出現，在條件消失后消失，即用即走，用完不管，可以不留痕跡。

對用戶來說無負擔、輕量（在心智模型里輕，不是應用本身輕）、容易采納和嘗試。

對產品來說，留存和頻次也有保障，只要你的 URL 總是在「有條件」的地方出現，或只要你的應用真的好用。

如果真的好用，且是高頻需求，讓用戶想要更方便的主動喚起，可以給 Web 應用增加對 PWA 的支持，實現「按需安裝」、「即用即裝」、「先用后裝」，獲得跟已安裝的原生應用一樣的體驗和用法。并且仍然保持 URL 的能力（比如分享再利用）。

對于更多數的低頻需求，URL 的按需使用、一鍵直達、用完不管，是更合適的，不適合安裝。

所以 PWA 不是一定要安裝，有些用戶想裝（高頻需求），有些用戶不想裝（低頻需求），或換個時候才想裝（低頻變高頻）。

1.3.5 動態能力和共創能力

需要打包上傳和下載安裝的客戶端應用，很多就像院線電影和實體書籍一樣，是一堆靜態的、固定的、有限的內容和功能，習慣像實體商品一樣，一次性直接售賣（比如除了服務型游戲、Free-To-Play 類型游戲之外的游戲）。

URL 對應的內容和功能，通常不僅是動態加載的，還可以是動態生成的，整個 Web 應用可以是「無限」的，可以按需「生長」出新的部分。

這樣的整體應用，或單個 URL，都天然不適合像有限的實體商品一樣售賣，變現方式會擴展到各種互聯網商業模式：

羊毛出在狗身上，豬來買單

廣告

傭金

……

訂閱

付費墻

免費增值

SaaS

……

這種動態性也意味著強大的「共創」能力，不僅能寫代碼的開發者群體是最大的，開發者生態是最大的，容易發展 plugin、widget、theme、hook、bot 等代碼形態的開發者社區（類似游戲的 mod 開發社區），也容易讓普通用戶共同參與到 Web 應用的「生長」中，比如：

創作平臺：類似抖音、bilibili、Medium 等

眾包平臺：比如 Reddit 這樣的 Curation 社區

互動平臺：各種社區

低代碼 / 無代碼：在 C 端類似 aPaaS 的模式，有的編輯器獨立于主應用，有的編輯能力融入主應用。參考 Minecraft、Roblox、Rec Room

……

1.3.6 跨平臺能力

「Web Runtime」章節反復強調了無處不在和至關重要的「標準化」，Web 獨特的跨平臺能力就是「標準化」帶來的。

看到「跨平臺」，可能第一反應是跟「平臺獨占」、「平臺利益」、「差異化優勢」有矛盾。其實越是不利用跨平臺能力，矛盾就真的越大，因為平臺不是活在真空里，你不利用，別人會利用，「就怕貨比貨」：

平臺的設計、API、知識庫、開發者社區等都趨向加拉帕格式化，跟業界脫節

容易陷入無止境的落后追趕狀態（因為沒有「站在巨人肩膀上」，沒有「先多抄、抄對，再學會創新」）

容易小眾化、兼容性差、測試少（"given enough eyeballs, all bugs are shallow"），給開發者帶來很高的學習成本、接入成本、適配成本、升級成本。

被那些想避開「蘋果稅」的開發者和合作方拋棄，成為競爭對手。

被那些想避開「平臺鎖定」的開發者和合作方拋棄，成為競爭對手。

排斥開源社區和獨立開發者。

平臺的內容和功能，只能在比其他平臺更小的范圍里傳播，缺少網絡效應，削弱用戶的創作動力和分享動力。

平臺的應用和用戶，只能在比其他平臺更小的范圍里互動，缺少網絡效應，削弱用戶的多人體驗。

用戶進入平臺的門檻更高，離開的代價也更高，讓用戶反而更不傾向于投入沉沒成本，雖然沒離開，但也不活躍。

……

而越是利用跨平臺能力，矛盾越小：

站在巨人肩膀上，把資源投入到真正能發展差異化優勢的地方，做真正的創新，不怕跨平臺技術帶來的同質化。

融入主流，參與到跨平臺技術的發展和標準化工作中，提早洞悉趨勢，消除沖突，避免自己走彎路，避免跨平臺技術對自己有損害。

有更多機會讓自己平臺的新技術對業界產生更大影響，更有可能去定義標準，讓自己平臺的新技術擁有更多跨平臺技術帶來的杠桿，放大優勢。

留住那些不喜歡「蘋果稅」的開發者和合作方。

成為那些想避開「平臺鎖定」的開發者和合作方的多平臺戰略的一部分。

吸引開源社區和獨立開發者。

更活躍、更豐富、更有傳播力和創造力的用戶社區，有網絡效應。

讓用戶更容易進入平臺，更沒必要離開平臺，敢于投入沉沒成本。

……

Web 的跨平臺能力，包括「不對稱」的跨平臺，比如同時支持 X 設備、桌面電腦、手機。在不同平臺上的能力可以是不對稱的：

可以「漸進增強（Progressive Enhancement）」，在 X 設備中獲得超出基準水平的體驗和功能，讓 X 設備的用戶擁有對其他平臺用戶也可見的「特權」。

可以「優雅降級（Graceful Degradation）」，在桌面和手機上只保留某些場景的可用性。

可以讓 X 端、桌面端、手機端各自做自己擅長的領域，可以結合使用，比如一些游戲的手機助手（跟游戲可以有共用的代碼實現和自適應的 UI）。

1.3.7 多人實時能力

現代 Web 應用天然適合做「Multiplayer App」、「RTA（Real-time App）」模式，實現多人實時的協作或互動。

除了 Web API、開源生態方面的原因，還有一個原因是 Web 應用天然是「Cloud First」（跟「云原生」有共通之處）的：

更容易擺脫本地文件的概念，避免傳送、同步、版本管理等問題

一個應用面對所有用戶，而不是每個用戶都裝了「自己的」應用（獨立客戶端）

更容易避免數據的分散，更容易把數據聯通起來，實現無縫的多人在線協作體驗。

不限于本地的網絡效應（比如本地客戶端積累的配置、組織管理的文件，小范圍的協作習慣），更容易發展全局的網絡效應（多人之間的、大規模人群之間的）

參考：Figma 為什么完勝 Sketch（Why Figma Wins）

也是因為這個原因，現在新一代的桌面端工具軟件，特別是生產力工具、編輯器形態的工具，都開始在 Web 上實現，用前端技術開發，強調「Web First」，它們的產物也更傾向是 Web 應用。比如（飛書、Notion 這類就不列舉了）：

2D 設計工具：Figma、Framer

3D 設計工具：Spline、Vectary、太極開物

游戲引擎：GDevelop、Construct 3、PlayCanvas

代碼編輯器：CodeSandbox、StackBlitz、Replit

白板工具：Excalidraw、FigJam

1.4 各平臺現狀

對于以上介紹的「Web 三要素」（Web Runtime、前端技術、URL）和「Web 的八大獨特能力」，國內外各大提供平臺級軟件的廠商都在做大力和持續的投入，且都有各自的側重和長項。

1.4.1 Google（新能力）

略…

1.4.2 Microsoft（應用開發者）

略…

1.4.3 Meta（UI 框架）

略…

1.4.4 Apple（歷史沉淀）

略…

1.4.5 國內大廠（小程序、容器技術）

略…

1.5 什么是 Web

回到開頭的「到底什么是 Web？」這個問題。

狹義的 Web 專指「Open Web」（符合統一的開放標準的 Web），

實現：基于前文介紹的前端技術、Web 文件、標準的 Web 軟件形式

分發：基于前文介紹的 URL 和 PWA

運行：基于前文介紹的標準化 Web Runtime

而從廣義上、本質上來說，只要同時具備八大 Web 獨特能力，就是 Web。

Duck Test：如果它看起來像鴨子、游泳像鴨子、叫聲像鴨子，那么它可能就是只鴨子

因為 Web 作為「全行業在平臺技術上最大、最主要的交集和共識」，原本就是為這些獨特能力而設計的（其實很多獨特能力都得益于前文中被「嫌棄」過的超文本文檔的需求），是對這些能力所做的標準化工作。

廣義定義和狹義定義，區別之處只在于是否符合統一的開放標準，共同之處是都要具備 Web 的獨特能力。

很多原生應用在這八大能力的其中一些上面也做的很好，如果有哪個應用最終在這八個方面全做到很好，這個應用實際上就徹底「Web 化」了，要么已經重構成了基于 Open Web 技術的實現，要么演化出了跟 Open Web 技術趨同的架構、設計和實現。

前面提到過「Web 的標準化并不是教條和瓶頸，可以圍繞業務需求，有選擇的、務實的做 trade-off 做取舍」。也就說，完全可以用自定義的方式，去實現這八大能力中的部分（或嘗試全部）。

但經過 GUI 軟件技術幾十年發展的經驗，Web 標準和 Open Web 技術是唯一完整具備這八大能力的技術。所以非標準的自定義方式，總會有些能力缺失或做的不到位，得到一種不完全的、私有的自定義 Web。

小程序就是這樣一種不完全的自定義 Web。

小程序是以下彩色部分的組合：

小程序的「trade-off」：

小程序的成功來自：

Web 的即用能力、部分跨平臺能力

Web 的部分分發能力

較低的上手門檻，一體化的良好的開發體驗

抽象程度高的 API（比如應用框架，比如現成的、移動優先的、原生 App 風格的 UI 實現）

結合原生技術的性能優化（相當于在自定義 Web Runtime 方面做的增強，其中網絡性能優化起到的作用更大）

后 3 條跟 Web 不沖突，原本不需要「取舍」，可以在保持 Web 八大能力的基礎上做到這三條。

編輯：黃飛

?