你应该了解的前端标准化

简介: # 前言## 前端诞生记截止2021年6月,全球已经有48亿互联网用户,占全球总人口的61%。前几天抖音宣布覆盖全球10亿互联网用户,但其实有一款100%覆盖48亿互联网用户的APP,它就是浏览器。1995年第一次浏览器大战,到98年IE统领浏览器,微软的IE达到了巅峰。随后便慢慢开始IE的市场地位被标准化的浏览器实现挑战,但是最有力的就是:FireFox,Opera,Safari三家。标

前言

前端诞生记

截止2021年6月,全球已经有48亿互联网用户,占全球总人口的61%。前几天抖音宣布覆盖全球10亿互联网用户,但其实有一款100%覆盖48亿互联网用户的APP,它就是浏览器。

1995年第一次浏览器大战,到98年IE统领浏览器,微软的IE达到了巅峰。随后便慢慢开始IE的市场地位被标准化的浏览器实现挑战,但是最有力的就是:FireFox,Opera,Safari三家。标准化浏览器,通过标准规范天然跟开发者亲和,逐步蚕食IE的市场份额。2008年Chrome 的推出敲响了第二次浏览器大战,Chrome通过崭新先进的技术架构和极致的性能,迅速引领标准化浏览器的实现,并且Google主动加入浏览器标准化组织,积极推进浏览器标准化,逐步Google占据标准化组织中的引导地位。随着2015年IE 推出edge采用了Chroumium,Chrome和Safari等为代表的标准化浏览器实现胜出。浏览器大战告一段落。现在的浏览器厂商都在标准化组织内,浏览器标准化实现相对稳定,开发体验不再分裂。浏览器实现统一,也产生了一系列的连锁反应:跨浏览器抽象兼容的类库JQuery等等逐步退出舞台,浏览器性能的提升也使得模型驱动的MVVM类库流行,从此专业前端职业诞生。

image.png

前端--保持对深水区的感知

image.png
前后端的开发其实有很多类似的,大致都可以分为3层。需要强调一下,这里并没有高低贵贱之分,只是大家关注的内容不同。
应用层开发,更加偏业务侧逻辑,关注业务逻辑/业务特性/业务领域建模,因此会有开发体验,用户体验,复用性和安全性等等作为衡量指标。
框架类库的开发,关注通用性和跨业务封装,因此衡量指标是:工程/工效,性能,稳定性,基础设施抽象,安全兜底。
而在前后端深水区差异还是比较大的。前端的运行时:浏览器,是一套完全由国际开源组织标准化的应用,而且标准规范对底层操作系统运行环境的封装非常完善,底层操作系统完全透明。后端的运行时的实现大多掌握在商业公司手中,标准规范对跨操作系统的通用能力做了封装,但系统级的开发,还是有大量的操作系统接口需要关注,因此要求对操作系统层还是要有所感知。

作为一名VUCA时代的前端,我们应该如何去了解浏览器,了解我们前端的代码运行时呢?
经历过浏览器2次大战,现代的浏览器都是基于标准规范实现的(除了还有少量存在的IE8)。因此从标准化的维度来分,浏览器大致可以分为3层:浏览器厂商与实现,标准规范,标准化组织。image.png

浏览器厂商与实现

image.png
2021年全球的浏览器市占比:Chrome+Chromium(IE edage, samsung等等)占有72%,Safari占有18.5%,FireFox+Opera占有5.8%,IE内核浏览器0.5%。

浏览器站队--这个新特性我能用吗?

image.png
现代浏览器厂商基本上已经二分天下了:谷歌为代表的实现开源派,chrome本身已经具备了65%的市场占有率,在加上chromium衍生浏览器的 7%的市场占有率,基本上是独领风骚,但Chrome却一直无法触动苹果为代表的实现闭源派的市场。FireFox和Opera虽然也是开源派的,但是在实现具体新特性时,有时站队Safari,有时站队Chrome。

Chrome和Safari是竞合关系,合作是对于已经确定的标准。竞争则是在默认行为的定义:例如第三方Cookie,SameSite,还有争夺未被标准化锁定的议题,例如新的WebP,HTTP3等等。Safari更加注重苹果的生态和安全性,Chrome更加注重谷歌的战略推进与发展。因此双方都会在标准规范层面,相互掣肘,确保自身的利益不被侵犯。典型案例就是第三方Cookie,明知道涉及隐私数据泄露,Safari/FireFox/Opera都已经默认禁止了,但Chrome因为涉及到Google搜索广告商的用户追踪和计费策略,加上替代方案的进展也不太顺利,一直推迟禁用第三方Cookie。

