TS、Vue、React、SSR、Node、Deno、Bun：回顧2022，展望2023

作者：CUGGZ 2023-01-24 08:50:22

開(kāi)發(fā) 前端

本文將回顧并總結(jié) 2022 年 JavaScript 生態(tài)系統(tǒng)中最重要的發(fā)展以及 2023 年的發(fā)展趨勢(shì)！

大家好，我是 CUGGZ。祝大家新年快樂(lè)呀~

本文將回顧并總結(jié) 2022 年 JavaScript 生態(tài)系統(tǒng)中最重要的發(fā)展以及 2023 年的發(fā)展趨勢(shì)！

大綱：

TypeScript
React
Vue
服務(wù)端渲染（SSR）
Node.js、Deno、Bun

1、TypeScript

回顧 2022 年，事實(shí)證明，即使在這樣一個(gè)成熟穩(wěn)定的生態(tài)系統(tǒng)中，也會(huì)發(fā)生一些有趣的事情。

類型會(huì)出現(xiàn)在 JavaScript 中嗎？

3 月初，TypeScript 背后的公司微軟準(zhǔn)備了一份 JavaScript 標(biāo)準(zhǔn)提案。它的內(nèi)容側(cè)重于使用類似于 TypeScript 中已知類型的類型來(lái)豐富語(yǔ)法。為了保持向后兼容性并且不改變語(yǔ)言的基礎(chǔ)，微軟建議解釋器將類型視為與注釋相同（完全忽略它們）。這會(huì)將類型排除在應(yīng)用邏輯之外，但會(huì)通過(guò)將語(yǔ)言服務(wù)器和類型檢查器連接到 IDE 來(lái)提高代碼的可讀性和開(kāi)發(fā)效率。

上面顯示的行為可能與當(dāng)前的 JSDoc 行為相似。但是，新提案比該解決方案具有顯著優(yōu)勢(shì)。首先，Microsoft 建議的格式比 JSDoc 更簡(jiǎn)潔和可讀。其次，JSDoc 的功能受到嚴(yán)重限制（至少很難使用它定義泛型）。

// —-----------------------------------
// JSDoc
// —-----------------------------------

/**
 * @param {string}  p1 - 字符串參數(shù).
 * @param {string=} p2 - 可選參數(shù)（閉包語(yǔ)法）
 * @param {string} [p3] - 可選參數(shù)（JSDoc語(yǔ)法）
 * @param {string} [p4="test"] - 帶默認(rèn)值的可選參數(shù)
 * @return {string} - 結(jié)果
 */
function stringsStringStrings(p1, p2, p3, p4) {
   /* ... */
}
// —-----------------------------------
// 帶有類型注釋的JavaScript
// —-----------------------------------
function stringsStringStrings(p1: string, p2?: string, p3?: string, p4 = "test"): string {
    /* ... */
}

那JavaScript 中的類型是否意味著 TypeScript 的終結(jié)呢？在早期階段，JavaScript 中的類型可能比 JavaScript 中已知的類型更原始。TypeScript 還提供基于代碼轉(zhuǎn)換的功能，例如枚舉。在這方面，JavaScript 不太可能很快趕上 TypeScript。

從 2022 年 3 月開(kāi)始，該提案的工作進(jìn)展不大，一直停留在 Stage 1（整個(gè)過(guò)程分為 4 個(gè)階段）。但是，天正在由微軟處理，所以該提案應(yīng)該會(huì)在 2023 年回歸。

TypeScript 的新功能

在過(guò)去的一年里，TypeScript 發(fā)布了 3 個(gè)新的版本：4.7、4.8、4.9。TypeScript 團(tuán)隊(duì)的開(kāi)發(fā)人員花費(fèi)了大量時(shí)間來(lái)優(yōu)化性能并更好地處理更多邊緣情況。在這些新特性中，有一個(gè)新功能令人眼前一亮：satisfies 操作符。

下面來(lái)通過(guò)官方文檔中的示例來(lái)解釋新運(yùn)算符的工作原理，假設(shè)需要在以下代碼中添加類型：

// 每個(gè)屬性可以是字符串或 RGB 元組
const palette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [0, 0, 255]
};

