前端技术演化史

Web平台能力演进史

Properties1
tagsweb平台, 标准, 标准化回潮, 总览, 技术史

11分钟阅读

🌊 Web 平台能力演进史

一句话定性

这是一部**“平台原生能力收编框架功能”的潮汐史**。框架先用 JS 在用户态造轮子(组件、路由、状态、动画、打包),浏览器原生能力成熟后,再把这些能力一项项”沉”进平台内核(Web Components 之于组件、原生 ESM 之于打包、View Transitions 之于动画、:has()/容器查询之于布局)。这条主线和语言层的 ECMAScript演进史、模块层的 ES-Modules 讲的是同一个故事:野蛮生长 → 标准追认。但本专题要揭穿一个残酷真相——标准赢了理念,不等于标准赢了生态。

一、母题:野蛮生长 → 标准追认的潮汐

前端三十年有一条贯穿始终的暗线,可以叫它**“标准化潮汐”**:

   社区/框架在真空里野蛮生长(造轮子)
                │
                │  某个能力被广泛验证、形成事实标准
                ↓
   标准委员会(W3C/WHATWG/TC39)把它"追认"为平台原生能力
                │
                │  浏览器逐步内置,框架的同名功能从"必需"变"可选"
                ↓
   框架要么拥抱原生(变薄),要么因体验/生态惯性继续自己干

这不是巧合,而是 Web 的结构性宿命

Web 平台的演进受两条物理定律级约束支配:

  1. 向后兼容铁律:永不破坏旧网页 → 标准只能做”加法”,且制定极慢(详见 ECMAScript演进史 里 ES4 的惨痛教训)。
  2. 多厂商共识:任何原生能力要四大浏览器都实现才算”能用”,这天然落后于”一个 npm 包就能装”的框架。

这两条约束决定了:平台永远落后于框架。框架是 Web 的”前沿实验场”,平台是”事后追认者”。所以你看到的每一个”浏览器新增能力”,几乎都能在更早的某个 JS 库里找到原型。

二、四组”框架先跑、平台追认”的对照

能力维度框架先造的轮子(野蛮生长)平台后来的追认(标准内置)追认时间
组件化React/Vue 私有组件模型、JSX/SFCWeb-Components(Custom Elements + Shadow DOM)v1 约 2016–2018
模块/打包Webpack/Browserify 把 CJS 打成大文件原生 ES-Modules(<script type=module>)约 2017–2018
动画/过渡React Transition Group、Vue <transition>、FLIP 库View Transitions API约 2023(Chrome)
布局/样式CSS-in-JS 的运行时父子查询、JS 测量容器宽度:has() 父选择器、容器查询(Container Queries)约 2022–2023

读法:每一行都是"先有 JS 方案,后有平台方案"

注意时间差——框架方案往往比平台方案早 5～10 年。这正是母题的核心:平台不是创新者,是收编者。它把社区跑通的实践”标准化”,换来的好处是零运行时、跨框架、永久可用;代价是慢、保守、且常常错过生态窗口期。

三、本专题的三个主角(本组互链)

本专题聚焦三项最能体现”平台想要原生能力”的努力:

  1. Web-Components —— 组件化的原生标准。理念最先进、生态最失败的典型,是整条母题里最值得反复咀嚼的案例:标准很好,却没赢过 React/Vue。
  2. PWA —— Web 想拥有 App 的能力(离线、安装、推送)。Google 2015 年提出,理念宏大,却被 iOS 的保守支持和商业模式现实卡住。
  3. WebAssembly —— 打破”前端只能用 JS”的天花板,让重计算应用(Figma、Photoshop Web、浏览器端 AI 推理)成为可能。它是本组里**少数”平台提供了框架根本给不了的东西”**的案例。

其中 Service-Worker与离线能力 是 PWA 的技术基石,单独成篇——它是”网页必须在线”这一古老假设的终结者。

                    Web 平台能力演进史(本篇)
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
   组件化原生标准          App 化能力             性能/语言天花板
        │                     │                     │
  [[Web-Components]]      [[PWA]]            [[WebAssembly]]
   (理念赢,生态输)          │              (平台真正补了短板)
                              │
                      [[Service-Worker与离线能力]]
                       (离线/缓存/后台同步的基石)

