為什么我對JavaScript的未來持樂觀態度？

作者：前端小智 2023-01-10 08:17:41

這是重點：這不僅僅關乎基礎設施。還關乎那些擁抱這些同樣的 Web API 并幫助成千上萬的新開發人員學習一次并寫在所有地方的框架。

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/why-im-optimistic-about-javascripts

責任編輯：武曉燕來源：大遷世界