最近，在網(wǎng)絡(luò)看到一張圖片，對(duì)比了 2016 年 和 2024 年前端開發(fā)所需掌握的技術(shù)。

當(dāng)年只需要知道 HTML、CSS、JavaScript，以及一些 jQuery 的知識(shí)，就可以在前端開發(fā)的世界中游刃有余。

而如今，我們面對(duì)的是 React、Vue、TypeScript、Node.js、Next.js、 shadcn/ui 等各種框架和工具的洪流。

學(xué)習(xí)成本直線上升，這其中到底發(fā)生了什么？

今天我們就從這個(gè)問題開始，聊聊 JavaScript 框架的發(fā)展過程，了解背后的故事。

前端開發(fā) 2016

前端開發(fā) 2024

1.JavaScript：一種編程語言的誕生

在講述 JavaScript 框架的發(fā)展之前，先簡(jiǎn)要回顧一下 JavaScript 的歷史，幫助理解為什么現(xiàn)代前端開發(fā)如此混亂。

網(wǎng)景通信公司是一家美國(guó)技術(shù)公司，開發(fā)了第一個(gè)廣泛使用的網(wǎng)絡(luò)瀏覽器——網(wǎng)景導(dǎo)航器（Netscape Navigator）。

1995 年，網(wǎng)景聘請(qǐng)了 Brendan Eich，希望將 Schem e編程語言集成到其網(wǎng)景導(dǎo)航器中。

然而，Eich 在加入公司僅 10 天后就創(chuàng)造了一種新的編程語言，起初命名為 Mocha，后改為 LiveScript，最終確定為 JavaScript。

盡管名稱暗示了與 Java 的關(guān)聯(lián)，JavaScript 實(shí)際上與 Java 編程語言關(guān)系不大。這一命名更多是出于市場(chǎng)營(yíng)銷策略，因?yàn)楫?dāng)時(shí) Java 正變得越來越受歡迎。

到了 1990 年代末，網(wǎng)景試圖通過 Ecma International 來標(biāo)準(zhǔn)化 JavaScript，這一努力最終導(dǎo)致了 ECMAScript 標(biāo)準(zhǔn)的誕生。

盡管 JavaScript 的發(fā)展歷程中有過不少波折，如與微軟的瀏覽器大戰(zhàn)，但它經(jīng)受住了時(shí)間的考驗(yàn)，成為了世界上最流行的編程語言之一。

1999 年，網(wǎng)景被美國(guó)在線（AOL）收購，該產(chǎn)品于 2008 年停止更新和支持。

2.瀏覽器大戰(zhàn)

為了理解現(xiàn)代前端開發(fā)背后的混亂，我們需要回到 90 年代中期到 2000 年代初。

那時(shí)候，關(guān)于瀏覽器的選擇并不多。你要么使用網(wǎng)景/火狐，要么使用微軟的 IE，前者在市場(chǎng)上占有絕大多數(shù)份額，高達(dá)90%。

Safari 和 macOS（最初稱為Mac OS X）當(dāng)時(shí)幾乎被開發(fā)者忽視，我記得 Safari 在 2000 年代初的市場(chǎng)份額不超過 0.5%。

在蓋茨的領(lǐng)導(dǎo)下，微軟展現(xiàn)出了極強(qiáng)的競(jìng)爭(zhēng)性，簡(jiǎn)單地說就是消滅了所有競(jìng)爭(zhēng)對(duì)手。

對(duì)微軟來說，瀏覽器與其他商業(yè)產(chǎn)品無異，用戶必須購買這些應(yīng)用程序并將其安裝在個(gè)人電腦上。

微軟想要獨(dú)占所有市場(chǎng)份額，因此他們的做法很簡(jiǎn)單：將 IE 作為默認(rèn)瀏覽器與 Windows 一同發(fā)布，這樣當(dāng)用戶“打開互聯(lián)網(wǎng)”時(shí)，映入眼簾的便是 IE。

