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

前端小智發表於2023-01-17
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 視為最高抽象層次可能會有所幫助，在這裡你將把所有時間都花在業務邏輯上。

image.png

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 已收錄，有一線大廠面試完整考點、資料以及我的系列文章。

相關文章