关于前端:为什么我对JavaScript的未来持乐观态度

微信搜寻【大迁世界】, 我会第一工夫和你分享前端行业趋势，学习路径等等。
本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。

Lee Robinson 写了一篇《Why I’m Optimistic About JavaScript’s Future》表白对 JavaScript 将来的看好。

注释开始 …

我对 JavaScript 持乐观态度。

开发人员心愿编写 JavaScript，并心愿它能在浏览器、服务器或 Edge 运行。

只管有种种怪异和不欠缺之处，但因为其内置的增长黑客（它在浏览器中）、其宏大的工具和库生态系统以及 TypeScript 的持续增长和采纳，JavaScript 的采用率持续回升。越来越多的开发者可能学习一个 API（如 Request 或Response），并在所有中央重复使用雷同的常识。

领有一套约定俗成的通用 API（即规范）和反对雷同接口的平台（如跨浏览器反对），意味着网络开发者当初能够一次学习，到处编码。

本文将概述近期在浏览器、服务器和 edge 对 Web 平台所做的改良。

JavaScript：在浏览器中

明天，Web 开发人员编写特定于供应商的 JavaScript 或特定于供应商的 CSS 选择器的工夫比以往任何时候都更少。

function isIE11() {return !!window.MSInputMethodContext && !!document.documentMode;}

咱们曾经逃离了维持元素长宽比的padding hacks 的世界：

@supports not (aspect-ratio: 16/9) {
  .aspectRatio {
    overflow: hidden;
    padding-bottom: 56.25%;
    height: 0;
  }
}

两个交融的趋势使这成为可能:

• Internet Explorer 的死亡：当初，IE 11 已正式服役，Web 开发人员能够编写更少的特定于供应商的 CSS，从而使样式表更小，hack 更少。
• 浏览器引擎对齐：三大浏览器引擎（Chromium/Chrome、Gecko/Firefox 和 Webkit/Safari）当初对 JavaScript、CSS 和 Web API 的跨浏览器反对是咱们见过的最好的。为 Interop 我的项目点赞。

当初，当然，它在各浏览器引擎中并不完满，也不可能永远完满。但这是目前最好的，我很乐观。因为不须要花一周的工夫去钻研深奥的 IE 谬误，数千（或数百万）的开发者工夫将被累计节俭。

上面是一个例子，阐明这种排列组合如何使所有的 web 开发者受害。设想一下，你是一个框架的作者，试图编写一个可重复使用的图像组件，以帮忙成千上万的开发人员在应用图像时取得良好的性能。在 2020 年，就在几年前，你须要围绕 web 平台发展工作。

加载图片而不引起布局变动，正确地放弃长宽比，并且不因图片的大小 / 分量而升高页面的初始加载性能，这很难在所有次要的浏览器上实现反对。这导致开发者要么漠视了这些问题，要么框架编写的组件形象产生了这样的代码。

<span> <-- needed to maintain aspect ratio
  <span> <-- needed to maintain aspect ratio, CSS padding hacks
    <img src=""style="" /> <-- inline styles to prevent layout shift
    <noscript>...</noscript> <-- JS needed for IntersectionObserver
  </span>
</span>

但 2022 年状况就不同了。当初有跨浏览器反对：aspect-ratio，避免布局变动的宽 / 高属性，本地图像惰性加载，以及纯 CSS/SVG-based 含糊图像占位符。上述代码能够删除包装元素，并在不须要运行时 JavaScript 的状况下工作。

<img
  alt="A kitten"
  decoding="async"
  height="200"
  loading="lazy"
  src="https://placekitten.com/200/200"
  style="aspect-ratio: auto 1 / 1"
  width="200"
/>

JavaScript：在服务器上

在客户端和服务器上都能够运行的同构 JavaScript（即能够在客户端和服务器上运行的代码）始终是许多 Web 开发人员的现实状态。学习一次，写在所有中央，对吧？直到最近，Node.js 和 Web 平台还未对齐。

思考通过 HTTP 获取数据。在浏览器中，咱们有 Web Fetch API。在 Node.js 18 之前，没有内置的获取数据的计划。应用 fetch 须要应用 node-fetch 或 undici 等包，它们的 API 相似但略有不同，通常是以不显著的形式应用的。

这种平台之间的不对齐意味着用于编写同构 JavaScript 的工具（例如 Next.js）须要增加 polyfill，以便开发人员能够在客户端和服务器上应用 fetch。应用 Node.js 18，这些工具当初能够删除用于 polyfill 平台差别的额定 JavaScript，最终导致所需的 JavaScript 更少。

我对服务器上的 JavaScript（和 TypeScript）感到乐观。这不仅仅是 fetch。还有 Request、Response 和其余 100 多个当初可在浏览器和 Node.js 中应用的 API。浏览器供应商和构建服务器基础设施的公司当初比以往任何时候都更加亲密地单干，提供一组可在所有中央运行的规范 API，包含 edge 计算平台。

JavaScript: 在 Edge 中

Edge computing，这种经常被误会的最新运行 JavaScript 的指标，在三个（浏览器、服务器、edge）中标准化起码。

将 edge 视为最高抽象层次可能会有所帮忙，在这里你将把所有工夫都花在业务逻辑上。

Edge 并不是全新的货色，而是从现有的 Node.js 世界中刻意的、无意的取舍。

你想写 JavaScript，但 edge compute 基础设施须要（相当大的）Node.js API 表面积的较小子集。通过为 Node.js API 的子集做出这种衡量，你的能够始终保持疾速的冷启动和更具老本效益的计算工作负载。这听起来很好。

让咱们看一个例子。在这种状况下，我将应用 Vercel Edge Function。但也能够是其余边缘计算平台，如 Cloudflare 或 Deno。对我来说，这段代码最好的局部实际上是它相当无聊。它看起来像 Node.js。

export const config = {runtime: 'edge'}

// Web standard Request API
export default function handler(req: Request) {
  // Web standard URL API
  const {searchParams} = new URL(req.url)
  const name = searchParams.get('name')

  // Web standard Fetch API
  const req = await fetch('https://...', { body: { name} })
  const data = await req.json()

  // Web standard Response (.json is new)
  // https://github.com/whatwg/fetch/issues/1389
  return Response.json(data);
}

这是重点：这不仅仅关乎基础设施。还关乎那些拥抱这些同样的 Web API 并帮忙成千上万的新开发人员学习一次并写在所有中央的框架。

这段代码能够与 Next.js 一起工作。或 SvelteKit。混搭。陈腐。或者下一个建设在同一套规范 API 根底上的新 Web 框架。

作为一名 Web 开发者，这是一个如许不堪设想的时代。

原文：https://leerob.substack.com/p…

编辑中可能存在的 bug 没法实时晓得，预先为了解决这些 bug, 花了大量的工夫进行 log 调试，这边顺便给大家举荐一个好用的 BUG 监控工具 Fundebug。

交换

有幻想，有干货，微信搜寻 【大迁世界】 关注这个在凌晨还在刷碗的刷碗智。

本文 GitHub https://github.com/qq449245884/xiaozhi 已收录，有一线大厂面试残缺考点、材料以及我的系列文章。