作為回應(yīng)，網(wǎng)景嘗試將他們的瀏覽器與 ISP 提供的軟件捆綁。然而，作為市場(chǎng)巨頭的微軟則要求所有第三方應(yīng)用必須捆綁 IE，將其作為“Windows 上進(jìn)行網(wǎng)絡(luò)訪問的必需組件”。

微軟在處理 IE 中的腳本語言時(shí)無視任何標(biāo)準(zhǔn)，完全按照自己的方式行事，不在乎 Web 標(biāo)準(zhǔn)。

接著，微軟對(duì) IE 中的腳本語言為所欲為，無視其他供應(yīng)商試圖制定的任何標(biāo)準(zhǔn)。在微軟看來，非我族類，其心必異。

如果按照微軟的方式，我們今天可能都在使用 IE 和 VBScript（盡管我認(rèn)為 VBScript 在當(dāng)時(shí)是一種比 JavaScript 更有能力的腳本語言）。

他們甚至還逆向工程了網(wǎng)景的腳本語言 JavaScript，并將其命名為 JScript。

最終，微軟因壟斷網(wǎng)絡(luò)瀏覽器市場(chǎng)而被判有罪，裁定操作系統(tǒng)和瀏覽器必須分離，用戶應(yīng)有權(quán)選擇使用任何他們想要的瀏覽器。

在 VBScript、JScript 和 JavaScript 之間，最終勝出的是 JavaScript，因?yàn)殚_發(fā)者可以使用同一種腳本語言為多個(gè)瀏覽器進(jìn)行開發(fā)。

但曾有一段時(shí)間，網(wǎng)頁代碼中 JavaScript 和 VBScript 混用，造成了巨大的混亂。

注：還存在許多其他腳本語言，如 PerlScript 或 ASP。這與今天 WebAssembly 試圖解決的問題類似，即允許開發(fā)者在客戶端使用任何編程語言，同時(shí)確保性能和跨瀏覽器的兼容性。

3.jQuery 的誕生

在 2000 年初，Web 世界還像是一個(gè)亂世，存在許多相互競(jìng)爭(zhēng)的標(biāo)準(zhǔn)，廠商們還在摸索如何有效地為Web編程。

如果將今天的前端開發(fā)描述為復(fù)雜，那么那時(shí)它更是混亂無章，尋求幫助的在線教程寥寥無幾。

正是在這種背景下，jQuery 應(yīng)運(yùn)而生。它的初衷是為開發(fā)者提供一個(gè)統(tǒng)一的、能夠跨瀏覽器工作的 API。

在 jQuery 出現(xiàn)之前，如果你想處理 JS 事件，你需要為幾種不同的瀏覽器標(biāo)準(zhǔn)編寫不同的代碼，以確?？鐬g覽器兼容。

以下是一個(gè)展示 2005 年網(wǎng)絡(luò)開發(fā)難題的簡(jiǎn)短代碼示例：

function myEvent() {
  alert('click event');
}

// 檢查瀏覽器是否支持 addEventListener 方法。
if (elem.addEventListener) {
  // 為元素添加點(diǎn)擊事件監(jiān)聽器，使用標(biāo)準(zhǔn)的方法。
  elem.addEventListener("click", myEvent, false);
} else if (elem.attachEvent) {
  // 為元素添加點(diǎn)擊事件監(jiān)聽器，用于不支持 addEventListener 的老舊瀏覽器（如IE8及以下版本）。
  elem.attachEvent("onclick", myEvent);
}

jQuery 的實(shí)施效果非常好，它通過簡(jiǎn)潔強(qiáng)大的 API，解決了跨瀏覽器的兼容問題，使開發(fā)者無需操心這些問題。它的創(chuàng)新之處在于，它以瀏覽器的功能而非用戶代理為目標(biāo)，這一策略極大地改變了游戲規(guī)則。

上面的代碼可以用 jQuery 重新編寫，無需考慮瀏覽器兼容問題：

