Jeremy Wagner 的 Smashing Podcast 第 45 集：什么是负责任的 JavaScript？

这一集得到了我们在 Wix 的亲爱的朋友的大力支持，Wix 是专业人士建立客户网站、管理复杂项目和在线发展业务的平台。 谢谢！

在这一集中，我们将讨论负责任的 JavaScript。 代码负责意味着什么，我们应该如何以不同的方式处理项目？ 我与专家杰里米·瓦格纳（Jeremy Wagner）进行了交谈以找出答案。

显示注释

• 负责任的 JavaScript 网站
• 从 A Book Apart 购买这本书
• 杰里米的个人网站
• 杰里米在推特上

每周更新

• 史蒂文·胡伯 (Steven Hoober) 所写的接触时代的菲茨定律
• 网页设计做得很好：Frederick O'Brien 写的完全没有意义
• Nick Babich 和 Gleb Kuznetsov 编写的关于创建语音用户界面的一切你想知道的事情
• WordPress 加入由 Leonardo Losoviz 编写的块协议的意义
• Knut Melvar 写的关于 Markdown 的思考

成绩单

Drew McLellan：他是一名技术作家、网络性能书呆子、开发人员和演讲者，目前在 Google 工作。 他为 A List Apart、CSS-Tricks 和 Smashing Magazine 撰写文章，并且是新书名“Responsible JavaScript for A Book Apart”的作者。 所以我们知道他是一位熟练的技术人员和沟通者，但你知道他想在立式桨板上环游地球吗？ 我的好朋友们，请欢迎杰里米·瓦格纳。 嗨，杰里米，你好吗？

杰里米·瓦格纳：我太棒了。 你好吗？

德鲁：我很好。 谢谢你。 今天我想和你谈谈负责任的 JavaScript 的想法。 这是某种新的方法或技术，还是您实际上是在谈论负责任地使用 JavaScript？

Jeremy：我实际上是在谈论负责任地使用 JavaScript。 因此，根据 HTTP 存档，我们看到去年移动设备下载的 JavaScript 量中位数增加了近 58%，从大约 290 KB 增加到近 500 KB。

德鲁：哇。

Jeremy：所以当我谈到负责任地使用 JavaScript 时，它是一种用户至上的方法，可以说……批判性地评估我们正在构建的内容以及我们正在构建的目标是现代 Web 开发实践所服务的目标，所以说话。 而且我想这有点……也许不是开玩笑，但我并没有对现代 Web 开发进行抨击，但现代 Web 开发的一个副产品是向项目添加依赖项非常容易。 一切都是 MPM 安装，每个 MPM 安装都有成本，成本各不相同。 但我们确实看到的是，在 HTTP 存档数据中，第 95 个百分位……意味着 5% 的体验是最慢的……或者不是最慢的，但交付的 JavaScript 最多，在去年增加了约 875千字节到大约 1.4 兆字节。

德鲁：哇。

Jeremy：所以它是大量的 JavaScript 被传输，它对加载性能和运行时性能都有影响。

德鲁：所以你提到了那里的表现。 在我看来，现代网络体验就像 10% 的 HTML 和 CSS 以及 90% 的 JavaScript。 并且必须有某种性能考虑。 我的意思是，你谈到了我们正在传输的数据量，但还有其他性能考虑因素，因为有很多 JavaScript。

杰里米：对。 因此，互联网连接速度很慢，您知道……我住在美国的哪个地方，如果您在大城市以外的地方走得足够远，则取决于去哪里，这会变得有点困难……仅应对互联网的速度有多慢有点像这些农村地区，并且对生活在这样的地区的人们很重要。 因此，当您开始交付数兆字节的 JavaScript 时，它的加载性能方面已经具有足够的挑战性，但您也可能正在与没有 iPhone 的人打交道……比如 iPhone X 或 iPhone 13。