// 在“red”上使用數(shù)組方法
const redComponent = palette.red.at(0);

// 在“green”上使用字符串方法
const greenNormalized = palette.green.toUpperCase();

我們可能想到的就是定義顏色的類型并使用 Record 類型。在這種情況下，就被迫執(zhí)行危險(xiǎn)的轉(zhuǎn)換操作：

type Color = "red" | "green" | "blue";
type RGB = [red: number, green: number, blue: number];

type Palette = Record<Color, string | RGB>

const palette: Palette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [0, 0, 255]
};

// 在“red”上使用數(shù)組方法
const redComponent = palette.red.at(0);

// 在“green”上使用字符串方法
const greenNormalized = palette.green.toUpperCase();

此問(wèn)題的解決方法就是使用新的 satisfies 運(yùn)算符，它將在賦值時(shí)驗(yàn)證類型，但不會(huì)影響 TypeScript 推斷的類型。這聽(tīng)起來(lái)很復(fù)雜，下面來(lái)通過(guò)一個(gè)簡(jiǎn)單的例子來(lái)說(shuō)明：

type Color = "red" | "green" | "blue";
type RGB = [red: number, green: number, blue: number];

type Palette = Record<Color, string | RGB>

const palette = {
    red: [255, 0, 0],
    green: "#00ff00",
    blue: [0, 0, 255]
} satisfies Palette;

// 這兩種方法仍然可用
const redComponent = palette.red.at(0);
const greenNormalized = palette.green.toUpperCase();

// —-----------------------------------
// 通過(guò) satisfies 捕獲錯(cuò)誤的示例
//  —-----------------------------------

const spelloPalette = {
    red: [255, 0, 0],
    green: "#00ff00",
    bleu: [0, 0, 255] // 捕獲到錯(cuò)別字
} satisfies Palette;

// 捕獲到缺少屬性
const missingColorPalette = {
    red: [255, 0, 0],
    bleu: [0, 0, 255]
} satisfies Palette;

const wrongColorTypePalette = {
    red: [255, 0], // 捕獲到缺少元素
    green: "#00ff00",
    bleu: [0, 0, 255]
} satisfies Palette;

TypeScript 的未來(lái)

2023 年 3 月初將發(fā)布 TypeScript 5.0。值得注意的是，TypeScript 并不遵循語(yǔ)義版本控制。這意味著新的主要版本應(yīng)該帶來(lái)一系列激動(dòng)人心的變化，但不一定是重大變化。

查看 TypeScript 存儲(chǔ)庫(kù)，可以瞥見(jiàn)一些即將推出的功能。首先，TypeScript 被重寫(xiě)為模塊（之前是基于命名空間），減少了 25% 的包大小，提高了 10% 的編譯速度。TypeScript 還致力于為任何文件類型提供原生 import 支持。種種跡象都表明，2023 年對(duì)于 TypeScript 來(lái)說(shuō)，肯定會(huì)是比 2022 年更有趣的一年。

2、React

在 React 17 發(fā)行兩年后，Meta 終于發(fā)布了下一個(gè)主要版本：18.0。與以前的版本不同，從API 的角度來(lái)看，上一版本沒(méi)有引入顯著的新穎之處，而這一版本充滿了令人興奮的功能。

React 18 和并發(fā)模式

這里說(shuō)的并發(fā)是關(guān)于對(duì)渲染進(jìn)行排隊(duì)、排定優(yōu)先級(jí)以及添加中止正在進(jìn)行的渲染的能力的。

可以從并發(fā)模式中獲益的典型示例就是與搜索字段進(jìn)行交互。當(dāng)用戶按下鍵盤(pán)上的一個(gè)鍵時(shí)，即使是更新文本字段的最輕微延遲也會(huì)讓用戶感覺(jué)到有問(wèn)題。當(dāng)涉及到搜索結(jié)果時(shí)，稍微延遲甚至是比較自然的。在這種情況下，顯然有優(yōu)先級(jí)和非優(yōu)先級(jí)渲染器需要處理。此外，如果用戶能夠比 React 渲染組件輸入的更快，那么渲染中間搜索狀態(tài)是不可取的。在這種情況下，渲染取消就可以發(fā)揮作用，只要出現(xiàn)更新版本的組件，就會(huì)取消之前的渲染。