/**
 * 通過 jQuery 綁定點(diǎn)擊事件。
 */
$(function() {
  $('#elem').click(function() {
    alert('click event');
  });
});

我記得第一次在 QuirksMode 上讀到關(guān)于 jQuery 的文章時(shí)，對(duì)其簡(jiǎn)單的使用方式感到震驚。我只需添加一個(gè)腳本標(biāo)簽，一切問題即刻迎刃而解，僅需一行代碼。

jQuery 迅速成為 Web 開發(fā)者的新寵，廣泛應(yīng)用并推動(dòng)了我們今天熱愛并使用的許多現(xiàn)代 Web 標(biāo)準(zhǔn)的發(fā)展。

我們不應(yīng)忘記，盡管有人認(rèn)為 jQuery 的流行主要得益于 WordPress，但 jQuery 仍是當(dāng)今使用最廣泛的 JavaScript 框架之一。

在解決了瀏覽器 JavaScript 兼容性問題之后，jQuery 的下一步發(fā)展是其插件系統(tǒng)。

為了保持核心庫的精簡(jiǎn)，jQuery 設(shè)計(jì)了一個(gè)插件系統(tǒng)，允許開發(fā)者擴(kuò)展其功能。開發(fā)者們借此創(chuàng)建了眾多可復(fù)用的UI組件，例如著名的 jQuery 日期選擇器。

4.Backbone.js 與 AngularJS 登場(chǎng)

Backbone.js 于 2010 年問世，它是最早為客戶端 Web 應(yīng)用帶來結(jié)構(gòu)化設(shè)計(jì)，并邁向單頁應(yīng)用（SPA）的先鋒之一。

一些開發(fā)者認(rèn)為 Backbone 的重要貢獻(xiàn)在于促進(jìn)了前端開發(fā)理念的轉(zhuǎn)變，雖然不能忽視 YUI 庫在這方面的早期嘗試。

在 Backbone.js 出現(xiàn)之前，網(wǎng)站主要通過服務(wù)器端應(yīng)用推送 HTML 和 CSS 到客戶端瀏覽器，并通過 JavaScript 來“漸進(jìn)式”增強(qiáng)用戶體驗(yàn)，這就是“漸進(jìn)增強(qiáng)”的由來。

隨著網(wǎng)站交互性的增強(qiáng)，需要在客戶端維護(hù)一個(gè)與服務(wù)器端和 DOM 同步的數(shù)據(jù)模型。Backbone.js 通過其基于 MVC（模型-視圖-控制器）的架構(gòu)設(shè)計(jì)來滿足這一需求，這標(biāo)志著基于組件的 Web 開發(fā)的一個(gè)重要里程碑。

另一方面，AngularJS 作為谷歌的創(chuàng)新產(chǎn)品，首發(fā)于 2010 年，其后續(xù)版本 Angular 2+ （從2016年開始，統(tǒng)稱為Angular）不同于 Backbone.js，它不是一個(gè)庫。

Angular 是一個(gè)功能全面的 JavaScript 框架，它引入了“指令（directives）”這一概念（后被 Vue 采用），提供了一種擴(kuò)展 HTML 語法的優(yōu)雅機(jī)制，允許開發(fā)者創(chuàng)建自定義 HTML 元素，這在基于組件的開發(fā)中是一個(gè)劃時(shí)代的概念。

通過引入“指令”，Angular 實(shí)現(xiàn)了可重用組件的創(chuàng)建，顯著提高了代碼的維護(hù)性和可讀性，正如其市場(chǎng)宣傳所述。

總的來說，Backbone.js 和 Angular 都在 Web 開發(fā)社區(qū)中引發(fā)了關(guān)于如何創(chuàng)建更高效、可維護(hù)和可擴(kuò)展的客戶端應(yīng)用的重要討論，并推動(dòng)了基于組件的 Web 開發(fā)的熱潮。

5.利用 CoffeeScript 進(jìn)行轉(zhuǎn)譯