杰里米：他们可能只是在功能手机上，或者只是有点像廉价的 Android 手机，只是试图在生活中导航。 我的意思是，想想诸如网上银行、失业援助或其他政府援助之类的东西，诸如此类的应用程序门户。 在线学习，在很多地方，过多的 JavaScript 确实会对那些可能没有足够幸运生活在大都市地区甚至没有宽带互联网服务的都市地区以及使用速度较慢的设备的人产生不利影响. 我有点认为作为开发人员，我们有这种倾向……我们购买 MacBook 或这些高端设备，但有时我们并没有真正看到当我们过度使用 JavaScript 时这些问题会出现在哪里。

德鲁：就像你在那里提到的那样，有时是那些因无法访问服务而遭受最大损失的个人会受到此类事情的惩罚。 那些没有快速数据连接或没有功能强大的设备的人有时会访问对他们来说意味着一切的服务……这对他们来说意味着他们能够访问的一切。 所以它在某些方面几乎成了一个人权问题。

杰里米：是的。 我的意思是，我们倾向于看到 Web 性能以商业价值为框架。 我是一些电子商务公司的绩效顾问，就像一家大型食品公司，一家大型电子商务公司……就像一家商店，一家电子产品店，这样做很诱人，对吧？ 因为当你为一家企业工作时，我的意思是，显然你希望财务状况良好，而我认为网络性能确实在其中发挥了作用。 我认为有许多案例研究证明了这一点。 然而，有人性的方面，甚至对于企业来说，比如杂货店之类的东西。 是的，他们是收入驱动的。 他们希望拥有健康的财务状况，因此 Web 性能是其中的一部分，但他们也在满足关键需求，对吧？ 就像你必须吃饭，对吧？

杰里米：就像有些人可能出于某种原因回家一样。 他们可能无法轻易上车。 他们可能没有车。 因此，他们依靠这些服务来获得生计，但更重要的是，如果他们需要帮助，尤其是危机干预之类的事情，他们会得到帮助。 我不认为说一个被虐待并被赶出家门的伴侣可能会转向他们的智能手机，并点击谷歌试图找到一个危机干预和援助的门户网站，这并不是很牵强。 而 JavaScript 可能会妨碍这些类型的目标并满足人类的需求。 当我们倾向于过度依赖它时。

德鲁：我的意思是，在过去 18 个月左右的时间里，我们已经看到了这种情况的一瞥，因为 COVID 和人们进入隔离状态，正如你所说，需要订购要交付的杂货。 那时，网络成为他们的生命线。 他们感觉不舒服，无法离开住处，因为他们正在隔离，他们必须得到食物，他们必须得到必需品。 所以，是的，我认为，对于我们所有人来说，它是日常生活中越来越重要的一部分。

杰里米：没错。 回到那种设备故事，Tim Kadlec 几年前写了一篇很棒的文章，我想那是两年前，也许是三年前，但它被称为优先考虑性能的长尾。 当你看到那个......所以用网络性能术语来说，我们有点谈论实验室数据与现场数据。 实验室数据就像您在运行灯塔或在网页测试中投放网站以查看其运行情况。 这些都是非常有用的工具，但是当您查看这些现场数据时，您真的开始获得更大的图景，并更深入地了解您的受众到底是谁。 在这篇文章中，Tim Kadlec 谈到了优先考虑性能的长尾意味着什么。 这意味着所有这些设备……可能不如我们开发人员可能拥有的设备那么强大和强大。

杰里米：那篇文章背后的想法是，如果我们能够专注于 90% 或 95% 的人……并改善这些人的体验，我们正在为每个人构建一个更快的网络，包括那些使用快速设备的人。 并攻击美国的一个数据点，这就像 statcounter.com 一样。 大约 28 点……大约 28% 的人使用的是该工具捕获的 iOS 设备。 其中大约 21% 是安卓系统。 Android 往往代表了设备长尾中的很大一部分，因为 Android 不是单一的。 多家设备制造商生产 Android 手机，但与世界形成对比，因为世界不仅仅是美国，大约 16% 的人使用 iOS，大约 41% 的人使用 Android。 因此，优先考虑那些较慢或可能较慢的体验确实值得。

