要回答这个问题，首先需要了解Web 的三个要素。

Web 运行时前端技术URL

1.1 Web Runtime

第一个核心元素是“Web 运行时”。基于网络的内容或应用程序本质上是以高度抽象的方式实现、分发和执行的客户端软件。非常高级的软件抽象层。这个抽象层就是“Web 运行时”。

提供“Web运行时”的客户端技术可以分为四类：

传统浏览器：主导Chrome、Safari、Edge等桌面平台的应用层Web平台。 PWA（Progressive Web App）：基于全球主流OS层的Web平台，如YouTube的桌面应用、Premium Offline Access、BBC的UAP等。 WebView：操作系统层提供的Web功能API在移动平台上占主导地位，例如iOS上的WKWebView、Android上的WebView和Windows上的WebView2。跨端（混合）容器：国内主流应用层提供的Web功能API，如小程序、Kun、Weex等技术。在传统浏览器中，“Web 运行时”被称为“浏览器引擎”。互联网上的2D 浏览器传统上主要用于渲染具有交互功能的2D 图形和文本内容，因此“浏览器引擎”也称为“渲染引擎”。

1.1.1 浏览器

浏览器引擎对用户来说是“不可见的”，就像用于显示内容和软件界面的“空白画布”。用户可见的“可视浏览器”对应的就是地址栏的“图片框”。收藏夹和选项卡是帮助用户使用网络的“辅助工具”。

“有形浏览器”可以采取其他形式，可以提供各种“辅助工具”，并且不一定有地址栏，例如：

1.视觉搜索应用（Google Lens、Snapshot、抖音等）：将相机屏幕用作地址栏，使用视觉搜索（CV，基于AR 技术）找到您想要访问的网络。

2. 聊天机器人应用（微信、飞书、Messenger等）：使用聊天对话窗口代替地址栏，通过指令或自然语言（NLP）对话框（推入对话信息流）找到您想要访问的网页。 （以卡片的形式）。

3.信息流应用（今日头条、微博、Facebook、Twitter等）：通过信息流推荐算法访问网络。

在上述三种类型中，Snapchat的Snap Mini是一个典型的例子。

用户与朋友互动的地方就是Mini运行的地方（对话信息流、摄像头镜头）。

Mini 基于网络的HTML5 和JS 技术。创建Mini 类似于构建HTML5 网站，可用于实现从小工具到实时社交游戏的各种应用程序。

关于嵌入式物联网，有很多东西需要学习。如果你不学错路线或者内容，你的工资就会增加。

免费共享约150GB的数据包。学习内容、访谈、项目都比较新、广泛。据估计，在网上购买某些鱼至少要花费几十美元。

点此寻找助手0元获取：添加微信随时了解

4. Web OS（例如Chrome OS）：与独立的原生应用程序类似，您可以在OS应用商店、全局搜索等中找到Web应用程序，将它们“安装”在OS Dock中，然后单击应用程序图标打开相应的网络马苏。应用。

5.其他超级应用或跨端容器应用（美团、谷歌地图等）：通过不同的方式找到你想要访问的网页，例如黄页导航或地图上的POI。

我们通常所说的“浏览器”特指带有地址栏的传统浏览器应用程序。它继承了桌面平台的习惯和理解。因为在桌面时代，这种形式的浏览器几乎是唯一的“超级应用程序”。

自从移动互联网时代开始，它们不再是唯一的“浏览器”（不再是唯一提供Web运行时、提供Web应用平台功能的超级应用）。

上面的五种应用形式本质上都是浏览器，有些是比较现代的浏览器，有些是专门针对垂直领域进行优化的。

Web 运行时本身（“画布”部分）是最基本的“Web 平台”。

上面提到的提供Web运行时的平台级软件（Chrome、Chrome OS、微信、今日头条、飞书等）也是一个“Web平台”，可以在“画布”上添加自己的“框架”部分，从而使它更实用。一个更贴近业务领域和用户群的“网络平台”。

另一方面，一个平台与Web 运行时集成得越紧密，它就越具有“Web 平台”的功能和特性（例如，将Chromebook 与iPad 进行比较，后者也集成了浏览器引擎） ）。系统级）。

1.1.2 应用平台

Web Runtime作为最基本的“Web平台”，是一个标准化（“Web标准”）系统，隐藏了较低级别软件平台（例如不同硬件、不同操作系统和底层API）之间的差异。软件应用平台。 ），提供高水平的跨平台软件开发能力，开发成本和门槛普遍较低。

传统网络以超文本文档（交互式2D 图形和文本）中的内容为中心。

HTML（负责实现内容和结构）等标准化“标记语言”和CSS（负责实现外观）等“样式声明语言”是这种软件开发能力的核心。

Web 运行时提供：

布局引擎：根据Web标准，HTML从纯文本解析为由文档节点对象（DOM对象）组成的树状数据结构（称为内容树），并与CSS声明结合创建矩形（盒模型）。产生。树状数据结构（称为渲染树或框架树）经过自动布局（也称为布局或回流，简单地相当于布局图形或文本）并最终成为网页“绘制”内容。的。 Web 内容可以由多种媒体格式组成，包括纯文本、“超文本”（包含链接的文本）、图像、视频、音频和动画。网页内容默认交互行为：跳转链接和锚点、表单填写和提交：010 -69509