CoffeeScript 在 JavaScript 框架演進(jìn)中扮演了關(guān)鍵角色，主要體現(xiàn)在它引入了“轉(zhuǎn)譯”的概念，即源到源的編譯方式。CoffeeScript 的作者也是 Backbone.js 的開發(fā)者。

對(duì)于那些厭倦了處理 JavaScript 的復(fù)雜性和各種特殊情況的開發(fā)者來說，CoffeeScript 提供了一個(gè)解決方案：創(chuàng)造一種全新的語言，然后將這種語言轉(zhuǎn)譯成 JavaScript，使其能夠在瀏覽器中運(yùn)行。

比如，JavaScript 中的作用域和閉包常常讓新手和經(jīng)驗(yàn)不足的開發(fā)者感到困惑。尤其是 var 關(guān)鍵字導(dǎo)致的變量提升問題，以及函數(shù)作用域與塊級(jí)作用域的差異。

CoffeeScript 引入了 let 和 const，這兩個(gè)關(guān)鍵字幫助定義塊級(jí)作用域變量，減少了由于作用域引起的常見錯(cuò)誤。

除了提供更簡(jiǎn)潔的語法外，CoffeeScript 引入的高級(jí)功能，如解構(gòu)賦值、類和數(shù)組推導(dǎo)，極大地簡(jiǎn)化了 Web 組件的構(gòu)建過程。這些特性最終被納入現(xiàn)代 JavaScript 中，對(duì) JavaScript 的發(fā)展產(chǎn)生了深遠(yuǎn)的影響。

6.Node.js，JavaScript 的顛覆之路

Node.js 可以視為一股助燃劑，點(diǎn)燃了客戶端技術(shù)快速發(fā)展的潛行之火，推動(dòng)了今天我們使用的多種現(xiàn)代 JavaScript 標(biāo)準(zhǔn)的廣泛采納。

在 Node.js 出現(xiàn)之前，JavaScript 主要是一種客戶端語言，用來增強(qiáng)網(wǎng)頁的交互性。

Web 開發(fā)者在 JavaScript 開發(fā)工具方面選擇有限，大多依賴于瀏覽器的運(yùn)行時(shí)執(zhí)行，并常常需要借助其他服務(wù)器端技術(shù)手動(dòng)進(jìn)行代碼的壓縮和合并。

Node.js 的誕生使得 JavaScript 得以跨越到服務(wù)器端，允許開發(fā)者在瀏覽器環(huán)境之外執(zhí)行 JavaScript 代碼。

盡管 Node.js 的初衷是展示 JavaScript 的通用性，并承諾能夠簡(jiǎn)化 Web 開發(fā)流程、優(yōu)化代碼、捕獲錯(cuò)誤，并通過在服務(wù)器和客戶端使用同一編程語言來自動(dòng)化重復(fù)性任務(wù)，但實(shí)際上它觸發(fā)了相反的趨勢(shì)。當(dāng)然，這種趨勢(shì)的形成并非 Node.js 所能控制。

Node.js 提供了開發(fā)各種工具的平臺(tái)，催生了包括 Grunt、Gulp、Webpack、Babel 等在內(nèi)的豐富的包生態(tài)系統(tǒng)。

毫無疑問，Node.js 的另一個(gè)重要?jiǎng)?chuàng)新是其包管理器 NPM，該管理器極大地簡(jiǎn)化了 JavaScript 庫和工具的安裝與分發(fā)過程，為 JavaScript 的擴(kuò)展和應(yīng)用提供了極大的便利。

7.React 和前端工具的瘋狂演進(jìn)

我們已經(jīng)進(jìn)入了單頁應(yīng)用（SPA）、互動(dòng)豐富的 Web 應(yīng)用領(lǐng)域，React 在這里無需過多介紹了吧。

雖然 React 并未引領(lǐng)我們今天前端開發(fā)復(fù)雜的生態(tài)系統(tǒng)，但它確實(shí)改變了我們的開發(fā)方式，使之更加偏向于 React 的專有方式。

