Google 开发者大会 2019:前端工程师的体验和收获

1,085 阅读10分钟

前言

源起

掘金翻译计划的译者群中,我看到有人分享了报名链接。于是,抱着重在参与报名的心态,花了五分钟在线填表报名,就忘了这茬事情了。8 月 21 日,又看到了几位群友分享了中签的好消息。本以为开发大会“与我无瓜”,第二天下班之后收到了一条短信!我居然也中了😆!

说明

我个人对排队体验 Google 的黑科技不大感兴趣,这次出行也没带相机拍照。如果你想更直观地了解新奇有趣的参会体验,我推荐你关掉这篇文章,去看看 Bilibili 上的 Vlog,比如这个视频;但是,如果你是像我一样入行不久的(萌新)前端工程师,平时没有太多机会接触 Web 前端的背景知识和实战技巧;我会与你分享一些自己的收获。

因本人水平有限,如有疏漏和错误还请见谅,非常欢迎问题和建议!

前端的道与术

Web:标准和 API 都在迭代进化

什么是 Web API

广义的 Web API 包含两类:浏览器 API 和第三方 API。 我们这里讨论仅指浏览器 API,以下是 MDN 中的一段介绍

浏览器API内置于Web浏览器中,能从浏览器和电脑周边环境中提取数据,并用来做有用的复杂的事情 。例如Geolocation API提供了一些简单的JavaScript结构以获得位置数据,因此您可以在Google地图上标示您的位置。在后台,浏览器确实使用一些复杂的低级代码(例如C++)与设备的GPS硬件(或可以决定位置数据的任何设施)通信来获取位置数据并把这些数据返回给您的代码中使用浏览器环境;但是,这种复杂性通过API抽象出来,因而与您无关。

这个解释很复杂?那么举个简单的例子,如果你对前端有所了解,你熟悉的 console.log() 方法,它就是一个 Web API,其功能是向浏览器的控制台输出内容。

百度就在他们的首页的代码里调用了这个 API

顺带一提,虽然偶尔有些繁琐,MDN 上的绝大多数文档对于前端工程师来说非常有帮助。如果你遇到使用搜索引擎之后还是毫无头绪的问题,不妨试试找找 MDN 的文档读读,也许有惊喜。

我们可以在 MDN 上看到 console.log API 的更多信息

本次大会中,Thomas Steiner 主讲了《实现适用于网络的新功能》,其中就提到了很多 Google 推进并实现的 API:比如说文件系统访问功能、联系信息选择器(可让用户有选择性地分享联系信息)、空闲状态检测功能、串行和 HID 设备访问功能等等。

新 Web 标准和新 Web APIs

在听演讲的时候,我就想到了经常被自己忽略的一个问题:新的 API 是怎么产生的呢?怎么保证除了 Chrome 以外,别的浏览器也兼容?

这就不得不提到两个组织:W3C 和 WHATWG。W3C 的全称是万维网联盟(World Wide Web Consortium),是制定互联网标准的组织。WHATWG 主要由浏览器厂商员工(Google、Opera、Mozilla、Apple)组成的开源社群,最近已经成为事实上的 HTML 和 DOM 标准制定者,如果你感兴趣,可以读读这篇新闻

xkcd #927

大多数人,比如曾经的我,可能会有一个误解:W3C 和 WHATWG 制定新标准,然后各大浏览器厂商实现 API。然而事实上,W3C 和 WHATWG 并不是这么运作的;Lea Verou 的《CSS 揭秘》一书中这样介绍 W3C(如果你对 W3C 的工作流程感兴趣,你也可以听听 Lea Verou 的这场演讲):

W3C 并不“生产”标准。实际上,它扮演的是一个论坛的角色:W3C 以工作组的方式,把某项技术的相关各方聚集起来,最终由他们来产出标准。当然,W3C 并不只是一个观察者:它设定了整个平台的规则,监督整个进程。但这些技术规范(基本上)并不是由 W3C 的工作人员编写完成的。

简而言之,每个具体标准都是具体的工作组(Group)完成的;工作小组才是标准的制定者;而工作组(Working Group)的成员绝大多数都来自 W3C 会员公司(比如说 Google)。除了工作组之外,还有兴趣组(Interest Group)和社区组(Community Group),这里就不多介绍了

在 Google 内部,为 Web 开发新功能的项目叫做 Project Fugu,演讲中提到的比如 Web Bluetooth原生文件系统 API,以及小巧的 Badging API 。这些未标准化的 API 已经在 Chrome 中实现了,并且通过 W3C 的 Web 平台孵化器社区组(WICG)生产了相应的报告。开发者大会本身,也正是推广 API 的好时机,只有让更多的开发者了解并使用了它们,才能促使这些 API 更快地成熟起来,并产生新的 Web 标准。

你很可能从未使用过这些 API,毕竟平时工作中不太可能使用它们。但这并不妨碍我们自己安装好最新版的 Chrome,到 Github 上找找 demo 或建一个玩具工程,试一试这些最新的 API。如果你能深入探索某个 API 就更好了。在不远的将来,新 API 被浏览器普遍实现并在生产环境中广泛使用时,说不定开发者会用上你贡献的 npm 软件包呢 😊?

API 是否实现和兼容性

在 Web 标准和浏览器 API 不断迭代更新时,一般的 Web 开发者关心的是如何了解 API 支持情况,能否在生产环境使用某个 API;我一般使用 MDN 和 caniuse.com。近期有个好消息:caniuse 引用 MDN 数据。caniuse + MDN,前端工程师双倍的幸福 😒!

