BlinkOn9 - Layered APIs

简介:

作者在 4 月 18~19 期间和同事一起在湾区参加了为其两天的 BlinkOn 9 会议。每次 BlinkOn 都是了解当前 Blink & Chrome 和 Web 技术演进现状和发展方向的一个不错机会,两天的会议下来大概听了 6 ~ 7 场分享,有些主题是之前已经有所了解,这次又更新了最新的进展信息;有些主题则是完全陌生,在这次 BlinkOn 上才第一次知悉。作者接下来会撰写一系列文章,每篇文章针对一个特定的主题,尽可能把相关的信息回馈给读者。

对于 Layered APIs 作者事前并没有了解,不过听了BlinkOn9 的分享后觉得这个概念还挺有意思的,如果真的能够实现构建一个跨浏览器通用的标准库,覆盖 Web 开发的主要需求,对 Web 开发者而言当然是极大的利好。

Layerd APIs 提出的一些背景

提出 Layered APIs 这个概念的背景,跟可扩展的 Web 宣言有关,可扩展的 Web 宣言提出了可扩展的 Web 平台演进的一些设计准则 —— 更聚焦于提供 low level primitives API,更多暴露引擎底层的能力来赋能开发者,使得引擎的开发和维护成本更低,从而更聚焦于安全和性能,让 Web 技术的演进也更快。

SharedArrayBuffer and Atomics,还有 Houdini 项目里面的 CSS Paint API,CSS Layout API 就是遵循这些设计准则的很好例子。

如果把浏览器引擎类比于操作系统,这些所谓的 primitives API 差不多就类似于操作系统的基础 API,通常会比较难以学习和使用,所以它们更多是面向库或者框架的开发者,也意味着普通的 Web 开发者需要选择第三方提供良好封装,更容易使用的库或者框架。但是不同的库提供的 high level API 设计可能并不相同,使用上又各有其优缺点,性能,稳定性,兼容性表现上可能也有缺陷,Web 开发者不得不增加很多库的学习,使用,对比选择,甚至自己完善其实现的成本。

Layered APIs vs 第三方库

Layered APIs 与第三方库相同的地方在于:

  1. 它们都基于 JavaScript 实现;
  2. 都使用了同样的 primitives API,Layered APIs 不会使用特定的私有 API;
  3. 使用前需要显式加载到当前的运行环境,Layered APIs 不会做成默认内置;

起码 Chromium 目前的设计原则是这样的,但是其它 Browser Vendor 理论上并不受这个约束,它们可以自由选择是否使用 native 的实现。

Layered APIs 与第三方库不同的地方在于:

  1. Layered APIs 可能有很多不同的实现,但是在 API 层面上是一致的(包括签名和行为);
  2. Layered APIs 在 API 的制定上跟其它 Web API 一样,也需要经过相同的标准化流程,在各大 Browser Vendor 和参与讨论的 Web 开发者之间达成一致;
  3. 支持某个特定 Layered API 的浏览器引擎会提供内建的实现,也支持在没有内建实现的情况下 fallback 到外部的实现;
  4. 外部的实现开发者可以自由选择,包括 Browser Vendor 比如 Chromium 提供的开源实现,或者其它第三方的实现,甚至自己的实现;

所以 Layered APIs 的目标是成为 Web 开发的标准库,为主要的功能模块提供标准化的,易于使用的 high level API,跟引擎直接实现的 primitives API 一起构成完整的 Web API 集。它相对于第三方库保证了 API 的一致性,浏览器引擎内建的实现理论上也提供了更好的性能和稳定性,降低了 Web 开发者的学习,使用成本,和 Web 开发的整体成本。并且,如果使用内建实现也意味着减少了网络加载的时间,另外内建实现可以被预编译,也减少了 JavaScript 虚拟机编译的时间。

Layered APIs 的使用

<script type="module"
        src="std:virtual-list|https://some.cdn.com/virtual-list.js">
</script>

<infinite-list>...</infinite-list>