那使用防抖函數(shù)是不是也可以達(dá)到類似的效果呢？React 18 之前的技術(shù)與并發(fā)模式之間的區(qū)別在于，之前，渲染是同步完成的，用戶無(wú)法在渲染期間與頁(yè)面進(jìn)行交互。在并發(fā)模式下，當(dāng)隊(duì)列中出現(xiàn)優(yōu)先級(jí)較高的渲染時(shí)，優(yōu)先級(jí)較低的渲染將被中斷。通過(guò)中止優(yōu)先級(jí)較低的渲染，頁(yè)面應(yīng)該會(huì)響應(yīng)更快。

使用此功能，可以以低優(yōu)先級(jí)在屏幕外呈現(xiàn)組件（以便可以緩存已訪問(wèn)的頁(yè)面，或者提前渲染用戶最有可能訪問(wèn)的頁(yè)面）。由于使用了優(yōu)先級(jí)，這些操作不會(huì)影響界面的響應(yīng)性，因?yàn)樗鼈冎粫?huì)以較低的優(yōu)先級(jí)執(zhí)行。

下面來(lái)看一個(gè)實(shí)際的例子，低優(yōu)先級(jí)更新必須包裝在 startTransition 方法中，可以通過(guò) useTransition() Hooks 訪問(wèn)它：

export default function App() {
  const [isPending, startTransition] = useTransition();
  const [count, setCount] = useState(0);

  function handleClick() {
    startTransition(() {
      setCount((c) => c + 1);
    });
  }

  const advancedCounter = useMemo(
    () <AdvancedCounter count={count} />,
    [count]
  );

  return (
    <>
      {/*點(diǎn)擊按鈕后，直到低優(yōu)先級(jí)渲染完成，div才會(huì)改變不透明度*/}
      <div style={{ opacity: isPending ? 0.8 : 1 }}>
    {/*只有在所有高優(yōu)先級(jí)渲染完成后，下面的組件才會(huì)更新。*/}
    {/*若用戶連續(xù)點(diǎn)擊增加按鈕，則只有最后一次渲染對(duì)用戶可見(jiàn)。*/}
        {advancedCounter}
        <button onClick={handleClick}>+1</button>
      </div>
    </>
  );
}

useDeferredValue Hook 也已添加到 API 中。如果在高優(yōu)先級(jí)渲染中調(diào)用此 Hook，它將返回前一個(gè)渲染的值。這樣引用就不會(huì)改變，這將使渲染更快，因?yàn)椴粫?huì)重新渲染虛擬 DOM 樹(shù)的一部分。完成高優(yōu)先級(jí)渲染后，將安排低優(yōu)先級(jí)渲染，其中 Hook 將返回新值并渲染更新的組件。

export default function App() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount((c) => c + 1);
  }

  const deferredCount = useDeferredValue(count);

  const advancedCounter = useMemo(
    () <AdvancedCounter count={deferredCount} />,
    [deferredCount]
  );

  return (
    <>
      <div>
        {/*只有在所有高優(yōu)先級(jí)渲染完成后，下面的組件才會(huì)更新。*/}
    {/*若用戶連續(xù)點(diǎn)擊增加按鈕，則只有最后一次渲染對(duì)用戶可見(jiàn)。*/}
        {advancedCounter}
        <button onClick={handleClick}>Increase counter</button>
      </div>
    </>
  );
}

React 的未來(lái)

我們不太可能在 2023 年看到 React 新的主要版本。可以預(yù)見(jiàn)，有些功能不會(huì)等到 React 19，而是會(huì)進(jìn)入 React 18 的下一版本。

React 團(tuán)隊(duì)目前正在開(kāi)發(fā)的最大和最受期待的功能可能是 React 服務(wù)端組件。這并不是目前正在開(kāi)發(fā)的唯一功能。React 團(tuán)隊(duì)正在開(kāi)發(fā)一個(gè) <Offscreen />? 組件，它將允許在不將元素附加到 DOM 的情況下渲染屏幕。另一個(gè)正在開(kāi)發(fā)的功能是一個(gè)編譯器，它可以在需要的地方自動(dòng)添加 useMemo? 和 useCallback。