德鲁：我在你的书中读到了关于设备热节流的内容，这在我之前从未真正考虑过。 有什么顾虑？

杰里米：那里的担忧，无论如何我都不像微处理器专家。 我只是一个可能写得有点多的网络开发人员，但是......所以热节流背后的想法存在于所有系统中，不仅仅是手机和平板电脑，是微处理器将......当它承担过多的工作负载或实际上只是一般的工作量，这项工作的废物是热量。 所以设备有办法缓解这种情况。 就像您的笔记本电脑同时具有被动和主动冷却设备一样。

杰里米：所以就像一个被动冷却设备就像一个散热器或某种散热器。 而它的活跃部分就像一个风扇，可以更有效地散热。 一些像定制 PC 构建可能会使用像液体冷却，这是一个比较极端的例子，但手机没有这个，因为如果便携性是你的一种，你将在哪里真正适合风扇东西，对吧？

Jeremy：所以为了让这些设备应对这些繁重的工作负载，他们可能会人为地降低处理器的速度，比如降低时钟频率，直到设备进入可以提高时钟频率的状态。 这会产生影响，因为如果你正在咀嚼大量的 JavaScript，你就会像这些大块一样从网络上下来，这会开始处理，对吗？ 因此，在编译和执行中通过评估和解析进行了大量处理。 如果你用 1 兆字节或 2 兆字节的 JavaScript 来做这件事，并且你有很多其他进程在后台运行，比如不同的选项卡，那种类型的东西，可以让你的状态......设备可能会进入热节流状态，这意味着它将无法承担额外的工作。

德鲁：所以这是一种负反馈循环。 不是吗？ 你让设备做很多工作。 它变得非常热，然后实际上执行该工作的能力降低，因为它不得不节流。

杰里米：对。 再说一次，我不是微处理器专家。 我敢肯定，如果一位非常熟悉这一点的工程师可能会纠正我的一些细节，但总的想法是，是的，随着环境压力的增加，该设备不太能够应对这些繁重的工作量，直到压力降低。

Drew：所以我们正在为最新的 Apple M1 Max 的各种设备编写 JavaScript，这是新的处理器，不是吗？ 从笔记本电脑一直到几乎没有足够的工作 RAM 来呈现网页的设备。 但网络并不是这样开始的，年轻的听众可能有兴趣知道我们过去完全不用任何 JavaScript 来构建交互式网络体验。 我们庞大而沉重的框架将成为我们的毁灭。

Jeremy：我想说框架是有时间和地点的，那些读过这本书节选的人可能会认为我是反框架的。 我肯定对几个框架持批评态度，但它们确实是有目的的，并且可以以保持良好用户体验或可以带来良好用户体验的方式使用它们。 但我认为我们做的还不够多，就是根据它们如何损害……运行时性能来批判性地评估这些框架，对吧？ 所以我正在谈论的东西类型，如果你点击一个按钮，设备需要大约一秒钟或者两秒钟来响应那个输入，因为在后台发生了很多事情。 你有第三方 JavaScript 东西，比如收集分析，然后你有其他东西在线程上运行。

Jeremy：如果你不严格评估框架的运行时性能，你可能会留下一些机会来更好地为你的用户服务。 所以一个很好的例子，我总是喜欢使用 react 与 pre-act。 我一直在敲这个鼓有一段时间了。 不久前，我为 CSS-Tricks 写了一篇文章，描述了一个基本的点击交互，比如移动导航菜单。 这听起来微不足道，但您会发现，在所有设备上，React 提供了更好的运行时性能，但它具有基本相同的 API。 有一些差异，有一些细微的差异和东西可以用预演兼容来掩盖，但是很简单……我不应该说一个简单的选择，但是那个选择，那个基本的选择可能是体验之间的差异这对所有用户或至少对大多数用户都非常有效，或者只对某些用户有效。 希望这有点道理。]