对于前端在业务中使用浏览器新特性,为了确保用户覆盖率,推荐先查一下CanIUse的。另外关注浏览器厂商的新版本/新特性也很重要,所以我们阿里巴巴前端委员会--标准化组 ,特意为大家提供了《了不起的Chrome系列》,为大家持续更新Chrome新版本release notes中值得关注的内容。

浏览器实现

作为我们前端的代码运行时:浏览器。了解浏览器的基本原理,更有利于我们定位问题和优化代码。
现代浏览器中,Chrome是开源的(基于Chromium)。我们介绍浏览器实现原理也将采用Chrome,以下内容和截图都来自谷歌开发者文档,大家如果有兴趣进一步学习更多细节,也可以阅读原文: Inside look at modern web browser

多进程模型

image.png
图片来源:Inside look at modern web browser

首先现代浏览器的实现都是多进程模型的,例如UI Process负责和我们交互的浏览器窗口,还有Network Process负责处理网络事务,Storage Process负责存储相关的事务等等,但最值得我们关注的还是Renderer Process渲染进程。我们打开每个tab窗口,就是一个独立的Renderer Process进程,而且进程间是相互隔离的。我们常见的CSS, HTML, JavaScript标准规范都在渲染进程里。

单Tab渲染进程中的多线程

image.png
图片来源:Inside look at modern web browser
在 Chrome中一个Tab窗口就是一个渲染进程,而一个渲染进程则是有多个线程组成的:主线程,Worker线程,Compositor线程,Raster线程。我们前端所熟悉的HTML,DOM树,CSS解析树,JS解析执行都在这一个线程中。主线程慢,页面就展现的慢。主线程奔溃,这个Tab窗口就奔溃了。我们常见的标准规范也都在渲染进程的主线程里。我们再进一步看看主线程是如何执行的。

主线程--单线程串行执行

image.png图片来源:Inside look at modern web browser

如上图所示,渲染进程的主线程,是一帧一帧的绘制的。大多数情况下,我们的刷新率都是60fps,也就是说每帧执行间隔为17ms。
我们前端的代码:HTML/CSS/JS,最终都在这一个线程中解析执行,因此我们的代码不阻塞进程就变得尤为重要。当然浏览器将这些细节隐藏的很好,我们大多数情况不需要关心这些细节,但如果遇到渲染慢或需要极致优化渲染性能的场景,就需要引入异步加载,WebWorker,分时分片处理等等手段。

现代的前端MVVM框架,核心的逻辑都在JavaScript引擎中执行,而我们如果想再进一步,可能会涉及JavaScript性能提升,就需要学习JavaScript引擎的知识。例如Chrome的V8引擎。推荐大家阅读秦粤老师的系列ATA文章:
浏览器的实现之所以这么复杂。其源头约束,都来自于浏览器的标准与规范。例如JavaScript的规范ECMAScript就限定了,它的实现是:弱类型的,动态解释执行的。因此才会有上图V8原理图中的,源码直接编译执行,而且还会在执行的过程中,不断优化代码的流程设计。

前端具体都有哪些标准和规范需要我们关注呢?

标准与规范

image.png
浏览器的标准和规范中,我们只关心与我们息息相关的部分:HTML, CSS, JavaScript的规范。

HTML和CSS是由WHATWG和W3C这2个开源组织维护,JavaScript是ECMAScript的实现,ECMAScript(即ECMA-262)是由ECMA的TC39技术组维护。
现在的HTML和DOM规范,主要都由WHATWG来维护。WHATWG还维护了Fetch API,Stream API, MIME type等等规范。而CSS,XHTML规范 ,则由W3C来维护。W3C还维护了SVG,XML, A11y等等规范。

JavaScript是ECMAScript的最著名的实现,我们前端熟知的ES6,也就是ES2015版本,目前全球的支持率已经高达98%了。因此我们的应用代码中大可去掉兼容ES5语法了,根据Google统计,单单代码去掉ES5支持平均可以提升JS代码执行效率12%。而且Google还做了一个工具检查网站去掉ES5支持后可以提速多少:https://estimator.dev/

对于上述和我们前端开发息息相关的标准和规范,我们应该熟知去哪里查询,常见的细节更加了然于胸。虽然我们也可以从MDN查询到简单的描述,但是如果要系统学习和了解更多的细节,还是需要查官方文档。HTML和DOM,访问WHATWG的官网查询:https://html.spec.whatwg.org/multipage/ 。CSS通过W3C-->Standards--> Web Design and Applications的HTML&CSS里面的CSS文档查询:https://www.w3.org/Style/CSS/ 。ECMAScript则通过ECMAScript官网查询:https://262.ecma-international.org/ 。熟练标准规范文档的查询,会让你对自己使用的底层接口掌握更多的技术细节,写出更加高效安全的应用。另外推荐大家阅读吞吞2片语雀文章:ECMAScript 规范文本阅读导引 part 1ECMAScript 规范文本阅读导引 part 2