3、Vue

2022 年，Vue 只發(fā)布了一個(gè)主要版本。令人驚訝的是，它不是另一個(gè) Vue 3，而是 Vue 2 的最終版本。此外，我們終于可以通過(guò) Nuxt 3 獲得服務(wù)端渲染。

Vue 2.7

Vue 2.7 是 Vue 2 的最新版本，將支持到 2023 年底。簡(jiǎn)而言之，這個(gè)版本將 Vue 3 中最重要的功能添加到 Vue 2 中。通過(guò)這種方式，增量遷移應(yīng)該會(huì)變得更加簡(jiǎn)單。

Vue 2.7 中最重要的功能是 Composition API，許多人稱之為 Vue 的 React Hooks。該 API 由 3 個(gè)組件組成：Reactivity API（ref 和 reactive）、Lifecycle Hooks（onMounted/onUnmounted）和依賴注入（provide/inject）。重要的是，所有新功能的行為和類型都與 Vue 3 100% 兼容。

// 舊的 Options API
<script>
export default {
  data() {
    return {
      name: 'John',
    };
  },
  mounted() {
    console.log(`Hello ${this.name}`);
  },
};
</script>

<template>
  <p>Hello {{ name }}!</p>
</template>

// 新的 Composition API
<script setup> 
const name = ref(0);

onMounted(() {
  console.log(`Hello ${name.value}`);
});
</script>

<template>
  <p>Hello {{ name }}!</p>
</template>

Vue 3.3

Vue 3.3 原本應(yīng)該在 2022 年底發(fā)布，但它的發(fā)布已經(jīng)推遲到 2023 年。不過(guò)，可以看看 Vue 2023 年會(huì)發(fā)布什么。

第一個(gè)期待已久的功能是 <Suspense />。它將啟用臨時(shí)組件的渲染，直到加載完樹(shù)中的所有異步組件。

<Suspense>
  <!-- 具有嵌套異步依賴項(xiàng)的組件 -->
  <Dashboard />

  <!-- 通過(guò) #fallback 插槽加載狀態(tài) -->
  <template #fallback>
    Loading...
  </template>
</Suspense>

第二個(gè)備受期待的功能是 Reactivity Transform，這是對(duì) Composition API 的一系列改進(jìn)。Reactive API 中的所有方法（包括 ref 和 computed）都將獲得以 $ 開(kāi)頭的版本。這些將是允許更輕松地訪問(wèn)數(shù)據(jù)的宏，但需要額外的編譯步驟。

// Vue 3.3 之前
<script setup>
import { ref } from 'vue'

let count = ref(0)

console.log(count.value)

function increment() {
  count.value++
}
</script>

<template>
  <button @click="increment">{{ count }}</button>
</template>

// Vue 3.3
<script setup>
let count = $ref(0)

console.log(count)

function increment() {
  count++
}
</script>

<template>
  <button @click="increment">{{ count }}</button>
</template>

在 Vue Amsterdam 上，尤雨溪分享了團(tuán)隊(duì)的長(zhǎng)期計(jì)劃。目前，這些計(jì)劃還處于起步階段，仍有可能發(fā)生變化。Vue 3.3 完成后，團(tuán)隊(duì)正在考慮采用與 SolidJS 類似的新編譯策略。SolidJS 是一個(gè)類似于 React 的框架，但由于放棄了虛擬 DOM，它擁有更好的性能。可選地從 Vue 中刪除虛擬 DOM 可以顯著縮小包大小，并節(jié)省存儲(chǔ)虛擬組件結(jié)構(gòu)所需的內(nèi)存。

4、服務(wù)端渲染（SSR）

過(guò)去的一年，幾乎每個(gè)主要框架都有關(guān)于服務(wù)端渲染的較大更新，或者有一個(gè)具有大量新功能的全新庫(kù)（Vue – Nuxt 3、Svelte – SvelteKit、React – React Server Components、Remix、Next.js 13）。市場(chǎng)上也有很多創(chuàng)新的解決方案，與現(xiàn)有的框架無(wú)關(guān)。這里不得不提的就是 Qwik，它試圖徹底改變水合方法，還有 Astro，它推廣了創(chuàng)新的 Dynamic Islands 架構(gòu)。