隨著對(duì)創(chuàng)建高交互性和高性能 Web 應(yīng)用的需求不斷增加，圍繞模塊化JavaScript 代碼開發(fā)了越來越多的工具。這種對(duì)技術(shù)的追求在一定程度上塑造了我們今天所見的開發(fā)環(huán)境。

我第一次接觸 React 是在 2014-2015 年，客戶的技術(shù)領(lǐng)導(dǎo)完全接受了 React 早期的 Flux 架構(gòu)。

當(dāng)時(shí)我強(qiáng)烈反對(duì)使用 JSX，這反映了更廣泛的 Web 開發(fā)社區(qū)的看法：“哪個(gè)理智的開發(fā)者會(huì)把 HTML 嵌入JavaScript中？！”

但現(xiàn)實(shí)就是這樣，HTML 最終被嵌入到 JS 中，接著是 CSS，像 Web 開發(fā)中許多事情一樣，你不得不逐漸接受它。

現(xiàn)在，管理和響應(yīng)瀏覽器中的應(yīng)用狀態(tài)并對(duì)其作出反應(yīng)，已成為主流。

React 開啟了這一變革，Vue 則繼續(xù)推動(dòng)這種以 JavaScript 為中心的開發(fā)轉(zhuǎn)變，鼓勵(lì)開發(fā)者使用 JavaScript 編寫一切，包括標(biāo)記語言和樣式，并提倡“一次創(chuàng)建，隨處使用”的組件理念（至少這是最初的承諾）。

React 通過 React Native 則更進(jìn)一步，承諾可以在包括移動(dòng)端在內(nèi)的任何平臺(tái)上使用一次編寫的代碼。

React 還加劇了前端開發(fā)中的反饋循環(huán)趨勢(shì)，隨著越來越多的工具和 JS 模塊被創(chuàng)建出來，為了在進(jìn)一步改進(jìn)或修復(fù)廣泛使用的主要 JS 框架的不足，這些框架的使用往往未經(jīng)過深思熟慮。

注：如果你有時(shí)間，不妨觀看 React.js 的紀(jì)錄片，其拍攝和制作質(zhì)量都很高。

React.js 紀(jì)錄片：https://www.youtube.com/watch?v=8pDqJVdNa44

8.TypeScript，復(fù)雜類型的系統(tǒng)修補(bǔ)

與 CoffeeScript 相似，TypeScript 是一種源到源的編程語言，并非 JavaScript 框架，但它在這些框架的演進(jìn)中起到了關(guān)鍵作用，這一點(diǎn)得到了微軟和無數(shù)開發(fā)者的認(rèn)同。

編程語言中的類型安全極為重要，但我對(duì)于在本質(zhì)上應(yīng)支持動(dòng)態(tài)類型的 JavaScript 上強(qiáng)加靜態(tài)類型持保留態(tài)度，畢竟這不應(yīng)視為缺陷。

在這方面，我贊同 DHH 對(duì) TypeScript 的批評(píng)，他指出了TypeScript的局限性，解釋了為什么他們的產(chǎn)品中避免使用它。

DHH 對(duì) TypeScript 的批評(píng)：https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01

在 TypeScript 出現(xiàn)之前，JavaScript 以其在大規(guī)模項(xiàng)目中的難以管理而聞名，這不僅僅是因?yàn)槿鄙凫o態(tài)類型。

然而，靜態(tài)類型的缺失并沒有讓 JavaScript 更出色，反而隨著項(xiàng)目的擴(kuò)大，調(diào)試和維護(hù)代碼的復(fù)雜性也在增加。

TypeScript 引入了如接口、枚舉類型和可選參數(shù)等強(qiáng)大功能，這些特性對(duì)于管理復(fù)雜的 JS 項(xiàng)目至關(guān)重要。