Drew：我的意思是，有了所有的框架和构建工具，他们似乎一直在做一些事情，比如摇树和优化他们发布的包以及如何将它们交付给浏览器。 在使用大型框架时，您是否认为自己正在编写如此庞大的应用程序，以及您自己的代码如此之多，以至于框架由于其所有抽象性而使您能够交付更少的代码？

杰里米：这是一个很难回答的问题。 一方面是框架本身代表了您永远无法优化的大量代码。 因此，拥有一个精简的框架，比如 pre-act 或任何数量的类似......或者像拼写一样，这很有帮助。 但我看到的问题是，我认为来自 HTTP 存档的数据支持这一点是，似乎每当我们在微处理器和网络方面取得这些进步时，我们都倾向于消耗这种收益，对吗？

杰里米：我们往往只是在这台跑步机上，我们从来没有真正进步过。 而且我不知道，就像我对……的历史没有千里眼，或者对不起，框架的未来是什么样的。 我确信可以收集到一些效率收益。 但是我们在该领域看到的原始 JavaScript 的数量……只是使用了原始 JavaScript 的数量。 并没有告诉我这是一个我们可以自动化解决的问题。 我认为我们必须……我们必须成为人类，进行干预并做出符合用户最大利益的决定。 否则，我看不到我们离开跑步机，也许在我的职业生涯中，但我不知道。

Drew：在书中，您谈到了网站和 Web 应用程序，以及了解差异以及您正在使用的应用程序如何帮助您选择开发和优化策略。 告诉我们一点。

杰里米：这是一个非常好的问题。 我在我为 A List Apart 撰写的同名文章中写到了这一点，名为“负责任的 JavaScript 第 1 部分”，这是本书的前奏。 是不是我们在这个术语中加载了很多东西。 就像作为一名技术作家一样，我看到两者可以互换使用。 我看到的是网站，这意味着它是一种多年龄的体验，对吧？ 它是文档的集合。 现在是一个文档……这些文档可能嵌入了这些小岛之类的功能，就像最近的术语一样，这些功能小岛可以让人们完成工作。

杰里米：但是还有像网络应用程序和网络应用程序有点像功能这样的原生应用程序的内涵。 所以我们谈论的是单页应用程序，我们谈论的是大量的 JavaScript 来驱动复杂的交互性。 有时网络应用程序模型是有意义的。 例如，Spotify 就是一个很好的例子。 这作为一个网络应用程序效果更好。 您不会真的想尝试使用它或将其设计为多页应用程序。 就像一个传统的网站，但我认为这不是一个可持续的默认设置，因为当你对每个项目的默认设置是，“好吧，我们只需要发布一个单页应用程序，比如客户端路由器和重型框架，然后卸载所有这种从服务器渲染到客户端的处理过程。” 我认为这就是您开始达到将用户排除在外的地步，尽管是无意的，但仍然排除了他们。

德鲁：有没有很大的鸿沟，你认为采取我们将发布一个网站并且它可能具有任何交互功能的人与那些说“我们是一家软件公司，我们是制作产品、软件产品和我们将通过 Web 交付它的平台，而不是用于多个平台的本地应用程序。” 他们是否有可能以完全不同的方式解决问题？ 考虑因素是否因您当时的观点而异？

杰里米：这是一个棘手的问题。 所以-

德鲁：我很难说。

杰里米：我会说一家公司……这样一个很好的例子就像新闻一样，对吧？ 这种网站模型很好地服务于它们，因为它实际上是文档、文章的集合。 开发这些体验的人可能会拥有不同的技能组合，而不是像 Spotify 这样的公司或拥有像 Envision 这样的大型 Web 应用程序或类似事物的公司。 所以，是的，我认为他们会从不同的角度来解决这个问题。 我看待它的方式是有一个细分市场……或者至少这是我对整个 Web 开发社区的看法，即有一部分人，来自非传统软件开发的 Web 开发人员背景，对吧？ 我就是这些人中的一员，当我还是个孩子的时候，我正在修补网络，对吧？