对于标准和规范,我们熟练掌握和使用能解决日常大多数的问题。但是如果触碰到标准和规范的边界:例如发现一些规范实现的bug想去修复,某些标准相互冲突或者细节不太合理,甚至想引入推进一些新的议题扩展标准。这些都需要加入到标准化组织,才能推进。

标准化组织Jump in

标准化组织并不神秘,虽然都是开源组织,但是我们想参与到议题的修改和制定,还是有些门槛的。

W3C

W3C面向自己的会员开放,会员是机构为单位,会员加入W3C不需要获得委员会投票通过,申请即可,每年需要根据机构规模及营收情况支付年费。加入会员后,就可以参与到各类型的Group的中维护具体规范,例如CSS Working Group制定和维护CSS规范议题,A11y WorkGroup制定和维护可访问性的规范议题。Web技术跟国内互联网大厂紧密,因此国内大多数互联网大厂都已经加入了W3C,我们只需要找到公司内对应的负责人,即可申请加入。值得一提的是,阿里巴巴的标准化组朱红儒(茱滴)已经第四次当选W3C董事会成员。阿里巴巴可以联系:安琪。

ECMA

ECMA也是面向自己的会员开放,会员是机构为单位,会员需要申请,并获得ECMA的委员会投票同意加入,每年需支付年费。同样加入会员后,就可以参与到各个技术委员会TCs,影响相应的议题。例如ECMAScript就是由TC39技术委员会维护的。除了ECMAScript,ECMA的TCs维护着Dart,C++,C#等规范。相对于W3C,国内加入ECMA的大厂较少一些,360第一个加入ECMA之后,阿里巴巴紧随其后,今年字节跳动也加入了ECMA。阿里巴巴可以联系:吞吞和秦粤。

WHATWG

最难参与的标准化组织是WHATWG,WHATWG相对封闭,由核心浏览器厂商组成的steward进行管理,steward并不对外招收会员,由内部成员自己维护规范,但是通过Github issue的方式吸收社区的反馈意见,具体是否采纳社区反馈,由2-3名核心editor决定。

前置条件

个人加入标准化组织有三个前置条件:

  1. 英文好。W3C虽然有中文社区,但英文阅读和书写能力还是比较重要的。ECMA对非英语言更不友好,基本需要英语口语能力很强。
  2. 熟读标准和规范文档。在标准化组织中,这些文档是大家的基础背景知识,尤其是了解英文专业词汇。
  3. 有参与或者推进的具体议题。这点其实尤为重要,有切实具体的推进议题,才有动力持续克服议题推进的障碍,并在技术小组中维持活跃度。

议题推进过程

目前标准化组织的技术委员会或者工作组中,都由行业专家和业界大牛们在把关。包括浏览器厂商自己想推进一些议题,也没有那么容易,技术组中大家彼此之间更多的是博弈。因为任何一个简单议题,都可能会对整个前端生态影响深远,而且要防止整个技术组成为一言堂。所以我们有时反而很庆幸,还有Safari这样一个Chrome无法吞并的重要闭源浏览器,可以跟Chrome抗衡。推进议题,更多的是游说和文档的工作,将各方的意见能达成平衡统一后,就可以推进到下一个阶段。当然发展到现在,各个技术组中也已经存在大量无法达成共识的僵尸议题,因为各种原因无法继续推进。推进的后期阶段后,则是写文档和测试代码,最终浏览器厂商,会在未来的迭代中排期实现。
在标准化组织中成功推进议题,还是比较有成就感的。

阿里前端委员会在2020年就成功的将Error Cause议题推进到了Stage3,目前各大厂商的浏览器都已经实现支持了:

async function doJob() {
  const rawResource = await fetch('//domain/resource-a')
    .catch(err => {
      throw new Error('Download raw resource failed', { cause: err });
    });
  const jobResult = doComputationalHeavyJob(rawResource);
  await fetch('//domain/upload', { method: 'POST', body: jobResult })
    .catch(err => {
      throw new Error('Upload job result failed', { cause: err });
    });
}

try {
  await doJob();
} catch (e) {
  console.log(e);
  console.log('Caused by', e.cause);
}

总结回顾

image.png
浏览器标准化跟我们前端行业息息相关,现代浏览器是一个高度标准化的产品。各个浏览器厂商虽有竞争,但在标准化层面已经统一。所有浏览器的实现都受到标准规范的约束,这些标准和规范,提供给了我们前端一个稳定的系统基座。这些标准和规范的具体议题,则是由开源组织中一堆的行业专家和业界大牛们坚定的维护,浏览器厂商要推进新特性,也需要再标准化组织中相互博弈妥协。