此外，TypeScript 還提供了開發(fā)工具支持，如更準(zhǔn)確的自動(dòng)完成、重構(gòu)能力等功能，大大提高了開發(fā)效率（同時(shí)，自動(dòng)完成和 lint 規(guī)則也可以通過 JSDoc 設(shè)置）。

但是，TypeScript 本質(zhì)上是在 JavaScript 之上增加了一層，帶來了可能并非對(duì)每個(gè)項(xiàng)目或開發(fā)團(tuán)隊(duì)都必要或適宜的復(fù)雜性和開銷。

盡管 TypeScript 提供了許多增強(qiáng)功能，但學(xué)習(xí)一種全新的語言及其語法、規(guī)則和最佳實(shí)踐的代價(jià)也不小。這對(duì)于小型項(xiàng)目或團(tuán)隊(duì)來說，可能是一個(gè)不小的挑戰(zhàn)。

TypeScript 要求開發(fā)者為變量、函數(shù)返回值和參數(shù)注明類型。雖然這在大型項(xiàng)目中有助于提高代碼的可讀性和調(diào)試性，但在小型項(xiàng)目中可能會(huì)拖慢開發(fā)速度。

總之，TypeScript 引發(fā)了關(guān)于在 JavaScript 中引入可選靜態(tài)類型的討論，促進(jìn)了語言的成熟，這無疑是一件好事。

9.Svelte，為前端開發(fā)帶來一絲光明

隨著前端開發(fā)者對(duì) JavaScript 生態(tài)系統(tǒng)的普遍疲勞，Svelte 應(yīng)運(yùn)而生，帶來了新的活力。

Svelte 試圖解決傳統(tǒng)框架導(dǎo)致的代碼膨脹問題。到目前為止，React、Angular 乃至 Vue 都已被視為傳統(tǒng)框架。

Svelte 還試圖降低學(xué)習(xí)難度，其他框架和庫的復(fù)雜性往往使初學(xué)者望而卻步。與之形成對(duì)比的是，Svelte 的設(shè)計(jì)宗旨是直觀易懂。

通過簡(jiǎn)化的語法和減少的樣板代碼，即使是只有基礎(chǔ) HTML、CSS 和 JavaScript 知識(shí)的開發(fā)者也能在較短時(shí)間內(nèi)掌握 Svelte。

Svelte 也可以看作是一種編譯類 HTML、CSS 和 JS 代碼的編程語言，而非解析常規(guī) HTML/CSS/JS 的解析器。

如果把 Svelte 視為一種編程語言，那么我們寫的代碼雖然看起來像 HTML、CSS 和 JS，但實(shí)際上并非如此。

/**
 * Svelte 組件示例。
 */
<script>
  let count = 0;
  function handleClick() {
    count += 1;
  }
</script>

<button on:click={handleClick}>
  Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

<style>
  button {
    color: blue;
  }
</style>

這就是 Svelte 為什么被歸類為 devDependencies 的原因，因?yàn)榕c React 等不同，我們?cè)谏a(chǎn)環(huán)境中不需要 Svelte 的代碼。

通常，在使用傳統(tǒng) JavaScript 框架的情況下，客戶端瀏覽器需要加載并執(zhí)行整個(gè) JavaScript 包，用戶才能與應(yīng)用互動(dòng)。

這個(gè)過程可能很慢，尤其在移動(dòng)或網(wǎng)絡(luò)慢的環(huán)境下，可能會(huì)對(duì)用戶體驗(yàn)產(chǎn)生不利影響。SvelteJS 通過在構(gòu)建過程中完成繁重的工作來解決這個(gè)問題。

與 React 不同，Svelte 在如何處理事務(wù)上持有更明確的立場(chǎng)，這在 SvelteKit 中表現(xiàn)得尤為明顯。

此外，Svelte 是首批開始探討多頁應(yīng)用（MPAs）在客戶端開發(fā)中地位的主要框架之一。在此之前，MPAs 被視為過時(shí)的開發(fā)方法，不再被開發(fā)者采用。