四、为什么”标准赢理念”≠“标准赢生态”

这是本专题最想讲透的一点。平台原生能力在”理念正确性”上几乎总是赢的——它跨框架、零依赖、零运行时、永久兼容,符合所有第一性原则。但理念正确不代表能赢得开发者:

标准的三个"先天劣势"

劣势框架方标准方
迭代速度一个 npm 版本即可改 API需多厂商共识 + 永不破坏旧网页,以年为单位
开发体验(DX)围绕框架打磨工具链/调试/类型原生 API 常常啰嗦、缺糖、调试工具滞后
配套生态状态管理、路由、SSR、UI 库全家桶标准只给”原语”,上层生态要社区自己补(而社区已被框架占领)

Web-Components 输给 React/Vue,输的从来不是理念,而是这三点。生态是有惯性的、有网络效应的;当平台姗姗来迟,开发者早已用框架建好了家,搬不动了。

五、潮汐的另一面:平台变强,框架变薄

标准化回潮不是”平台干掉框架”,而是重新划分二者的边界——平台把”原语”层吃下,框架退守到”体验/约定/全栈”层:

  • 原生 ES-Modules + 浏览器原生加载 → Vite 的 no-bundle dev server 成为可能(平台能力反哺工具链)。
  • 原生 :has()/容器查询 → 削弱了 CSS-in-JS 的部分运行时刚需。
  • 原生 View Transitions → 框架的过渡库变成”薄封装”。
  • WebAssembly → 让”前端不只能用 JS”成立,催生了一整类重应用。

这正是 未来5到10年前端发展方向 预测的七股力之一:Web 标准回潮

趋势是:平台越来越强,框架越来越薄。框架的价值从”提供能力”转向”提供约定与体验”。但”框架消失论”是错的——只要 DX 和生态惯性还在,框架就有存在理由。平台与框架不是替代,而是层级下沉:今天的框架特性,是明天的平台原语;明天的框架,会在更高的抽象层重新长出来。

六、本专题与全局的因果链

语言层:JS 出生无模块 → 社区造 CJS/AMD → [[ES-Modules]] 追认([[ECMAScript演进史]])
   │
   │  (同一个"野蛮生长→标准追认"的潮汐,在不同层反复上演)
   ↓
组件层:框架私有组件([[React]]/[[Vue]]) → [[Web-Components]] 追认(理念赢/生态输)
   │
模块层:[[Webpack]] 打包 → 浏览器原生 ESM 追认 → 反哺 [[Vite]]
   │
能力层:JS 模拟 App 能力 → [[PWA]] + [[Service-Worker与离线能力]] 追认(被 iOS 卡住)
   │
性能层:JS 性能天花板 → [[WebAssembly]] 突破(平台真正补短板)→ 浏览器端 AI 推理([[2023-未来 AI时代]])
   ↓
结论:平台是收编者,不是创新者。
      标准化潮汐永不停歇,但"标准赢理念"≠"标准赢生态"。

历史地位

如果说 前端框架演进史 讲的是”框架如何彼此埋葬”,那么本专题讲的是框架与平台之间更慢、更深的拉锯。框架是 Web 的实验前沿,平台是它的记忆与沉淀。读懂”平台总在追认框架”这条潮汐,你就不会再为”又出新框架”焦虑——因为真正稳定的、值得长期下注的,是那些正在从框架沉淀进平台的能力。

🔗 本组:Web-Components | PWA | WebAssembly | Service-Worker与离线能力 🔗 同一母题:ECMAScript演进史 | ES-Modules 🔗 时代:2013-2018 SPA时代 | 2018-2023 工程化时代 | 2023-未来 AI时代 🔗 框架/浏览器:前端框架演进史 | React | Vue | Svelte | Chrome | 浏览器演进史 🔗 趋势:未来5到10年前端发展方向

关系图谱

反向链接