React 服務(wù)端組件和 Next.js 13

自 Dan Abramov 介紹 React 服務(wù)端組件以來(lái)已經(jīng)兩年多了。簡(jiǎn)而言之，React 將允許在服務(wù)端渲染單個(gè)組件并將 HTML 代碼發(fā)送到客戶端。這種方法非常類似于PHP，因?yàn)榭梢灾苯訌?React 組件進(jìn)行數(shù)據(jù)庫(kù)查詢。

// Note.js - Server Component
import db from 'db'; 

async function Note(props) {
  const note = await db.posts.get(props.id);
  
  return (
    <div>
      <h2>{note.title}</h2>
      <section>{note.body}</section>
    </div>
  );
}

然而，React 服務(wù)端組件也有其局限性。這種類型的組件不能存儲(chǔ)狀態(tài)（禁止使用 useState），不能被客戶端渲染的組件導(dǎo)入，并且需要像 Next.js 或 Gatsby 這樣的元框架才能工作。

盡管 React 服務(wù)端組件仍處于 alpha 階段，但使用它們的框架（Next.js、Gatsby）已經(jīng)發(fā)布。特別是，Next.js 13 引起了社區(qū)的共鳴，因?yàn)樗男录軜?gòu)完全基于 React Server Components。這種架構(gòu)的一個(gè)有趣的副作用是，只要不顯式定義客戶端組件，整個(gè)應(yīng)用將只在服務(wù)端渲染。

Qwik

Qwik 通過(guò)破壞水合過(guò)程的合法性，顛覆了所有現(xiàn)代服務(wù)端渲染工具的范式。水合是一個(gè)客戶端過(guò)程，在此期間服務(wù)端渲染的應(yīng)用加載 JavaScript 代碼，然后重復(fù)所有初始化邏輯。只有在水合過(guò)程完成后，應(yīng)用才會(huì)響應(yīng)。由于這種策略，用戶可以立即看到目標(biāo)內(nèi)容，過(guò)一會(huì)兒就可以與之交互。

Qwik 提供的替代方案是重新執(zhí)行。使用下面這種方式保存服務(wù)端的應(yīng)用狀態(tài)，以使客戶端可以立即恢復(fù)代碼執(zhí)行。聽(tīng)起來(lái)很復(fù)雜？幸運(yùn)的是，復(fù)雜的邏輯被隱藏在了可訪問(wèn)的 API 中：

那為什么未來(lái) Qwik 是值得關(guān)注的呢？其有一個(gè)真正的全明星團(tuán)隊(duì)負(fù)責(zé)其開(kāi)發(fā)——Mi?ko Hevery（anguar.js 的創(chuàng)建者）、Manu Almeida（Gin 和 Stencil 的創(chuàng)建者）和 Adam Bradley（Ionic 和 Stencil 的創(chuàng)建者）。如果有人想徹底改變前端，那就是一群這樣的老手。

Astro

Astro 是一個(gè)推廣所謂 island 架構(gòu)的框架。它假設(shè)在我們創(chuàng)建的頁(yè)面上，在靜態(tài)內(nèi)容的海洋（例如導(dǎo)航菜單、文章）中，有交互式組件的小島（例如表單）。這種方法允許我們?cè)诜?wù)端渲染整個(gè)應(yīng)用，并且只將一小部分組件島代碼發(fā)送到客戶端。

Astro 配備了一個(gè)非常先進(jìn)的機(jī)制來(lái)定義何時(shí)應(yīng)該下載動(dòng)態(tài)組件的代碼以及何時(shí)應(yīng)該將它們混合。在可用的選項(xiàng)中，只有當(dāng)組件在屏幕上可見(jiàn)時(shí)才需要下載，或者只有當(dāng)滿足適當(dāng)?shù)拿襟w查詢時(shí)才需要水合。

Astro 在競(jìng)爭(zhēng)中脫穎而出還因?yàn)樗?dú)立于框架。這是很長(zhǎng)一段時(shí)間以來(lái)第一個(gè)真正不支持任何解決方案的庫(kù)，最重要的是其可以與它們相互混合。