盡管如此，Svelte 仍在前端開發(fā)的復(fù)雜局勢(shì)中嘗試帶來一絲光明。

10.Htmx，前端開發(fā)的新視角

如果你還不熟悉 htmx，那也無妨。它是一個(gè)較新的 JavaScript 框架，更準(zhǔn)確地說，它是對(duì)現(xiàn)代前端開發(fā)的一種全新思路。

盡管 CoffeeScript、TypeScript 和 Svelte 試圖通過使用類似 JavaScript 的語言來修復(fù) JavaScript 的缺陷，htmx 的開發(fā)者則選擇了一條不同的道路——從零開始，完全不使用 JavaScript。

Htmx 使得 Web 開發(fā)者能夠直接在 HTML 中使用 AJAX、CSS Transitions、WebSockets、JS Events 和 SSEs（服務(wù)器推送事件），無需編寫大量的 JavaScript。

這種方法雖然不是全新的，但它以一種無縫的方式將靜態(tài) HTML 轉(zhuǎn)化為動(dòng)態(tài)內(nèi)容，為 Web 應(yīng)用增強(qiáng)提供了新的途徑。

與其他復(fù)雜的 JavaScript 框架不同，htmx 提倡一種更簡(jiǎn)單的 Web 開發(fā)方法，通過在 HTML 中直接實(shí)現(xiàn)動(dòng)態(tài) UI 交互，顯著減少了對(duì) JavaScript 的依賴。

這種方法強(qiáng)化了 Web 開發(fā)中的漸進(jìn)增強(qiáng)原則，即使用 HTML 和 CSS 構(gòu)建基礎(chǔ)和布局，而將 JavaScript 保留為增加必要交互性的輕量級(jí)工具。

Htmx 的簡(jiǎn)潔性可能令人不安，我們?cè)?jīng)深陷前端開發(fā)的復(fù)雜中不得自拔，而 htmx 提醒我們，許多它所采用的技術(shù)實(shí)際上早已存在，只是被我們忽視了。

通過后端語言的應(yīng)用，開發(fā)者可以在后端保持?jǐn)?shù)據(jù)和狀態(tài)，而前端則保持 UI 的動(dòng)態(tài)性和響應(yīng)性，這才是最理想的分工。

這種回歸簡(jiǎn)潔的趨勢(shì)對(duì)年輕開發(fā)者而言是一件好事，他們將發(fā)現(xiàn)在不依賴現(xiàn)代 JavaScript 框架的情況下進(jìn)行前端 Web 開發(fā)的樂趣。盡管如此，這并不意味著 React、Vue、Svelte 和 Angular 會(huì)很快消失，我們需要循序漸進(jìn)地接受這一變化。

全棧開發(fā)者的歸來預(yù)示著前端開發(fā)領(lǐng)域正在迎來更全面的技能要求和新的發(fā)展機(jī)會(huì)。

11.未提及的重要技術(shù)

我知道我遺漏了許多在現(xiàn)代前端開發(fā)中具有重要影響的技術(shù)，比如 Alpine、Astro、Babel、Bun、Dojo、EmberJS、Esbuild、ES6、ExtJS、Express、Gatsby、GraphQL、Jamstack、KnockoutJS、Lit、MeteorJS、MERN、MooTools、Next、Nuxt、Parcel、Polymer、Preact、PWAs、Remix、REST、RollupJS、Rome、Ruby on Rails、RxJS、SproutCore、Sass、Skypack、Snowpack、SolidJS、Stencil、Stylex、Vite、Vue、Zig 等等。這些技術(shù)在現(xiàn)代前端開發(fā)中都以某種方式做出了貢獻(xiàn)。

主要原因有：1) 我無法一一涵蓋所有內(nèi)容，2) 很多技術(shù)有相似的理念，最后 3) 我對(duì)其中許多技術(shù)不夠熟悉，難以做出深入的評(píng)價(jià)。