https://web.dev/howbrowserswork/

如果Web 运行时仅限于此功能，那么它就只是一个内容阅读器或播放器（尽管此功能也很重要）。

然而，在现代Web开发中，这些能力不仅有限，而且太抽象、太垂直（最初是为“内容”开发而设计的），而且不够灵活、不够强大，也不一定能适应你的“应用” 。发展需求是：经常被边缘化或隐藏。

更现代的网络以编程语言为中心。

我们软件开发能力的核心是两种标准化的原生Web 语言：JS (JavaScript) 和WebAssembly。

JS注重“生产端”和“DX（开发者体验）”来实现业务需求。 JS 还包括TypeScript 等变体。 WebAssembly 专注于“消费者端”和“UX（用户体验）”进行性能优化、底层处理以及非Web 程序的移植。 Web 运行时使这成为可能。

JS 引擎：可以标准化Web 原生语言执行的虚拟机。您可以使用该语言执行计算并调用Web API。这包括实时编译为本机机器代码以及基于执行结果的自动代码优化。垃圾收集和其他功能。宿主环境：事件循环不断运行，通过各种事件（页面加载、键盘鼠标点击、XR设备操作等）来驱动JS引擎内的Web程序。托管环境还提供标准化API。编程语言调用的API允许Web程序实现多种功能，包括： “输入”功能：监控人机交互事件、监控网络通信事件、监控本地读写事件等。 “输出”能力：UI布局、动画、2D或3D图形渲染、音频视频、本地存储、网络通信等

要了解Web 运行时，您还需要了解在其中运行的Web 应用程序。

1.1.3 Web 应用

为了避免术语“Web 应用程序”与下面“Web 应用程序”的狭义定义之间发生混淆，我们将在下面将其重命名为“Web 软件”。

当标准化网络软件被分发时，它是一堆各种格式的网络文件，由网络运行时通过标准化网络以标准化方式检索并以标准化方式解析和执行。

网页文件包括：

HTML文档：就像一个容器，它可以容纳内容和代码。这个“文档”文件与网络软件版本无关，可以独立修改。例如，更新内容以向不同的用户提供不同的内容。将您的代码静态更新到不同的Web 软件版本。 文件：在同一网络软件版本内不会改变。包含： 代码文件：由Web 运行时解析和执行。 JS 文件、WASM 文件（WebAssembly 代码）、CSS 文件资源文件：用于文档和代码。网络软件包括照片、字体、视频、音频、数据等。

不依赖标准化网络软件的网页：专注于“内容”，没有子页面（例如，许多H5 营销工作只有一个页面）。多页面网站：关注由通过链接连接在一起的多个页面组成的“内容”（因为这里的“页面”是一个业务和用户体验概念，而不是技术概念）（不一定对应于HTML 文档）。 Web App（狭义）：注重“功能”，类似于应用软件配置的粒度，可能比页面更细。 PWA（渐进式Web 应用程序）：离线优先，可安装的Web 应用程序。尽管它在您的浏览器中运行，但其外观和使用与浏览器无关。您可以获得与单独的本机应用程序相同的体验，同时仍然保留Web 应用程序的独特功能（有关特定功能，请参阅下文）。以上所有这些都是通过完全标准化的方法实现的。非标准Web 软件跨终端接口(HybridUI)：基于本机客户端Web 技术的接口。通常在客户端的WebView 中执行（尽管这种类型的Web 运行时是标准化的，但客户端通常会根据标准编写非标准的自定义扩展）。有些是以完全非标准的方式完成的（例如非标准运行）。 – 标准运行时，即本地运行部分或全部的“跨端容器”）分发方法通常是非标准的（例如，打包到客户端并以自定义方式分发）。典型的例子包括客户端内置的H5界面和小程序。打包应用程序：类似于混合UI，但不是单一界面。然而，这个容器是一个通用的“空壳”，不负责为网络提供服务。软件提供以下功能（包括标准化功能和基于标准增强的非标准功能）：一些打包的应用程序完全编译为本机应用程序。

标准化的Web软件必须运行在浏览器或其他具有完全标准化的Web运行时的客户端中，例如浏览器（如前所述，这个客户端实际上是浏览器，但在格式和功能上与传统浏览器不同）。

PWA 在“标准化网络软件”中是独一无二的，因为它们看起来“独立于”浏览器，并且可以像独立应用程序一样安装和运行。

标准化网络软件应包括所有特定于网络的功能（具体功能见下文）。

非标准网络软件完全独立于浏览器，通常包含非标准部分或完全非标准的运行方式。分发方法通常根本不标准。

非标准网络软件缺乏网络的许多独特功能。

请注意上图的含义。 “标准化的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

In the future, everything will run on JavaScript.

If we're living in a simulation, it too is running on JavaScript and is compiled down into quantum machine code.

— Lex Fridman (@lexfridman) February 12, 2021

前端技术在变强大的同时，也保持了直观、轻量、抽象、高效、关注产品和用户（面向人，而不是面向机器，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、Framer3D 设计工具：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 八大能力的基础上做到这三条。
写了这么多，希望各位朋友给个三连呀！
转载自：dexteryy
文章来源于重新理解 Web
原文链接：https://zhuanlan.zhihu.com/p/581977751