—
import HomeLayout from '../layouts/HomeLayout.astro'
import MyReactComponent from '../components/MyReactComponent.jsx';
import MySvelteComponent from '../components/MySvelteComponent.svelte';

const data = await fetch('API_URL').then(r r.json());
---
<HomeLayout>
  <MyReactComponent client:load name={data.name}>
    <MySvelteComponent avatar={data.avatar}/>
  </MyReactComponent>
</HomeLayout>

5、Node.js、Deno、Bun

一年前，JavaScript 運(yùn)行時(shí)的情況似乎比較穩(wěn)定。Node 憑借強(qiáng)大的實(shí)力占據(jù)主導(dǎo)地位，而 Deno 正在精心擴(kuò)大其市場(chǎng)。然而，在 2022 年年中，當(dāng) Bun 以 700 萬(wàn)美元的資金進(jìn)入游戲時(shí)，發(fā)生了一場(chǎng)真正的地震。

Bun

Bun 是 Node.js 和 Deno 的替代品。Deno 將其營(yíng)銷重點(diǎn)放在解決 Node.js 問(wèn)題上，而 Bun 則強(qiáng)調(diào)性能。根據(jù) Bun 作者發(fā)布的基準(zhǔn)測(cè)試，其優(yōu)勢(shì)非常顯著。

Bun 的表現(xiàn)主要由兩個(gè)因素導(dǎo)致。首先，與其競(jìng)爭(zhēng)對(duì)手不同，它不是用 C++ 編寫(xiě)的，而是用 Zig 語(yǔ)言編寫(xiě)的，Zig 是 C++ 和 Rust 的一個(gè)相當(dāng)小眾的替代品。

影響 Bun 性能的第二個(gè)因素是使用了 Apple 的 JavaScriptCore 引擎。事實(shí)證明，JavaScriptCore 比 V8 更快。差異相對(duì)較小，但絕對(duì)存在。

Bun 還對(duì) Node.js 進(jìn)行了很多改進(jìn)。與Deno一樣，TypeScript 是一種原生支持的語(yǔ)言。Bun 也是 npm 的替代品，其速度快 100 倍。Bun 提供了用于創(chuàng)建宏的 API（在編譯過(guò)程中生成的代碼，并訪問(wèn)AST樹(shù)和鍵入元數(shù)據(jù)）。為了打包應(yīng)用，Bun 使用它自己的打包工具/轉(zhuǎn)換器，這是非常快的。

Deno

在 Bun 的 alpha 版本發(fā)布幾周后，Deno 背后的團(tuán)隊(duì)宣布了 npm 兼容性和具有許多性能改進(jìn)的新 http 服務(wù)器。

支持 npm 是一個(gè)特別有爭(zhēng)議的決定，因?yàn)?Deno 作者聲稱這是其生態(tài)系統(tǒng)許多問(wèn)題的根源。需要注意的是，npm 與 Deno 結(jié)合使用的工作方式與Node.js結(jié)合使用的情況。首先，Deno 不需要運(yùn)行 npm install。其次，Deno 不會(huì)創(chuàng)建 node_modules 目錄，下載的包會(huì)全局存儲(chǔ)。第三，npm 導(dǎo)入將標(biāo)有特殊的 npm: prefix：

import { chalk } from "npm:chalk@5";

Node.js

Node.js 的發(fā)展速度不如 Bun 或 Deno。但我們更看重的是它的穩(wěn)定性和可預(yù)測(cè)性，而不是改變世界的功能。盡管如此，Node.js 2022 年還提供了一些有趣的新功能。

一個(gè)有趣的新特性就是內(nèi)置的 Test Runner，這意味著將不再需要 Jest 或 Vitest 等庫(kù)來(lái)測(cè)試 Node 應(yīng)用：

test('synchronous passing test', (t) => {
  // 測(cè)試通過(guò)，因?yàn)樗鼪](méi)有拋出異常
  assert.strictEqual(1, 1);
});

test('asynchronous passing test', async (t) => {
  // 測(cè)試通過(guò)，因?yàn)楫惒椒祷亓?Promise
  // 函數(shù)沒(méi)有被拒絕
  assert.strictEqual(1, 1);
});

責(zé)任編輯：姜華來(lái)源：前端充電寶

JavaScript Vue