<script type="module">
import { storage } from
         "std:async-local-storage|https://other.cdn.com/als.mjs";

storage.get("key").then(...);
</script>

上面的代码显示如何使用 ES6 的模块加载语法来加载某个特定的 Layered API 模块,额外的语法支持让 fallback 到外部实现变得十分简单。

上述语法还没有最终定案,如果 Web 开发者有更好的建议,也欢迎去提。

Layered APIs 的现状

在 Chromium 内部,Layered API 还处于比较初期的概念验证的阶段。加载的语法大致已经确定,在 Chrome Canary 68 上已经可以使用。开发团队正在进行 virtual list(貌似改成了 virtual scroller) 和 async local storage 的开发,感兴趣的 Web 开发者已经可以尝试去体验。

目录
相关文章
|
JavaScript
vue element plus Checkbox 多选框
vue element plus Checkbox 多选框
589 0
|
JavaScript
Vue 使用 mockjs (返回数据、get、post 请求)
Vue 使用 mockjs (返回数据、get、post 请求)
480 0
|
存储 JavaScript Java
ROS CDK魔法书:点亮博客上云新技能(Java篇)
在阿里云资源编排服务ROS的Cloud Development Kit(ROS CDK)中,开发者可以使用编程语言(如TypeScript、Java等)定义云资源,简化了基础设施即代码(IaC)的管理。ROS CDK的Asset模块是用于处理本地文件到云端对象存储(如OSS)的工具,它通过元数据封装本地资源,然后配合ROS CDK的部署工具将文件上传至云端。通过一个将本地博客网站部署到OSS的案例,文章展示了如何使用ROS CDK的Asset模块和BucketDeployment来实现这一过程。
|
9月前
|
SQL 存储 运维
云端问道5期方案教学-基于 Hologres 轻量实时的高性能OLAP分析
本文介绍了基于Hologres的轻量实时高性能OLAP分析方案,涵盖OLAP典型应用场景及Hologres的核心能力。Hologres是阿里云的一站式实时数仓,支持多种数据源同步、多场景查询和丰富的生态工具。它解决了复杂OLAP场景中的技术栈复杂、需求响应慢、开发运维成本高、时效性差、生态兼容弱、业务间相互影响等难题。通过与ClickHouse对比,Hologres在性能、写入更新、主键支持等方面表现更优。文中还展示了小红书、乐元素等客户案例,验证了Hologres在实际应用中的优势,如免运维、查询快、成本节约等。
155 0
云端问道5期方案教学-基于 Hologres 轻量实时的高性能OLAP分析
|
存储 关系型数据库 MySQL
[重磅更新]PolarDB-X V2.3 集中式和分布式一体化开源发布
2023年云栖大会,PolarDB-X 正式发布 2.3.0版本,重点推出PolarDB-X标准版(集中式形态),将PolarDB-X分布式中的DN节点提供单独服务,支持paxos协议的多副本模式、lizard分布式事务引擎,可以100%兼容MySQL。同时在性能场景上,采用生产级部署和参数(开启双1 + Paxos多副本强同步),相比于开源MySQL 8.0.34,PolarDB-X在读写混合场景上有30~40%的性能提升,可以作为开源MySQL的最佳替代选择。
|
API
【threejs教程】threejs中的边边角角:几何体详解
【8月更文挑战第6天】threejs中的几何体详解
438 4
【threejs教程】threejs中的边边角角:几何体详解
|
算法 测试技术 持续交付
软件开发深度解析:从设计到单元构建
软件开发深度解析:从设计到单元构建
293 2
|
Ubuntu Linux 编译器
嵌入式linux系统应用开发
嵌入式linux系统应用开发
211 1
|
XML 测试技术 Linux
性能测试之Locust(完整版)
性能测试之Locust(完整版)
2694 2
|
JSON JavaScript 前端开发
Vue ElementUI操作 和 Axios使用
Vue ElementUI 和 Axios 内容分享。
380 0