Lee Robinson 寫了一篇《Why I'm Optimistic About JavaScript's Future》 表達(dá)對 JavaScript 未來的看好。

正文開始...

我對JavaScript持樂觀態(tài)度。

開發(fā)人員希望編寫 JavaScript，并希望它能在瀏覽器、服務(wù)器或 Edge運行。

盡管有種種怪異和不完善之處，但由于其內(nèi)置的增長（它在瀏覽器中）、其龐大的工具和庫生態(tài)系統(tǒng)以及TypeScript的持續(xù)增長和采用，JavaScript的采用率繼續(xù)上升。越來越多的開發(fā)者能夠?qū)W習(xí)一個API（如Request或Response），并在所有地方重復(fù)使用相同的知識。

擁有一套約定俗成的通用API（即標(biāo)準(zhǔn)）和支持相同接口的平臺（如跨瀏覽器支持），意味著網(wǎng)絡(luò)開發(fā)者現(xiàn)在可以一次學(xué)習(xí)，到處編碼。

本文將概述近期在瀏覽器、服務(wù)器和 edge 對 Web 平臺所做的改進(jìn)。

JavaScript：在瀏覽器中

今天，Web 開發(fā)人員編寫特定于供應(yīng)商的 JavaScript 或特定于供應(yīng)商的 CSS 選擇器的時間比以往任何時候都更少。

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

我們已經(jīng)逃離了維持元素長寬比的padding hacks的世界：

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

兩個融合的趨勢使這成為可能:

• Internet Explorer 的死亡：現(xiàn)在，IE 11 已正式退役，Web 開發(fā)人員可以編寫更少的特定于供應(yīng)商的 CSS，從而使樣式表更小，hack 更少。
• 瀏覽器引擎對齊：三大瀏覽器引擎（Chromium/Chrome、Gecko/Firefox和Webkit/Safari）現(xiàn)在對JavaScript、CSS和Web API的跨瀏覽器支持是我們見過的最好的。為Interop項目點贊。

現(xiàn)在，當(dāng)然，它在各瀏覽器引擎中并不完美，也不可能永遠(yuǎn)完美。但這是目前最好的，我很樂觀。由于不需要花一周的時間去研究深奧的IE錯誤，數(shù)千（或數(shù)百萬）的開發(fā)者時間將被累計節(jié)省。

下面是一個例子，說明這種排列組合如何使所有的 web 開發(fā)者受益。想象一下，你是一個框架的作者，試圖編寫一個可重復(fù)使用的圖像組件，以幫助成千上萬的開發(fā)人員在使用圖像時獲得良好的性能。在2020年，就在幾年前，你需要圍繞 web 平臺開展工作。

加載圖片而不引起布局變化，正確地保持長寬比，并且不因圖片的大小/重量而降低頁面的初始加載性能，這很難在所有主要的瀏覽器上實現(xiàn)支持。這導(dǎo)致開發(fā)者要么忽視了這些問題，要么框架編寫的組件抽象產(chǎn)生了這樣的代碼。

<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年情況就不同了?，F(xiàn)在有跨瀏覽器支持：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：在服務(wù)器上

在客戶端和服務(wù)器上都可以運行的同構(gòu) JavaScript（即可以在客戶端和服務(wù)器上運行的代碼）一直是許多 Web 開發(fā)人員的理想狀態(tài)。學(xué)習(xí)一次，寫在所有地方，對吧？直到最近，Node.js 和 Web 平臺還未對齊。

考慮通過 HTTP 獲取數(shù)據(jù)。在瀏覽器中，我們有 Web Fetch API。在 Node.js 18 之前，沒有內(nèi)置的獲取數(shù)據(jù)的方案。使用 fetch? 需要使用 node-fetch? 或 undici 等包，它們的 API 類似但略有不同，通常是以不明顯的方式使用的。

這種平臺之間的不對齊意味著用于編寫同構(gòu) JavaScript 的工具（例如 Next.js）需要添加 polyfill，以便開發(fā)人員可以在客戶端和服務(wù)器上使用 fetch。使用 Node.js 18，這些工具現(xiàn)在可以刪除用于 polyfill 平臺差異的額外 JavaScript，最終導(dǎo)致所需的 JavaScript 更少。

我對服務(wù)器上的 JavaScript（和 TypeScript）感到樂觀。這不僅僅是 fetch。還有 Request、Response 和其他100多個現(xiàn)在可在瀏覽器和 Node.js 中使用的 API。瀏覽器供應(yīng)商和構(gòu)建服務(wù)器基礎(chǔ)設(shè)施的公司現(xiàn)在比以往任何時候都更加密切地合作，提供一組可在所有地方運行的標(biāo)準(zhǔn) API，包括 edge  計算平臺。

JavaScript: 在  Edge 中

Edge computing，這種常常被誤解的最新運行 JavaScript 的目標(biāo)，在三個（瀏覽器、服務(wù)器、edge）中標(biāo)準(zhǔn)化最少。

將 edge 視為最高抽象層次可能會有所幫助，在這里你將把所有時間都花在業(yè)務(wù)邏輯上。

Edge并不是全新的東西，而是從現(xiàn)有的Node.js世界中刻意的、有意的取舍。

你想寫JavaScript，但  edge compute 基礎(chǔ)設(shè)施需要（相當(dāng)大的）Node.js API 表面積的較小子集。通過為 Node.js API 的子集做出這種權(quán)衡，你的可以始終保持快速的冷啟動和更具成本效益的計算工作負(fù)載。這聽起來很好。

讓我們看一個例子。在這種情況下，我將使用 Vercel Edge Function。但也可以是其他邊緣計算平臺，如 Cloudflare 或 Deno。對我來說，這段代碼最好的部分實際上是它相當(dāng)無聊。它看起來像 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);
}

這是重點：這不僅僅關(guān)乎基礎(chǔ)設(shè)施。還關(guān)乎那些擁抱這些同樣的 Web API 并幫助成千上萬的新開發(fā)人員學(xué)習(xí)一次并寫在所有地方的框架。

這段代碼可以與Next.js一起工作。或SvelteKit。混搭。新鮮?；蛘呦乱粋€建立在同一套標(biāo)準(zhǔn)API基礎(chǔ)上的新Web框架。

作為一名 Web 開發(fā)者，這是一個多么不可思議的時代。

原文：https://leerob.substack.com/p/why-im-optimistic-about-javascripts