此外,如果你发现某个 API 在某浏览器没有实现;其实也可以给浏览器维护者提功能要求(Feature Request);比如这个在 bugs.webkit.org 提交的关于实现剪贴板 API 的功能要求

这个 Feature Request 的真正起因:我问 Google 工程师为什么 Webkit 内核的 Safari 不支持剪贴板 API 😂

在 Web 展台与 Paul Kinlan 交流中,他提到了 Web 平台测试套件(web-platform-tests),这个项目是 W3C 主导推进的跨浏览器测试套件,使得浏览器项目能基于测试更加可靠地去实现标准。wpt.fyi 上可以看到目前的统计数据,由于测试套件未完成,这些数据并不能准确的反应浏览器对 API 的支持情况。但可以肯定的是,有了这些标准化测试,浏览器的 Web 标准实现不再是无法量化的黑盒子,API 跨浏览器兼容性问题也将成为历史。

Chrome Devtools:前端工程师的利器

Kayce Basques 主讲了《利用 Chrome DevTools 更快速地构建出色的网站》,这个演讲是我个人在本次大会中,感觉对日常开发实际帮助最大的演讲。作为一个前端工程师,好似受高人指点,进一步掌握了武功秘籍,将 Chrome 开发者工具这个神器发挥出更大的威力。

多看文档才会用得更好的利器

演讲中介绍了许多我已经知道的功能;但也有很多功能我第一次听说,以下演讲的幻灯片截图是其中的几个例子,如果有些功能你早已经知道,甚至经常使用,也不用感到奇怪,因为那是我个人的知识盲区。演讲中信息量很大,可能介绍了几十个功能点和技巧,强烈推荐观看一遍完整的演讲。

忘记了 CSS 属性名称也没关系,你只要记得属性本身就可以自动补全 CSS。

你不仅可以用浏览器截图,还可以给指定的 DOM 节点截图。

console.log 之外,你还可以调用这些方法。

说到调试程序;我刚入门前端的时候只会 console.log(),后来在学会了 debugger 打断点,使用 console.log 的次数就急剧减少了。而 debugger 断点仅仅是一种打断点的方式。在 Google 的官方说明中,介绍了七种不同的断点,中文的开发者社区也可以找到总结和分享,这里就不多介绍了。

接下来,我将用一个例子,介绍这七种方式之外一种的断点调试方法。它非常不起眼,Google 的文档中甚至没有详细介绍它(快捷键列表中列出了它),但它在这一次 Debug 中立了大功。

和 Google 工程师一起用 Devtools 调试 CSS

在 Web 展台,一位程序媛小姐姐向 Kayce 请教了一个问题,我在旁边看了一会也加入了讨论。经过一番研究,我们还是没能解决;Kayce 甚至都留下了邮箱,准备以后慢慢研究。我们聊起了别的内容时,Kayce 突然话题一转,“I just got an idea.” ,用了一个断点轻松搞定了这个问题。

现在就一起看看这个问题吧:这是一个使用 Javascript 实现的下拉选择框,鼠标移动滑过选项时,选项会高亮成蓝色。

通过 Devtools 审查元素,发现是通过添加 highlighted 类来显示高亮的颜色

现在我们想要修改这个高亮的颜色,所以我们准备添加一个类选择器 .highlighted;配置一个 background-color 属性,为了保证优先级我们加上了 !important 修饰符,结果看上去像这样:

然而,浮动选项的颜色并没有改变!

如果你熟悉 CSS background 属性,你可能已经猜到背景色没有变化的原因;可是,当时现场的我们都忽略了某个细节,没能想到这里的问题。

在轮到神奇的断点登场之前,先用一个 GIF 说明下,此前为什么我们没法直接在属性面板修改 highlighted 类,而是要手动加一个同名的类进行 CSS 覆盖(CSS overriding)。

鼠标移开,highlighted 类就消失了;强行指定元素状态也只是指定 CSS 伪类,在这里也没用。

在 Sources 选项卡中,有一排调试按钮,我们将使用第一个按钮,暂停脚本执行。

将鼠标移动到第一个暂停按钮,会提示它的快捷键 F8 / Command + B ( MacOS )

因为将鼠标移开后 highlighted 会消失,所以我们必须使用快捷键。打开下拉框并按下暂停快捷键后,我们就可以轻松地切换回 Elements 选项卡并进行进一步调试。我们点开相应的元素,background-color 不生效的原因一目了然:highlighted 类配置了 background-image 属性

在取消勾选其它会影响的属性后,我们之前设置的 background-color: red 生效了!

我觉得这个问题本身不复杂, CSS background 的知识也并不难,文档里都有说;但是整个调试的思路和使用快捷键暂停脚本的操作,需要一定的经验积累和灵感才能完成。我觉得这是一个很有趣的调试 CSS 的例子。如果你想自己试试,可以点击这里访问它的在线地址

总结

这次大会前端还有很多内容,比如 Google 近年来主推的 Flutter 和 PWA 都有几场演讲。在构思这篇文章时,我本想一个不落地介绍完;但成文后我发现内容已经有点多了,全部加入反而不美。此外,我未使用过这些技术,所以与其献丑不如精简掉。但愿自己在未来的日子里,能使用一下这些技术;或许在明年就可以更有自信地介绍相关的技术了!(Flag++🤣)

希望这篇文章对你有所帮助,感谢你的阅读!