杰里米：就像在中学时一样，为所有人做愚蠢的粉丝页面，就像我当时真正喜欢的电子游戏一样。 而且我从未接受过那种计算机科学教育。 在此过程中，我学到了一些计算机科学概念。 然后还有一部分开发人员，尤其是我认为在过去 5 到 10 年出现的开发人员，他们以更加面向计算机科学的方式来处理这个问题。 而且我认为这将……这些差异和经验将引导每个小组就如何最好地为网络开发得出自己的结论。 但我认为，你真正能够……为网络进行可持续开发的唯一方法是批判性地评估你正在构建的内容，并尝试围绕最能为这些产品的用户服务的方法进行调整。 当我评估这些东西时，这就是网站和网络应用程序模型在我脑海中的位置。

德鲁：是的。 很有趣。 我的意思是，在书中，你实际上引用了我的一些工作。 非常感谢。 我选择的枯燥技术基本上是 PHP Apache 和少量的手工 JavaScript，默认情况下可以创建非常快速的用户体验，而无需进行任何特定的优化。 我认为这为来到网站上查看内容的前端访问者提供了良好的用户体验。

Drew：但实际上，一旦您登录并在网站上发布内容，我觉得创作内容的环境有点相反。 我认为它是用网站方法构建的，而不是一种更重的 JavaScript 重 Web 应用程序方法，以至于我在想……或者它可能需要两者兼而有之。 我需要继续以漂亮的静态 HTML 和 CSS 以及少量 JavaScript 发布前端。 但是我想提供内容创作体验的后端可能是不同的技术选择会更好。 这很有趣，因为它并不总是必须是一件事或另一件事吗？ 这不是二元选择。 这更像是一个频谱，你会说吗？

杰里米：是的，绝对的。 我认为我们开始在社区中看到更多关于 Web 开发的讨论。 对于可能对我的书感兴趣的人来说，它肯定来自网站方面。 再一次，因为我觉得这总是一个很好的默认值。 如果您不知道要如何构建某些东西，最好尝试以一种尽量减少 JavaScript 使用并尽量减少向客户端推送更多工作的方式来构建它。 也就是说，我认为注意到是一种极好的体验。 我认为这些久经考验的、真正“无聊”的技术非常适合手头的任务。 它以一种对开发人员开放和支持的方式这样做，对吗？

Jeremy：你不需要对状态管理存储或状态管理框架有深入的了解，才能真正完成这些事情。 我认为这种特殊方法很好地服务了这一点。 但就您的观点而言，我认为任何网站都有机会更接近频谱的中间位置，而无需全力以赴所有客户端路由，例如管理客户端上所有内容的重型框架和此类事物。 我认为该岛的方法正在开始探索它的样子。 我承认，我可能无意中做了一些岛屿类型的事情。 我想我们已经有很长一段时间了，只是还没有真正命名它。 但我认为，既然我们已经确定了这可能是一个中点，我们可能会开始看到提供良好用户体验的 Web 体验，但仍然更具交互性。 希望这不是非常曲折。

Drew：这有点回到我们嵌入 Flash 岛的日子，或者——

杰里米：是的。

德鲁：页面中有一些东西，这是我们的小互动部分，其余部分在流动。

杰里米：是的，就像 Flash 一样，我的天啊，我大学毕业后个人作品集的三个迭代对于高级 Flash 仿冒品和悬停效果来说真的很糟糕。 那东西真的，真的很有趣。 我有时会想念它，因为我们不再使用 Flash，所以有大量内容即将消失。 这真的很糟糕，但在某种程度上，它是我们正在谈论的这种岛屿事物的先驱。 你可以只拥有一个静态网页和所有东西，但是你会拥有这种非常丰富的互动体验，就像在它中间扑通一声。

