为什么我是 JS 乐天派？（译）

大家好，这里是大家的林语冰。

今年年初"前端已死"突然"三人成猫"，一大坨道友人心惶惶，纷纷向我付费咨询是要 all in 前端还是要切换赛道另谋出路。

抛开国内前端内卷/"前端已死"不谈，我们来看看国外大佬是如何看待 JS 的未来的，本文出自 Vercel DX 副总裁。

免责声明

本文属于是语冰的直男翻译了属于是，仅供粉丝参考，英文原味版请临幸 Why I'm Optimistic About JavaScript's Future（leerob.substack.com/p/why-im-op...

我是 JS（JavaScript）乐天派（乐观主义者）。

开发者希望编写 JS，它们希望 JS 能够在任何地方运行 ------ 浏览器、服务器或 edge（边缘计算）。

尽管 JS 存在各种怪癖和短板，但由于 JS 内置的增长黑客（在浏览器中）、庞大的工具和库生态系统以及 TS（TypeScript）的持续增长和采用，JS 的使用率与日俱增。

而且，开发者能够学习 API（如 Request/Response），并在任何地方复用同款知识，知行合一。

拥有一套公认的通用 API（比如标准）和平台，它们都支持相同的接口（比如跨浏览器支持），这意味着，Web 开发者现在可以一次学习，到处撸码。

本文将概述跨浏览器、服务器和 edge 的 Web 平台的最新改进。

浏览器中的 JS

今时今日，Web 开发者在编写特定供应商的 JS 或特定供应商的 CSS 选择器上花费的时间成本比以往任何时候都要少。

js 复制代码

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

我们已经逃离了用于维护元素纵横比的填充技巧的世界：

css 复制代码

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

两个趋同的趋势使这成为可能：

IE 已死：现在 IE 11 已经正式退役，Web 开发者可以编写更少的特定供应商的 CSS，从而减少样式表和黑客攻击。
浏览器引擎对齐：浏览器引擎三巨头（Chromium/Chrome、Gecko/Firefox 和 Webkit/Safari）现在对 JS、CSS 和 Web API 提供了有史以来最好的跨浏览器支持。感谢 Interop 项目。

当然，现在，它在浏览器引擎中并不完美，也不太可能完美。但这是有史以来最好的，所以我持乐观态度。不必再花一周时间深入研究深奥的 IE bug，这累积节省数千（或数百万）开发者的时间。

下面是一个示例，说明这种一致性何以使所有 Web 开发者受益。请想象一下，您是一个框架作者，正试图编写一个可复用的图像组件，以帮助成千上万的开发者在使用图像时实现出色的性能。在几年前，2020 年，您需要围绕 Web 平台工作。

加载图像而不引起布局偏移，正确保持纵横比，并且不会因图像大小/重量而降低初始页面加载性能，这很难在所有主流浏览器的支持下实现。

这导致开发者要么忽略问题，要么导致框架编写生成代码的组件抽象，举个栗子：

2022 年的情况就不同了。跨浏览器支持：aspect-ratio、宽度/高度属性以防止布局偏移、原生图像懒加载和纯基于 CSS/SVG 的模糊图像占位符。上面的代码可以删除包装元素，无需运行时 JS 即可工作。

html 复制代码

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

服务器上的 JS

同构 JS，即可以在客户端和服务器上运行的代码，一直是许多 Web 开发者的理想状态。一次学习，到处撸码，对吧？直到最近，Node.js 和 Web 平台还分道扬镳。

请考虑通过 HTTP 请求数据。在浏览器中，我们有 Web Fetch API。在 Node.js 18 之前，没有用于请求数据的内置技术方案。使用 fetch 需要诉诸 node-fetch 或 undici 等软件包，这些包具有相似但略有不同的 API，通常差异并非一目了然。

平台间缺乏一致性，意味着编写同构 JS 的工具（比如 Next.js）需要添加 polyfill（功能补丁），以便开发者可以在客户端和服务器同事使用 fetch。在 Node.js 18 中，这些工具现在可以移除，不必使用额外的 JS 来抹平平台之间的差异，最终减少所需的 JS。

我对服务器上的 JS（和 TS）持乐观态度。这包括但不限于 fetch。Request、Response 和 100+ 其他 API，现在在浏览器和 Node.js 中都可用。浏览器供应商和构造服务器基建的公司现在比前所未有地更紧密地合作，以提供一套可以在任何地方运行的标准 API，包括边缘计算平台。

边缘计算中的 JS

边缘计算是运行 JS 经常被误解的最新目标，在三者（浏览器、服务器、edge）中标准化程度最低。

将 edge 视为最高级别的抽象是很有帮助的，这样您可以将所有时间都花在业务逻辑上。

edge 并不是全新的万一，而是对现存 Node.js 世界的深思熟虑和有意的权衡。

您想要编写 JS，但边缘计算基建需要（相当大的）Node.js API 外围应用的轻量子集。

通过对同样在浏览器中运行的 Node.js API 子集进行这种权衡，您可以拥有始终如一的快速冷启动和更具成本效益的计算工作负载。这简直酷毙了。

举个栗子，。我将使用 Vercel Edge 函数。但它也可能是其他边缘计算平台，如 Cloudflare 或 Deno。对我来说，这段代码最好的部分实际上是它相当无聊。它看起来像 Node.js。

js 复制代码

export const config = {
  runtime: 'edge'
}

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

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

  // Web 标准 Response（新的 .json 方法）
  // https://github.com/whatwg/fetch/issues/1389
  return Response.json(data);
}

关键在于：这不仅仅是基建的问题。它是关于那些拥抱这些相同的 Web API 并帮助成千上万新人开发者一次学习、到处撸码的框架。

此代码可用于 Next.js。或者 SvelteKit、Remix、Fresh。或者下一个基于同一组标准 API 构建的新 Web 框架。

成为一名 Web 开发者是多么不可思议的时刻。

您现在收看的是前端翻译计划，学废了的小伙伴可以订阅此专栏合集，我们每天佛系投稿，欢迎持续关注前端生态。谢谢大家的点赞，掰掰~