其实标准化组织也是开源组织,前端的生态是非常开源友好的。即使大家没有机会参与前端标准化,其实也可以通过参与前端开源项目,维护前端生态的发展的。最后希望前端们应该对浏览器的实现和标准规范层有认知,如果有具体的业务场景和诉求涉及到标准和规范,欢迎大家加入标准化组织。另外更希望大家可以坚持贡献开源社区,共同维护前端的基座,推进行业发展。

image.png

目录
相关文章
|
7月前
|
前端开发 JavaScript Java
从前端到后端:构建全栈应用的技术路线探析
【2月更文挑战第3天】本文通过探讨前端和后端开发的基本概念和技术要点,深入剖析了构建全栈应用的技术路线。从前端的HTML、CSS和JavaScript,到后端的Java、C和数据库,我们将带您逐步了解如何将不同技术组合起来实现高效、稳定的全栈应用。
193 7
|
监控 安全 网络安全
标准化
一、标准化 标准化是指通过制定统一的规范和标准,对特定领域的产品、服务、过程等进行规范和统一。在网络安全领域,标准化起到了重要的作用,可以提供一致的安全要求和指导,促进安全技术的发展和应用,增强网络安全的可信度和互操作性。 网络安全标准化的主要目的包括: 1. 统一安全要求:通过制定统一的安全标准,明确网络安全的要求和指导,为各个组织和企业提供一致的安全基准。这有助于降低安全风险,提高网络安全的水平。 2. 促进技术发展:标准化可以推动网络安全技术的发展和创新。通过制定标准,可以促进安全技术的研究和应用,推动新的安全技术和解决方案的出现,提高网络安全的能力和效果。 3. 增强互操作性:网络安全
98 0
|
7月前
|
人工智能 运维 搜索推荐
软件定制开发与标准化产品的比较及选择
随着信息技术的不断发展,软件已经成为企业运营中不可或缺的一部分。而在选择软件时,企业用户通常面临两个选择:软件定制开发和标准化产品。软件定制开发和标准化产品各有其优缺点,以下是对两者的比较和选择:
|
小程序 前端开发 Java
【平台开发】技术整合思考(四)前后端不分离
【平台开发】技术整合思考(四)前后端不分离
240 0
|
存储 机器学习/深度学习 Kubernetes
前端设计走查平台实践(后端篇)
设计师在进行走查的过程中,肉眼的比对偶尔会忽略一些细微部分,同时也会耗费设计师大量的精力,为了辅助设计同学能够更高效的进行设计走查,本文旨在通过设计走查平台在后端侧的实践总结下对于视觉稿还原程度比对的一些思路。
129 0
|
前端开发 数据库 数据安全/隐私保护
【平台开发】— 5.后端:代码分层
【平台开发】— 5.后端:代码分层
【平台开发】— 5.后端:代码分层
|
7月前
|
Prometheus 监控 Cloud Native
基于 OPLG 从 0 到 1 构建统一可观测平台实践
“可观测”是近几年比较火的一个议题,而 OPLG 就是包含了 OpenTelemetry、Prometheus、Loki 和 Grafana 在内的开源可观测技术合集,它们之间将碰撞出什么样的火花?请阅读本文介绍的基于 OPLG 从 0 到 1 构建统一可观测平台实践。
212 0
基于 OPLG 从 0 到 1 构建统一可观测平台实践
|
消息中间件 供应链 监控
业务团队如何形成统一的设计风格
首次上线应用,面对业务框架搭建你是否曾感到无从下手?维护线上应用,面对大量历史包袱你是否正避坑不及深陷泥潭?为何同样是业务应用,不同人的设计风格千差万别?为何最初的设计经过多个迭代后总是面目全非?新人来到团队,怎样才能快速了解业务,不被大量技术细节折磨?如果你也有这些困扰,希望本文能提供些许帮助。
403 2
|
存储 编解码 Kubernetes
基于AutoTagging技术实践 构建统一的可观测性数据平台
混合云以及容器逐渐成为承载微服务应用的主要基础设施,对于云原生应用的监控保障,也面临诊断难、规模广、弹性大、波动性强等挑战,这些挑战同时也使得云原生应用可观测性成为了运维开发关注的焦点。基于云杉网络在混合云网络场景下的多年实践,给大家分享在构建统一的云原生应用可观测性数据平台中的一些思考和经验。
424 0
基于AutoTagging技术实践 构建统一的可观测性数据平台
|
监控 关系型数据库 MySQL
关于质量标准化的思考和实践
最近部门在推质量标准化,通过质量标准化,推动质量内建,从而提高研发部门的交付质量,作者深度参与其中,并在推进过程中总结了一些经验以及思考,在此通过以下定义、共识、实践三个大方向和大家分享一下。
关于质量标准化的思考和实践