Drew：长期以来，渐进式增强一直被认为是构建 Web 体验的最佳实践方式。 你觉得现在还是这样吗？

Jeremy：我承认这可能是……我不太可能承认进行渐进增强需要做更多的工作，因为在某种程度上，你有点分裂了你的开发经验。 您正在尝试以服务器可以处理类似于这些关键交互的方式提供网站的最小可行功能。 但除此之外，你会说，“好吧，现在我想促进这种交互，让 JavaScript 更流畅一点。” 我仍然认为这是一种通过网站、应用程序或产品实现目标的可行方式。

Jeremy：但我要说的是，我绝不会建议网站上的每一次交互都必须由这种同步导航类型的模式来促进。 因此，一个很好的例子可能是您的经济网站的结帐页面肯定应该有一个服务器路由。 你应该有一个服务器路由来将东西添加到购物车，然后你应该能够撒上足够多的 JavaScript 来让它更令人愉快，这样事情就可以更快一点，更异步。

德鲁：在衡量绩效方面。 我们听到了很多关于核心网络生命力的信息，主要来自谷歌。 这些真的是我们应该衡量的基准吗？ 或者这正是谷歌想让我们这么想的？ 我现在意识到这可能是您开始在 Google 工作时遇到的一个难题。

杰里米：是的，是的。 你知道，所以我在这里为自己说话。 我认为 Web Vitals 是……最初的核心 Web Vitals 是一个很好的尝试来定义用户体验的哪些部分是重要的。 我确实认为诸如累积布局变化和最大内容绘制等指标开始以我们还没有开始量化的方式思考体验。 在特别累积的布局转变之前，因为如果曾经有过让您愤怒的点击的时刻，那是因为按钮喜欢在页面上移动或其他东西。 我的意思是，我认为这对衡量它很有帮助。 这是不完美的。 而且我认为任何从事核心网络生命体征的人都会同意其中一些指标需要改进。 还有其他指标我不一定完全同意。 就像第一个输入延迟是一个很难确定的指标。

杰里米：我认为它真的很有用，对吧？ 因为你的字面意思是我们想要测量用户第一次交互的延迟和交互性，但它确实缺乏一点上下文，对吧？ 因为有些……很多事情都会影响它，因为它不一定总是与 JavaScript 相关联。 第一次输入延迟可能代表聚焦表单字段所产生的延迟，对吧？ 那种东西，HTML 中的东西。 我认为这些指标……诸如首次输入延迟之类的指标可能……如果您可以将它们与诸如长任务 API 中的条目、元素计时和这些类型的事物等内容关联起来，它们将是有益的。 我最终认为核心 Web Vitals 的未来将证明它将有助于衡量什么是良好的用户体验。 那是我个人的看法。

德鲁：我想是的，这是你总是可以衡量自己的事情之一，衡量你自己的进步，或者如果你的分数发生变化，你的体验是否会变得更糟，不太关心交通信号灯，而是关心你所知道的关于您网站的背景以及更改如何带来改进。

Jeremy：我认为累积布局偏移等指标非常好，但它们也可以从一点点改进中受益。 就目前而言，累积布局偏移主要衡量加载期间发生的布局偏移。 正如我们所知，当用户访问页面并登陆页面时，布局变化可能随时发生，对吧？ 所以我认为肯定有工作可以改善我们观察这种现象的方式，当然。

Drew：我认为布局稳定性是在使用渐进增强时实际上更难实现的事情之一。 有时，当您加载服务器呈现的页面然后开始在客户端中对其进行增强时，可能会产生这种布局变化的危险，不是吗？

