到底什么是 Web?要回答這個問題,需要先理解 Web 的三要素:
Web Runtime
前端技術(shù)
URL
1.1 Web Runtime
第一個核心要素是「Web Runtime」,基于 Web 的內(nèi)容或應(yīng)用,本質(zhì)上都是一種用高度抽象的方式來實現(xiàn)、分發(fā)和運行的客戶端軟件,需要建立在一個非常 high level 的軟件抽象層(abstraction layer)上,這個抽象層就是「Web Runtime」。
提供「Web Runtime」的客戶端技術(shù),可以分為這么四類:
傳統(tǒng)瀏覽器:一種應(yīng)用層的 Web 平臺,在桌面平臺上是主流,比如 Chrome、Safari、Edge。
PWA(Progressive Web App):基于 OS 層的 Web 平臺,在全球是主流,比如 YouTube 的桌面應(yīng)用和 Premium 離線訪問、BBC 的 UAP 等。
WebView:在 OS 層提供的 Web 能力 API,在移動平臺上是主流,比如 iOS 的 WKWebView、Android 的 WebView、Windows 的 WebView2。
跨端(Hybrid)容器:在應(yīng)用層提供的 Web 能力 API,在國內(nèi)是主流,比如小程序、Kun、Weex 等技術(shù)。
在傳統(tǒng)瀏覽器里,「Web Runtime」被稱作「瀏覽器引擎」,由于 2D 互聯(lián)網(wǎng)中的瀏覽器傳統(tǒng)上主要用來渲染帶交互能力的 2D 圖文內(nèi)容,所以「瀏覽器引擎」也經(jīng)常稱作「渲染引擎」。
1.1.1 瀏覽器
瀏覽器引擎對用戶來說是「無形的」,像是一副展示內(nèi)容或軟件界面的「空白畫布」,用戶能感知到的「有形的瀏覽器」相當于是「畫框」,是地址欄、收藏夾、標簽頁這些用戶使用 Web 的「輔助工具」。
「有形的瀏覽器」可以是其他的形態(tài),提供不同的「輔助工具」,不一定有地址欄,比如:
1、Visual Search 應(yīng)用(比如 Google Lens、Snapshot、抖音):用攝像頭畫面替代地址欄,用視覺搜索(基于 CV、AR 技術(shù))來找到要訪問的 Web。
2、Chatbot 應(yīng)用(比如微信、飛書、Messenger):用聊天對話窗口替代地址欄,通過指令或自然語言(NLP)對話來找到要訪問的 Web(以卡片形式推送到對話信息流中)。
3、信息流應(yīng)用(比如今日頭條、微博、Facebook、Twitter):通過信息流的推薦算法來訪問 Web。
對于以上三種類型,Snapchat 的 Snap Minis 是一個典型案例
用戶跟好友互動的地方,就是 Mini 運行的地方(對話信息流、相機鏡頭)。
Mini 基于 Web 的 HTML5 和 JS 技術(shù),創(chuàng)建一個 Mini 就像構(gòu)建一個 HTML5 網(wǎng)站,能用來實現(xiàn)從小工具到實時社交游戲的各種應(yīng)用。
4、Web OS(比如 Chrome OS):像獨立原生應(yīng)用一樣,在 OS 的應(yīng)用商店、全局搜索等地方找到 Web 應(yīng)用,「安裝」到 OS 的 dock 上,點擊應(yīng)用圖標打開對應(yīng)的 Web 應(yīng)用。
5、其他超級應(yīng)用或跨端容器應(yīng)用(比如美團、Google Maps、…):通過黃頁導(dǎo)航、地圖上的 POI 等各種方式來找到要訪問的 Web。
我們平時說的「瀏覽器」專指那種有地址欄的傳統(tǒng)瀏覽器應(yīng)用,是延續(xù)了桌面平臺的習慣和理解,因為在桌面時代,這種形態(tài)的瀏覽器幾乎是唯一的「超級應(yīng)用」。
從移動互聯(lián)網(wǎng)時代開始,它們就已經(jīng)不再是唯一的「瀏覽器」了(不是唯一提供 Web Runtime、提供 Web 應(yīng)用平臺能力的超級應(yīng)用)。
以上五種應(yīng)用形態(tài)本質(zhì)上都是瀏覽器,其中有的就是更現(xiàn)代的瀏覽器,有的是為垂直領(lǐng)域做專門優(yōu)化的瀏覽器。
Web Runtime 本身(「畫布」部分)就是一個最基本的「Web 平臺」。
以上這些提供 Web Runtime 的平臺級軟件(Chrome、Chrome OS、微信、頭條、飛書們),也都是「Web 平臺」,它們在「畫布」基礎(chǔ)上增加了各自的「畫框」部分,形成了更實用的、更貼近業(yè)務(wù)領(lǐng)域和用戶群體的「Web 平臺」。
反過來說,一個平臺越是跟 Web Runtime 緊密結(jié)合,就越具備「Web 平臺」的能力和特點(比如 Chromebook 相對于同樣在系統(tǒng)層面集成了瀏覽器引擎的 iPad)。
1.1.2 應(yīng)用平臺
Web Runtime 作為最基本的「Web 平臺」,是一種標準化(稱作「Web 標準」)的軟件應(yīng)用平臺,隱藏了更下層軟件平臺的差異(比如不同硬件、不同 OS、不同底層 API),提供了跨平臺的、抽象程度更高的、開發(fā)成本和門檻通常都更低的軟件開發(fā)能力。
傳統(tǒng) Web 是以超文本文檔(可交互的 2D 圖文)內(nèi)容為中心的。
HTML 這樣標準化的「標記語言」(負責實現(xiàn)內(nèi)容和結(jié)構(gòu)),加上 CSS 這樣的「樣式聲明語言」(負責實現(xiàn)外觀),是這種軟件開發(fā)能力的核心。
Web Runtime 為此提供:
布局引擎:按照 Web 標準,把 HTML 從純文本,解析成文檔節(jié)點對象(DOM 對象)組成的樹狀數(shù)據(jù)結(jié)構(gòu)(稱作 Content Tree),結(jié)合 CSS 中的聲明,生成由矩形(盒狀模型)組成的樹狀數(shù)據(jù)結(jié)構(gòu)(稱作 Render Tree 或 Frame Tree),經(jīng)過自動布局(Layout,也稱作 Reflow,簡單的情況下相當于做圖文排版),最后「繪制」(Paint)出網(wǎng)頁內(nèi)容。
網(wǎng)頁內(nèi)容由各種媒體形式組成:純文本、「超文本」(包含鏈接的文本)、圖片、視頻音頻、動畫等
網(wǎng)頁內(nèi)容的默認交互行為:鏈接和錨點的跳轉(zhuǎn),表單輸入和提交
https://web.dev/howbrowserswork/
如果 Web Runtime 僅限于這種能力,就只是一種內(nèi)容閱讀器或播放器(雖然這方面能力也很重要)。
但在現(xiàn)代的 Web 開發(fā)中,不僅不止這方面能力,而且這部分能力由于抽象程度太高、太垂直化(原本是為「內(nèi)容」開發(fā)而設(shè)計的)、不夠靈活強大、不一定適應(yīng)「應(yīng)用」開發(fā)的需求,經(jīng)常被邊緣化或隱藏。
更現(xiàn)代的 Web 是以程序語言為中心的。
軟件開發(fā)能力的核心是 JS(JavaScript) 和 WebAssembly 這兩種標準化的 Web 原生語言。
JS 側(cè)重「生產(chǎn)側(cè)」和「DX(開發(fā)者體驗)」
用于業(yè)務(wù)需求的實現(xiàn)。
JS 還包含 TypeScript 等變體。
WebAssembly 側(cè)重「消費側(cè)」和「UX(用戶體驗)」
用于性能優(yōu)化、跟底層打交道和非 Web 程序的移植。
Web Runtime 中為此提供:
JS 引擎:能標準化的執(zhí)行 Web 原生語言的虛擬機,讓語言既可以做計算,也可以調(diào)用 Web API
內(nèi)部包含實時編譯成原生機器代碼、根據(jù)運行結(jié)果自動優(yōu)化代碼、垃圾回收等能力。
宿主環(huán)境:不斷運行著事件循環(huán),通過各種事件(比如頁面加載、鍵鼠點擊、XR 設(shè)備交互)來驅(qū)動 JS 引擎中的 Web 程序
Web API:宿主環(huán)境也提供可被編程語言調(diào)用的、標準化的 API,讓 Web 程序能實現(xiàn)各種:
「輸入」功能:監(jiān)聽人機交互事件、監(jiān)聽網(wǎng)絡(luò)通信事件、監(jiān)聽本地讀寫事件等
「輸出」功能:UI 布局、動畫、2D 或 3D 的圖形渲染、音頻視頻、本地存儲、網(wǎng)絡(luò)通信等
為了理解 Web Runtime,還必須同時理解里面跑的 Web 應(yīng)用:
1.1.3 Web 應(yīng)用
為了避免「Web 應(yīng)用」這個詞跟下文中狹義的「Web App」混淆,在下文里改稱為「Web 軟件」。
標準化的 Web 軟件在分發(fā)的時候,是一堆不同格式的 Web 文件,可以被 Web Runtime 通過標準化的網(wǎng)絡(luò)、用標準化的方式按需獲取,再標準化的解析和運行。
Web 文件包括:
HTML 文檔:類似一個容器,可以承載內(nèi)容和代碼
這種「文檔」文件需要獨立于 Web 軟件的版本,能自主變化,比如:
更新內(nèi)容
對不同用戶提供不同內(nèi)容
把代碼更新到不同的 Web 軟件版本
靜態(tài)文件:在同一個 Web 軟件版本中保持不變。包括:
代碼文件:會被 Web Runtime 解析和運行。
JS 文件、WASM 文件(WebAssembly 代碼)、CSS 文件
資源文件:會被文檔和代碼使用到。
圖片、字體、視頻、音頻、數(shù)據(jù)等。
Web 軟件包括
標準化的 Web 軟件
獨立網(wǎng)頁:
側(cè)重「內(nèi)容」
沒有子頁面(比如很多 H5 營銷活動只有一個頁面)。
多頁網(wǎng)站:
側(cè)重「內(nèi)容」
由多個頁面組成,通過鏈接組織到一起(這里說「頁面」是業(yè)務(wù)和用戶體驗上的概念,不是技術(shù)概念,所以并不一定對應(yīng)到 HTML 文檔)。
Web App(狹義):
側(cè)重「功能」,更類似應(yīng)用軟件
組織的粒度可以比頁面更細。
PWA(Progressive Web App):
Offline First、可安裝的 Web App。
運行在瀏覽器中,但在外觀和用法上可以獨立于瀏覽器。
既能實現(xiàn)跟獨立原生應(yīng)用一致的體驗,也能保持 Web App 的獨特能力(具體能力見后文)。
以上全是通過完全標準化方式實現(xiàn)。
非標準的 Web 軟件
跨端界面(HybridUI):
原生客戶端里基于 Web 技術(shù)的界面。
通常運行在客戶端的 WebView 里(這種 Web Runtime 是標準化的,但客戶端經(jīng)常會在標準基礎(chǔ)上做非標準的自定義擴展)
也有的會以完全非標準的方式運行(比如運行在非標準的 Runtime,也就是「跨端容器」里,比如部分或全部以原生方式運行)
分發(fā)方式經(jīng)常是非標準的(比如打包在客戶端里、用自定義方式下發(fā))
通常跟特定產(chǎn)品的客戶端需求、非標準化的客戶端能力綁定在一起,無法獨立使用
典型例子有端上內(nèi)嵌 H5 界面、小程序。
打包應(yīng)用(Packaged App):
類似 Hybrid UI,但不是單一界面,整個 Web App 都運行在基于原生客戶端技術(shù)的容器里,只不過這個容器是通用的「空殼」,本身不含業(yè)務(wù)邏輯,只負責給 Web 軟件:
提供能力(包括標準化的能力,和在標準基礎(chǔ)上增強的非標準能力)
也有的打包應(yīng)用會完全編譯成原生應(yīng)用。
標準化的 Web 軟件需要運行在瀏覽器里,或運行在其他跟瀏覽器一樣具備完全標準化 Web Runtime 的客戶端里(如前文所述,這種客戶端實際上已經(jīng)是一種瀏覽器,只是形態(tài)和功能跟傳統(tǒng)瀏覽器不同)。
PWA 在「標準化的 Web 軟件」中具備獨有的能力,能「看上去」獨立于瀏覽器、像獨立應(yīng)用一樣安裝和運行。
標準化的 Web 軟件都一定具備全部 Web 的獨特能力(具體能力見后文)。
非標準的 Web 軟件完全獨立于瀏覽器,運行方式通常有非標準的部分,或是完全非標準。分發(fā)方式通常完全非標準。
非標準的 Web 軟件不具備很多 Web 的獨特能力。
注意上圖的含義:「標準化的 Web 軟件」在分發(fā)、實現(xiàn)、運行這三個環(huán)節(jié)一定都必須是「標準」的,而「非標準的 Web 軟件」可以在這三個中的任一環(huán)節(jié)引入「非標準」,也就是說,「非標準的 Web 軟件」并不一定在所有環(huán)節(jié)都是「非標準」的,可以在某些環(huán)節(jié)保持「標準」。
1.1.4 標準化
可以看到 Web Runtime 的本質(zhì)和關(guān)鍵在于:
以上描述的所有架構(gòu)設(shè)計
方方面面的標準化
這種架構(gòu)設(shè)計帶來了 Web 面向 end user、面向開發(fā)者的很多能力(其中很多能力是獨有的,見后文),而標準化確保了這些獨特能力在不同平臺上的一致性,這種跨平臺一致性本身也是 Web 獨特能力的核心部分。
包含架構(gòu)設(shè)計在內(nèi)的這些標準化,并不是教條和瓶頸,可以圍繞業(yè)務(wù)需求,有選擇的、務(wù)實的做 trade-off 做取舍,引入非標準。但由于會損失 Web 獨特能力,必須能換來更大的利益,才值得去搞非標準,而且最好是在一個逐步通向或兼顧標準化的長期戰(zhàn)略中去搞非標準。
1.2 前端技術(shù)
第二個核心要素是「前端技術(shù)」。
「Web Runtime」強調(diào)的是「消費側(cè)」(應(yīng)用的運行和使用)的 Web 技術(shù),「前端技術(shù)」強調(diào)的則是「生產(chǎn)側(cè)」(應(yīng)用的開發(fā)實現(xiàn))的 Web 技術(shù)。
前端技術(shù)幾乎是在 Web Runtime 之上做開發(fā)所必須的壟斷技術(shù)(一些來自其他技術(shù)棧的、小眾的或歷史遺留的解決方案和開發(fā)場景除外)。
反過來說,前端技術(shù)又不等同于 Web Runtime 的開發(fā)技術(shù),也不等同于做 Web 應(yīng)用的技術(shù),而是一個可以說包羅萬象無所不能紛繁復(fù)雜的大雜燴。
1.2.1 起源和分裂
雖然是大雜燴,前端技術(shù)仍然可以追溯到兩個根本的古老起源:
1、編寫和維護符合 Web 標準的超文本文檔的技術(shù)。
來自這個起源的后續(xù)發(fā)展,更側(cè)重「內(nèi)容」場景,更關(guān)注結(jié)構(gòu)語義、外觀、視覺效果、UI、UX。這個方向的前端開發(fā)者,更趨向 Designer 和創(chuàng)意內(nèi)容制作者。
?
2、基于 Web 標準中涌現(xiàn)的兩類重要 API(異步讀寫數(shù)據(jù)的 API、操作文檔對象的 API)實現(xiàn)和維護「富 Web 應(yīng)用」的技術(shù)。
來自這個起源的后續(xù)發(fā)展,更側(cè)重「功能」場景,更關(guān)注業(yè)務(wù)復(fù)雜性、代碼復(fù)雜性和開發(fā)效率,也因此專注于代碼復(fù)用、應(yīng)用架構(gòu)、工程化和基礎(chǔ)建設(shè)。這個方向的前端開發(fā)者,更趨向軟件工程師和應(yīng)用開發(fā)者。
區(qū)分這兩個方向的技術(shù)、開發(fā)者需求與偏好,是很重要的。如果搞混或以偏概全,就很容易誤解 Web 技術(shù)和 Web 場景。
1.2.2 吞噬世界
更新:注意「吞噬世界」和下面的圖都是業(yè)界老生常談的梗,不是我生造的,放在這里含調(diào)侃意味。如果你之前沒見過,可以爬一下我標注的鏈接,擴大下視野。
前端程序最初不是一種獨立的應(yīng)用程序,而是以服務(wù)器端為中心的 Web 程序中的「前端部分」(所以現(xiàn)在仍然延續(xù)習慣稱作「前端」)。能力很有限,技術(shù)需求也簡單。早期很多前端開發(fā)者寫的都不是真正的、產(chǎn)品級的代碼,而是跟設(shè)計師一樣做「假」的輸出物(比如模擬實際效果的網(wǎng)頁),交給「真正」的程序員和產(chǎn)品開發(fā)者去改寫成真正的、產(chǎn)品級的代碼。
只用短短幾年時間,前端技術(shù)就發(fā)展成了獨立的應(yīng)用軟件開發(fā)技術(shù),并且以大致每五年就換代的速度快速發(fā)展,不但在幾乎所有方面都追平了其他歷史底蘊深厚、有老牌大廠和獨占平臺支持的、成熟系統(tǒng)的軟件開發(fā)技術(shù)棧,還在很多方面跑到了更前面,被其他技術(shù)棧反向?qū)W習。
典型例子:
大家都在抄的 React:前端技術(shù)中演化出的 React 引領(lǐng)了 GUI 編程的變革,被 Apple、Google 等老牌 GUI 平臺廠商學(xué)習,支撐自己的次世代應(yīng)用開發(fā)方案(SwiftUI、Jetpack Compose、Flutter、Omniverse UI)。
獨有的前后端一體化技術(shù):前端技術(shù)能讓一個 Web App 成為同時跑在客戶端和服務(wù)器端(指客戶端 App 本身在服務(wù)器端跑)的一體化應(yīng)用,能同時發(fā)揮 Web 客戶端和服務(wù)器端的優(yōu)勢(比如實現(xiàn)「無限」大小的應(yīng)用、利用邊緣計算技術(shù)等),這是其他 GUI 軟件技術(shù)都不具備的,想學(xué)都學(xué)不了。
強大的 JS 運行環(huán)境:JS 擁有業(yè)界性能最頂級、場景最多樣的運行環(huán)境,光是其他很多動態(tài)語言求而不得的工業(yè)級的、頂級性能的虛擬機就有好多個,在巨頭們(比如 Google、Apple、Microsoft、Facebook、三星)和各種開源組織(比如 Mozilla、Igalia、OpenJS)長年累月的重度投入下,引入所有新技術(shù)和奇技淫巧,讓最初為寫腳本而設(shè)計、身為動態(tài)語言的 JS,性能被強行抬高到靜態(tài)系統(tǒng)編程語言的水平,在服務(wù)器端、邊緣計算、跨端技術(shù)、物聯(lián)網(wǎng)、腳本環(huán)境等各種垂直場景都有專門打造的選擇。
https://zhuanlan.zhihu.com/p/453354202
如今前端技術(shù)棧和前端技術(shù)社區(qū)是最龐大的技術(shù)生態(tài)(包括最龐大的開源生態(tài))。
前端技術(shù)是使用最廣泛、需求量最大的技術(shù)。
JS 開發(fā)者是最大的開發(fā)者群體,在全球所有軟件開發(fā)者中占比超過60%。
?
?
https://en.wikipedia.org/wiki/Jeff_Atwood
http://brendaneich.github.io/ModernWeb.tw-2015
https://twitter.com/lexfridman/status/1360373028912300040
前端技術(shù)在變強大的同時,也保持了直觀、輕量、抽象、高效、關(guān)注產(chǎn)品和用戶(面向人,而不是面向機器,obsessive customer focus)的開發(fā)體驗,以及更低的上手和實踐門檻。
典型例子除了前面說的最大開源生態(tài)的支持,還有一個是「即時反饋」:
修改了代碼,很快可以看到效果。
在有編譯構(gòu)建環(huán)節(jié)的情況下,推送到真機做測試的過程也可以輕量簡單。
前端開發(fā)者對編譯構(gòu)建等待時間更敏感、要求更高,社區(qū)在這方面不懈的優(yōu)化改進。
免編譯或按需做增量編譯、自動推送、熱更新應(yīng)用中有變化的部分,接近 Live coding 的體驗,是前端技術(shù)的慣例和文化。
很多時候可以實現(xiàn)真正的 Live coding,包括無編譯,直接運行。包括所見即所得的低代碼(Low-Code)開發(fā)方式。
1.2.3 底層邏輯
前端技術(shù)的這種「既要又要還要」的特點、目不暇接的發(fā)展速度和龐大生態(tài),很大程度上是因為以下三個獨一無二的特點:
1、全行業(yè)實際需求推動
根本推動力并非像其他技術(shù)一樣,來自學(xué)術(shù)研究、文化理念或特定商業(yè)目標,而是完全來自互聯(lián)網(wǎng)全行業(yè)(特別是前沿行業(yè))產(chǎn)品需求的發(fā)展,自己不想動都會被實際需求推著走。
前端技術(shù)是 Web(萬維網(wǎng))的原生技術(shù)。跟整個互聯(lián)網(wǎng)產(chǎn)業(yè)緊密結(jié)合在一起,隨之一起不斷成長。
前端技術(shù)的發(fā)展,不斷為互聯(lián)網(wǎng)產(chǎn)品形態(tài)和商業(yè)模式,帶來可能性和進步,這反過來又促進了產(chǎn)品需求的發(fā)展被第一時間轉(zhuǎn)變成前端技術(shù)的完善和演進,彼此是正循環(huán)的關(guān)系。
2、標準化和開放
建立在 Open Web 技術(shù)(Web 標準)之上,這種技術(shù)是全行業(yè)在平臺技術(shù)上最大、最主要的交集和共識。
因此能得到幾乎所有大小企業(yè)和個人的采納、投資和實踐。
新的交集和共識要么以行業(yè)協(xié)作的形式,在委員會的主導(dǎo)下被謹慎嚴謹?shù)奶砑拥?Open Web 里,要么以 de facto(事實標準)的形式在實際應(yīng)用中被快速落地、驗證和普及,最終被采納和融入到 Open Web 技術(shù)中。
3、抽象程度最高
JS 技術(shù)棧和 Web Runtime,都是位于最高抽象層級上的軟件技術(shù),最接近終端用戶和產(chǎn)品需求,也最接近技術(shù)發(fā)展(本質(zhì)是在不斷壘加抽象層)的前沿,需求變化最快,抽象程度高又帶來成本低,能專注于用戶和業(yè)務(wù)的需求。兩者加起來,就讓迭代發(fā)展達到最快。
反之,如果在有些領(lǐng)域里建設(shè)不足,導(dǎo)致抽象程度暫時不夠高,發(fā)展就會遲緩,比如在獨立移動應(yīng)用開發(fā)領(lǐng)域,跟小程序、SwiftUI(從一開始就面向這個垂直領(lǐng)域的 high level 需求去設(shè)計)相比。
1.3 URL 的魔法和 Web 的獨特能力
第三個核心要素「URL」。
URL 全稱是「Uniform Resource Locator(統(tǒng)一資源定位符)」,中文里經(jīng)常稱作「網(wǎng)址」、「地址」。它的本體是一段文本,長這個樣子:
Web 的獨特能力可以歸納為以下 8 個
分發(fā)能力
解綁能力
混搭能力
即用能力
動態(tài)能力
共創(chuàng)能力
跨平臺能力
協(xié)作能力
這些能力都是「Web 三要素」帶來的,其中 URL 起到了最多的作用。
1.3.1 真名魔法
如果把 Web 看成虛擬世界,URL 相當于世上一切事物的「真名」。萬事萬物都可以有獨一無二的「真名」。
這里說的有「真名」的「萬事萬物」,不僅包括嚴格意義上的網(wǎng)頁(HTML 文檔)、代碼文件、各種格式的媒體文件比如圖片視頻音頻、各種數(shù)據(jù)文件等「真實存在」的、「看得見摸著」的「資源」,還包括:
程序實時自動生成的「資源」
有些程序在不同條件下會生成不同的「資源」,有不同的「真名」,這種情況下,不同資源對應(yīng)的「條件」會需要直接包含在「真名」里。
有些程序生成的「資源」,在不同條件下會發(fā)生變化,但仍然是同一個「資源」,只有一個「真名」。
Web 應(yīng)用運行過程中的某個「狀態(tài)」比如:
Web 應(yīng)用的初始狀態(tài)。相當于「入口」、「首頁」、「首屏」的「真名」。
Web 應(yīng)用顯示某個功能界面或顯示某個內(nèi)容時的狀態(tài)。相當于這個「功能」或「內(nèi)容」的「真名」。
當顯示某個「內(nèi)容」的「子內(nèi)容」時,Web 應(yīng)用進入的不同狀態(tài)。比如「子應(yīng)用」從折疊變成展開、從屏幕外變成屏幕內(nèi)。相當于這個「子內(nèi)容」可以有自己的「真名」。
當在某個「功能」中抵達某個「中間環(huán)節(jié)」,或取得某種「結(jié)果」時,Web 應(yīng)用進入的不同狀態(tài)。比如按引導(dǎo)完成了第一個步驟、在地圖里搜索了關(guān)鍵詞、在游戲里抵達了某個位置。相當于這些「中間環(huán)節(jié)」、「結(jié)果」都可以有自己的「真名」。
掌握了任何事物的「真名」,就對這個事物擁有了魔法般的力量:
可以「瞬間傳送」去訪問這個事物
如果這個事物是網(wǎng)頁資源,就會直接訪問這個網(wǎng)頁。
如果這個事物是 Web 應(yīng)用的某個狀態(tài),就會運行這個應(yīng)用,「還原」或「直接跳到」到這個狀態(tài)。
如果這個事物是代碼資源、多媒體資源、數(shù)據(jù)資源,你可以直接查看這些資源的內(nèi)容。
可以在 Web 代碼里「召喚」這個事物
如果這個事物是代碼資源、多媒體資源、數(shù)據(jù)資源,在滿足安全要求的情況下,可以不受限于它們的來源,用它們實現(xiàn)其他 Web 應(yīng)用中不同的內(nèi)容或功能。
如果這個事物是網(wǎng)頁資源,或Web 應(yīng)用的某個狀態(tài),在滿足安全要求的情況下,可以通過「爬蟲技術(shù)」抓取和解析到對應(yīng)的內(nèi)容和功能信息,用于其他 Web 應(yīng)用,也可以直接把它們嵌入到其他 Web 應(yīng)用。
可以在 Web 內(nèi)容或代碼里開啟通往這個事物的「傳送門」
比如在發(fā)表的文章里引用其他 Web 內(nèi)容的 URL。
比如把某個 Web 應(yīng)用的狀態(tài)轉(zhuǎn)發(fā)到聊天群里。
可以通過在「真名」中做細微的調(diào)整,讓原本的事物「變化」成另一個事物
比如有些攝影平臺上的照片,你可以通過調(diào)整照片的 URL,把它變成不同尺寸、格式
比如你能訪問某個店鋪商品列表的第一頁,通常也能訪問它的第二頁、第一百頁(除非該店鋪不想讓你順藤摸瓜)
URL 的這些設(shè)計和能力意味著什么呢?
1.3.2 分發(fā)能力
首先,URL 的本質(zhì)之一,是 Web 應(yīng)用和內(nèi)容的分發(fā)。
常說的「鏈接」,是「Hyperlink」的簡稱,在 Web 里的本意是指 HTML 里面對 URL 的引用。鏈接本質(zhì)上也是分發(fā)入口。
對 end user 來說,無論 URL 還是鏈接,這種入口都不必保持「硬核」的文本形式。
可以是圖文并茂的卡片,在信息流、聊天窗口、推廣位、AR 鏡頭、圖文內(nèi)容中出現(xiàn)。
可以是一種錨點,在視頻、鏡頭、圖片中出現(xiàn)。
可以作為一種可互動的對象,比如對話式卡片中的選項、按鈕,比如游戲中的門、水晶球、地磚、廣告牌。
可以是應(yīng)用圖標,像原生應(yīng)用一樣管理、搜索和打開。
?
?
越是現(xiàn)代的 Web 平臺設(shè)計,越趨向弱化和隱藏地址欄、URL 文本這類「硬核」細節(jié),讓 Web 潤物細無聲的支撐起更直觀的用戶體驗。
不過產(chǎn)品設(shè)計中還是需要留出「逃逸口」,在有需要的時候可以獲取 URL 文本,否則不利于下文提到的用戶再利用。
1.3.3 解綁能力和混搭能力
URL 這種分發(fā)方式,是細粒度的,不是只能分發(fā)整個應(yīng)用,可以分發(fā)里面具體的內(nèi)容(比如一個用戶的 Profile),可以分發(fā)一個具體的功能(比如某份點到一半的外賣訂單)。
這也意味著 URL 的另一種本質(zhì):App Unbundling(應(yīng)用解綁)。
Web 應(yīng)用不像原生應(yīng)用一樣以單一入口為主,要從最頂層的入口進入,一級一級深入進入各種內(nèi)容和功能。
Web 應(yīng)用是多入口為主的,很多內(nèi)容和功能可以直達(所以設(shè)計的時候要提供上下文,不能假設(shè)用戶都是經(jīng)過上層入口抵達這里)。
Web 應(yīng)用的每個內(nèi)容和功能,天然是可以獨立使用的,且使用方式比原生應(yīng)用的 Deep LInk 更多樣靈活(Deep Link 本來就是為了緩解原生應(yīng)用沒有 URL 帶來的弊?。?strong>:
更容易被文本/語音/視覺搜索發(fā)現(xiàn)、理解、組織、推送。
能「混搭(Mashup)」。
更容易用類似 IFTTT、RPA(機器人流程自動化)的方式串聯(lián)起來,實現(xiàn)新的功能。
可以像閱讀器、Reddit 一樣做聚合和 curation。
更容易實現(xiàn)不同應(yīng)用之間的 Interoperability(互操作性)。
更容易為應(yīng)用的每個狀態(tài)、運行過程中的每個「snapshot」都提供 URL。
普通用戶也能輕易的、無代碼(No-Code)的再利用 URL,類似「二次創(chuàng)作」和「共創(chuàng)」。
URL 實際上是讓 Web 應(yīng)用被拆分成很多小應(yīng)用,反過來,也讓一個 Web 應(yīng)用可以由很多應(yīng)用組成,讓應(yīng)用可以組成新的應(yīng)用。
由此帶來一種更移動互聯(lián)網(wǎng)的產(chǎn)品設(shè)計原則:Creating systems not destinations
這種解綁需求和趨勢,也導(dǎo)致移動互聯(lián)網(wǎng)剛起步時「Web 已死」的說法逐漸被遺忘。如今的原生應(yīng)用變得「超級應(yīng)用化」——也就是「瀏覽器化」,應(yīng)用中大量 Unbundling 的內(nèi)容和功能,都用 Web 技術(shù)來實現(xiàn)(H5 或跨端技術(shù))。
?
?
1.3.4 即用能力
URL 這種分發(fā)方式,還是免安裝的,可以按需訪問。
漏斗更淺,可以把流量直接轉(zhuǎn)化成用戶(且永遠是應(yīng)用最新版本的用戶)。而這種流量可以來自 Open Web 生態(tài)的各個角落(不需要像原生應(yīng)用一樣做專門的建設(shè)和合作)。包括各種「私域流量」,因為對普通用戶來說 URL 也是開放免費低門檻的工具。
不但拉新成本低,召回成本也更低。
雖然移動應(yīng)用有幾百萬個,但研究表明,智能手機上平均只會安裝 80 多個應(yīng)用。
即使只是這 80 個應(yīng)用,大多數(shù)之后都沒有使用,或很快就不再使用。
早在 17 年,智能手機用戶平均每天使用的應(yīng)用就只有 10 個,每月只有 30 個(如今隨著超級應(yīng)用的發(fā)展和應(yīng)用增長停滯,數(shù)字會更低。另外以下特意選擇美國市場的數(shù)據(jù),因為國外的超級應(yīng)用相對更少,數(shù)據(jù)更分散)。
25% 的應(yīng)用在下載后只使用一次,然后就再也沒有使用過。
https://www.statista.com/statistics/271628/percentage-of-apps-used-once-in-the-us/
大部分用戶在下載應(yīng)用后一段時間就流失了。
根本原因是大部分用戶需求都是在特定條件下(比如時間、場景、人、上下文、興趣、關(guān)注點等)才存在的,導(dǎo)致:
條件不具備時,拉新和召回都非常低效,不但轉(zhuǎn)化率低,還容易損害用戶體驗和品牌形象。
在條件具備之前安裝和維持應(yīng)用,會在用戶側(cè)帶來高成本,包括占用存儲資源、拖慢速度(在用戶感知中),增加認識負擔(除了無形的,也包括有形的,比如耗費精力組織管理)。
條件具備時,安裝帶來的成本打斷了原本自然連貫的需求轉(zhuǎn)化和用戶行為,容易減弱或破壞這次轉(zhuǎn)化。
多數(shù)需求的條件是低頻出現(xiàn)的。即使對于少數(shù)高頻的需求,用戶愿意提前安裝,當條件具備時,用戶經(jīng)常還是需要離開當前的上下文,主動查找和喚起所需的應(yīng)用,同樣有打斷。
原生應(yīng)用不得不「報團取暖」,建立圍墻花園(超級應(yīng)用),希望能把用戶關(guān)在自家花園里,讓用戶需求的條件總是在自家花園里出現(xiàn),或在條件出現(xiàn)時,讓用戶無他處可去。
Web 應(yīng)用不是必須這么做,有其他路可走。
Web 應(yīng)用的 URL 可以「放」在所有「有條件」的地方,伴隨著這些條件的出現(xiàn)而出現(xiàn),在條件消失后消失,即用即走,用完不管,可以不留痕跡。
對用戶來說無負擔、輕量(在心智模型里輕,不是應(yīng)用本身輕)、容易采納和嘗試。
對產(chǎn)品來說,留存和頻次也有保障,只要你的 URL 總是在「有條件」的地方出現(xiàn),或只要你的應(yīng)用真的好用。
如果真的好用,且是高頻需求,讓用戶想要更方便的主動喚起,可以給 Web 應(yīng)用增加對 PWA 的支持,實現(xiàn)「按需安裝」、「即用即裝」、「先用后裝」,獲得跟已安裝的原生應(yīng)用一樣的體驗和用法。并且仍然保持 URL 的能力(比如分享再利用)。
對于更多數(shù)的低頻需求,URL 的按需使用、一鍵直達、用完不管,是更合適的,不適合安裝。
所以 PWA 不是一定要安裝,有些用戶想裝(高頻需求),有些用戶不想裝(低頻需求),或換個時候才想裝(低頻變高頻)。
1.3.5 動態(tài)能力和共創(chuàng)能力
需要打包上傳和下載安裝的客戶端應(yīng)用,很多就像院線電影和實體書籍一樣,是一堆靜態(tài)的、固定的、有限的內(nèi)容和功能,習慣像實體商品一樣,一次性直接售賣(比如除了服務(wù)型游戲、Free-To-Play 類型游戲之外的游戲)。
URL 對應(yīng)的內(nèi)容和功能,通常不僅是動態(tài)加載的,還可以是動態(tài)生成的,整個 Web 應(yīng)用可以是「無限」的,可以按需「生長」出新的部分。
這樣的整體應(yīng)用,或單個 URL,都天然不適合像有限的實體商品一樣售賣,變現(xiàn)方式會擴展到各種互聯(lián)網(wǎng)商業(yè)模式:
羊毛出在狗身上,豬來買單
廣告
傭金
……
訂閱
付費墻
免費增值
SaaS
……
這種動態(tài)性也意味著強大的「共創(chuàng)」能力,不僅能寫代碼的開發(fā)者群體是最大的,開發(fā)者生態(tài)是最大的,容易發(fā)展 plugin、widget、theme、hook、bot 等代碼形態(tài)的開發(fā)者社區(qū)(類似游戲的 mod 開發(fā)社區(qū)),也容易讓普通用戶共同參與到 Web 應(yīng)用的「生長」中,比如:
創(chuàng)作平臺:類似抖音、bilibili、Medium 等
眾包平臺:比如 Reddit 這樣的 Curation 社區(qū)
互動平臺:各種社區(qū)
低代碼 / 無代碼:在 C 端類似 aPaaS 的模式,有的編輯器獨立于主應(yīng)用,有的編輯能力融入主應(yīng)用。參考 Minecraft、Roblox、Rec Room
……
1.3.6 跨平臺能力
「Web Runtime」章節(jié)反復(fù)強調(diào)了無處不在和至關(guān)重要的「標準化」,Web 獨特的跨平臺能力就是「標準化」帶來的。
看到「跨平臺」,可能第一反應(yīng)是跟「平臺獨占」、「平臺利益」、「差異化優(yōu)勢」有矛盾。其實越是不利用跨平臺能力,矛盾就真的越大,因為平臺不是活在真空里,你不利用,別人會利用,「就怕貨比貨」:
平臺的設(shè)計、API、知識庫、開發(fā)者社區(qū)等都趨向加拉帕格式化,跟業(yè)界脫節(jié)
容易陷入無止境的落后追趕狀態(tài)(因為沒有「站在巨人肩膀上」,沒有「先多抄、抄對,再學(xué)會創(chuàng)新」)
容易小眾化、兼容性差、測試少("given enough eyeballs, all bugs are shallow"),給開發(fā)者帶來很高的學(xué)習成本、接入成本、適配成本、升級成本。
被那些想避開「蘋果稅」的開發(fā)者和合作方拋棄,成為競爭對手。
被那些想避開「平臺鎖定」的開發(fā)者和合作方拋棄,成為競爭對手。
排斥開源社區(qū)和獨立開發(fā)者。
平臺的內(nèi)容和功能,只能在比其他平臺更小的范圍里傳播,缺少網(wǎng)絡(luò)效應(yīng),削弱用戶的創(chuàng)作動力和分享動力。
平臺的應(yīng)用和用戶,只能在比其他平臺更小的范圍里互動,缺少網(wǎng)絡(luò)效應(yīng),削弱用戶的多人體驗。
用戶進入平臺的門檻更高,離開的代價也更高,讓用戶反而更不傾向于投入沉沒成本,雖然沒離開,但也不活躍。
……
而越是利用跨平臺能力,矛盾越小:
站在巨人肩膀上,把資源投入到真正能發(fā)展差異化優(yōu)勢的地方,做真正的創(chuàng)新,不怕跨平臺技術(shù)帶來的同質(zhì)化。
融入主流,參與到跨平臺技術(shù)的發(fā)展和標準化工作中,提早洞悉趨勢,消除沖突,避免自己走彎路,避免跨平臺技術(shù)對自己有損害。
有更多機會讓自己平臺的新技術(shù)對業(yè)界產(chǎn)生更大影響,更有可能去定義標準,讓自己平臺的新技術(shù)擁有更多跨平臺技術(shù)帶來的杠桿,放大優(yōu)勢。
留住那些不喜歡「蘋果稅」的開發(fā)者和合作方。
成為那些想避開「平臺鎖定」的開發(fā)者和合作方的多平臺戰(zhàn)略的一部分。
吸引開源社區(qū)和獨立開發(fā)者。
更活躍、更豐富、更有傳播力和創(chuàng)造力的用戶社區(qū),有網(wǎng)絡(luò)效應(yīng)。
讓用戶更容易進入平臺,更沒必要離開平臺,敢于投入沉沒成本。
……
Web 的跨平臺能力,包括「不對稱」的跨平臺,比如同時支持 X 設(shè)備、桌面電腦、手機。在不同平臺上的能力可以是不對稱的:
可以「漸進增強(Progressive Enhancement)」,在 X 設(shè)備中獲得超出基準水平的體驗和功能,讓 X 設(shè)備的用戶擁有對其他平臺用戶也可見的「特權(quán)」。
可以「優(yōu)雅降級(Graceful Degradation)」,在桌面和手機上只保留某些場景的可用性。
可以讓 X 端、桌面端、手機端各自做自己擅長的領(lǐng)域,可以結(jié)合使用,比如一些游戲的手機助手(跟游戲可以有共用的代碼實現(xiàn)和自適應(yīng)的 UI)。
1.3.7 多人實時能力
現(xiàn)代 Web 應(yīng)用天然適合做「Multiplayer App」、「RTA(Real-time App)」模式,實現(xiàn)多人實時的協(xié)作或互動。
除了 Web API、開源生態(tài)方面的原因,還有一個原因是 Web 應(yīng)用天然是「Cloud First」(跟「云原生」有共通之處)的:
更容易擺脫本地文件的概念,避免傳送、同步、版本管理等問題
一個應(yīng)用面對所有用戶,而不是每個用戶都裝了「自己的」應(yīng)用(獨立客戶端)
更容易避免數(shù)據(jù)的分散,更容易把數(shù)據(jù)聯(lián)通起來,實現(xiàn)無縫的多人在線協(xié)作體驗。
不限于本地的網(wǎng)絡(luò)效應(yīng)(比如本地客戶端積累的配置、組織管理的文件,小范圍的協(xié)作習慣),更容易發(fā)展全局的網(wǎng)絡(luò)效應(yīng)(多人之間的、大規(guī)模人群之間的)
參考:Figma 為什么完勝 Sketch(Why Figma Wins)
也是因為這個原因,現(xiàn)在新一代的桌面端工具軟件,特別是生產(chǎn)力工具、編輯器形態(tài)的工具,都開始在 Web 上實現(xiàn),用前端技術(shù)開發(fā),強調(diào)「Web First」,它們的產(chǎn)物也更傾向是 Web 應(yīng)用。比如(飛書、Notion 這類就不列舉了):
2D 設(shè)計工具:Figma、Framer
3D 設(shè)計工具:Spline、Vectary、太極開物
游戲引擎:GDevelop、Construct 3、PlayCanvas
代碼編輯器:CodeSandbox、StackBlitz、Replit
白板工具:Excalidraw、FigJam
1.4 各平臺現(xiàn)狀
對于以上介紹的「Web 三要素」(Web Runtime、前端技術(shù)、URL)和「Web 的八大獨特能力」,國內(nèi)外各大提供平臺級軟件的廠商都在做大力和持續(xù)的投入,且都有各自的側(cè)重和長項。
1.4.1 Google(新能力)
略…
1.4.2 Microsoft(應(yīng)用開發(fā)者)
略…
1.4.3 Meta(UI 框架)
略…
1.4.4 Apple(歷史沉淀)
略…
1.4.5 國內(nèi)大廠(小程序、容器技術(shù))
略…
1.5 什么是 Web
回到開頭的「到底什么是 Web?」這個問題。
狹義的 Web 專指「Open Web」(符合統(tǒng)一的開放標準的 Web),
實現(xiàn):基于前文介紹的前端技術(shù)、Web 文件、標準的 Web 軟件形式
分發(fā):基于前文介紹的 URL 和 PWA
運行:基于前文介紹的標準化 Web Runtime
而從廣義上、本質(zhì)上來說,只要同時具備八大 Web 獨特能力,就是 Web。
Duck Test:如果它看起來像鴨子、游泳像鴨子、叫聲像鴨子,那么它可能就是只鴨子
因為 Web 作為「全行業(yè)在平臺技術(shù)上最大、最主要的交集和共識」,原本就是為這些獨特能力而設(shè)計的(其實很多獨特能力都得益于前文中被「嫌棄」過的超文本文檔的需求),是對這些能力所做的標準化工作。
廣義定義和狹義定義,區(qū)別之處只在于是否符合統(tǒng)一的開放標準,共同之處是都要具備 Web 的獨特能力。
很多原生應(yīng)用在這八大能力的其中一些上面也做的很好,如果有哪個應(yīng)用最終在這八個方面全做到很好,這個應(yīng)用實際上就徹底「Web 化」了,要么已經(jīng)重構(gòu)成了基于 Open Web 技術(shù)的實現(xiàn),要么演化出了跟 Open Web 技術(shù)趨同的架構(gòu)、設(shè)計和實現(xiàn)。
前面提到過「Web 的標準化并不是教條和瓶頸,可以圍繞業(yè)務(wù)需求,有選擇的、務(wù)實的做 trade-off 做取舍」。也就說,完全可以用自定義的方式,去實現(xiàn)這八大能力中的部分(或嘗試全部)。
但經(jīng)過 GUI 軟件技術(shù)幾十年發(fā)展的經(jīng)驗,Web 標準和 Open Web 技術(shù)是唯一完整具備這八大能力的技術(shù)。所以非標準的自定義方式,總會有些能力缺失或做的不到位,得到一種不完全的、私有的自定義 Web。
小程序就是這樣一種不完全的自定義 Web。
小程序是以下彩色部分的組合:
小程序的「trade-off」:
小程序的成功來自:
Web 的即用能力、部分跨平臺能力
Web 的部分分發(fā)能力
較低的上手門檻,一體化的良好的開發(fā)體驗
抽象程度高的 API(比如應(yīng)用框架,比如現(xiàn)成的、移動優(yōu)先的、原生 App 風格的 UI 實現(xiàn))
結(jié)合原生技術(shù)的性能優(yōu)化(相當于在自定義 Web Runtime 方面做的增強,其中網(wǎng)絡(luò)性能優(yōu)化起到的作用更大)
后 3 條跟 Web 不沖突,原本不需要「取舍」,可以在保持 Web 八大能力的基礎(chǔ)上做到這三條。
編輯:黃飛
?
評論