杰里米：当然。 这就是组件的水合变得有点棘手的地方，因为该组件的尺寸可能由于多种原因而发生变化。 就像客户端组件中存在的内容可能不会在服务器上呈现，因为在客户端执行之前不会评估状态。 这是一个极其困难的问题。 我不会坐在这里假装我喜欢它的灵丹妙药。

Drew：我想谈一谈动态导入和代码拆分，这两种技术都是在体验开始时预先下载和执行大量 JavaScript 包的不同技术。 通过提出大量小请求是否存在过度优化的风险，特别是在最简单的小型项目上，或者从一开始就预先确定您将遇到这些问题，它们是否绝对没有害处？ 还是应该等到真正看到性能问题后再考虑这些事情？

杰里米：所以我建议你刚才所说的结尾是一个很好的引导方式。 我们不应该尝试过早地进行优化，除非这些优化当然可以非常快速和轻松地实现，但是如果在早期进行优化需要付出很多努力，当实际上并没有很多性能问题时，我会争辩说代码拆分可能是不必发生的事情。 您可能只需预先加载该功能。

杰里米：但是例如，我在书中谈到了这个。 如果你有一个由一大段 JavaScript 驱动的高价值交互，对我来说，一大段 JavaScript 可能意味着 20 KB，因为在经过压缩的线路上，最终可能是 60 KB 的 JavaScript 块。 然后，如果您可以在主捆绑包或无数捆绑包中的任何一个中提取它，您的网站可能正在发货，您将有助于启动性能。

Jeremy：但在书中，我讨论了一种关于感知何时……或者至少尝试感知用户何时可能进行高价值交互的技术。 所以我使用的例子是一段 JavaScript。 它用于验证表单的内容，因为 HTML 表单验证很棒，但它也不是样式化的，而且非常简单。 对于诸如类型等于电子邮件之类的事情没有很大的灵活性，对吗？ 它以某种方式对其进行评估。 但是，在客户端验证表单确实很有帮助，因为我们也可以设置它的样式。 我们可以调整该验证的外观，使其更接近品牌美学或网站美学。 所以在这个例子中，我所做的是，如果用户关注……甚至只是关注表单中的任何字段，这就是我们预加载那段 JavaScript 的点。

杰里米：所以希望到那时，我希望因为填写表格需要一点时间，网络有足够的时间将其拉下来，以便在调用动态导入时，它可以将现金打到获取已经预加载的内容。 这是我一直在这里和那里进行的一些工作，而且在所有情况下都很难做到。 例如，您不能在悬停时始终可靠地执行此操作，因为某些设备没有精细的指针。 他们有……他们是……这是点击输入，对吧？ 例如，悬停发生的时间与您有一个细指针的时间不同。

Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they're on a data plan. Are there techniques that we can lean on here to, to help us think about those things?

Jeremy: Yeah. So currently, or at least historically from the last… I don't know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it's a request header that's called save data and it only has one token and it's just on. Because if it's off, the header just doesn't get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?

Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There's a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we're converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it's sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.

Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn't the most important thing. Maybe we don't really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.

Drew: That's nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that's sent over the wire.

Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It's kind of a hack need phrase, but it really is limited to your imagination. There's a huge space where I think that concept can be applied to deliver better user experiences. And I've used it with a client of mine in Wisconsin. In rural Wisconsin it's just like… it is an internet dead zone. Like it's so difficult to… I don't know how people cope with how slow it is. Maybe it's just because of my data plan and I might be roaming or whatever, but I've used this to some effect to say, “You know, maybe they don't need this carousel.” Somebody who's just kind of out there in the sticks who… there's a lot of farmland in Wisconsin, but there's also like a lot of forests and somebody might need some work done in logging, right? It's a logging company. And so maybe all of these images, aren't really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.

Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we're building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?

Jeremy: Anytime you take a new syntax and you have to transform it so that it's more broadly compatible, that's going to generally… I have not done this comprehensive audit of all features, but generally I've observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it's a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.

Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we're going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I'm going to generate these transformed bundles for older browsers and serve it to them.” And I'll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It's taking time, but it's fading.

Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don't quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.

Jeremy: In the case of the NHS or literally any government service, I would say that it's virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don't know where they're going to be accessing the web off of, right? The constraints we develop for are incredible, it's really, really hard. It's thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.

Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.

Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser's list configuration, so that we're transpiling bundles to be smaller since we don't need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.

Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn't preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it's crucial, right? Or infrastructure.

Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?

Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don't need JavaScript for. So an example of this would be… what's the word for it? Truncation of content, right? That's something that we can do in CSS. Whereas I've been in situations or in projects where I've seen libraries or a library get downloaded that does that. And we don't necessarily need to really do that anymore because CSS can handle it.

Jeremy: Or we have access to these layout modes now where we don't really need. If we invest the time to learn these layout modes like grid, we don't really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what's great about that is with layout modes like CSS grid, if they're abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what's possible, I always like to point to Jen Simmons, her experimental layout lab homepage.

Jeremy: I don't know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it's incredible and it's really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.

Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it's full of very practical information. It's very to the point, you know? There's not filler. It's not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It's just like it's all straight in there and it's all very nicely written. Was it a challenge to put that set of information together?

Jeremy: I'll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I'm… As your listeners can probably guess I'm sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn't like sound mechanical, but the result was that the manuscript is like 42,000 words. So it's a book, it's a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.

Drew: And it's very much a book that you can sort of dip into various parts. You don't need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that's relevant to the problem that you're facing at the moment and dive in there. So I think that's really great about it. So I've been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?

Jeremy：自从它问世以来，我一直在做的一件事情就是搞乱 CSS 绘制 API。 我真的很喜欢paint API。 我的意思是，它总是以自己的方式存在…… 喜欢以它自己的方式，因为喜欢画布 2D 上下文已经是一回事了。 因为那......你以前不能动画和那种类型的东西。

Jeremy：最近我一直在刷新博客。 那就是……我是一个巨大的最终幻想极客，就像我刚刚重播的最终幻想 II 一样，其中有 15 个，并且某个时候会出现 16 个，但这是一个复古的领域。 所以我一直在使用 CSS 绘制 API 来使用不同的图块生成一个随机的世界。 所以有河流之类的东西，比如穿过草砖和树木之类的东西。 并对其进行参数化，就像用户在黑暗模式下访问我的网站一样……油漆工作将呈现为仿佛是夜晚。 它只会有类似的覆盖层和那种类型的东西。

Jeremy：但是绘画 API 很棒。 我必须向蒂姆霍尔曼大喊大叫。 他，我在澳大利亚的 JSConf 见过他，他做了一个关于生成艺术的演讲。 那真的只是，它真的让我感兴趣。 然后 Sam Richard 在前一天的 CSSConf 上谈到了 CSS 绘画 API，当我把这两件事放在一起时，就像，“哇，这太酷了。” 所以我实际上做了一个叫做Paintlets的东西！ 这是一个 Paintlets.Herokuapp.com，如果您访问 Chrome，不幸的是，您必须这样做，因为它还没有得到很好的支持。 你可以看到一堆不同的、随机的艺术品随机生成的艺术品……是的，我刚刚……这就是我一直在做的，抱歉。 长篇大论。

德鲁：太棒了。 听起来不错。

杰里米：是的。 是的。

Drew：亲爱的听众，如果您想从 Jeremy 那里听到更多信息，您可以在 Twitter 上找到他，他是 @malchata，并在他的个人网站 jeremy.codes 上找到他的写作演示、视频和项目，负责任的 JavaScript 现在可以从 A分开预订。 您可以在 Responsiblejs.dev 上找到更多相关信息。 谢谢你今天加入我，杰里米，你有什么告别的话吗？

杰里米：继续前进，以最好的方式为网络构建，并尝试将用户牢记在心。 这就是我的口头禅，我希望这本书能让我坚持下去。