標題：我用每個前端框架都建立了一個應用

已發布：是

描述：對2026年前端Web框架的效能、開發體驗與可行性進行詳細比較

標籤：Web開發、JavaScript、前端、效能

封面圖：https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bvpk6r0jtqnifp2ljo45.png

發佈時間：2026年1月5日 16:20 +0000

太長不看

應該使用哪個框架？這取決於你正在開發什麼以及你的優先事項。但我做了一個簡單的比較工具，可以幫助你找到最適合你專案的技術堆疊。請參閱： Stack Match 。

只想看資料？我還用 10 個不同的框架建立了同一個應用，並進行了基準測試。原始碼和結果請參考framework-benchmarks程式碼庫。

方法論

我為什麼要寫這篇文章呢？因為我看到很多文章都在吹捧某些框架，或是貶低其他框架。但很少有作者能夠撥開迷霧，對所有*選項進行客觀公正的比較。

我的目的是簡要概述每個框架的獨特賣點、何時應該使用它們、它們的優點和缺點，並提及我的想法。

說到客觀公正，我需要用每個框架建立相同的應用程式，才能進行公平的測試（我已經做到了！）。但這只是第一個問題，因為簡單的應用程式並不能完全展現框架在實際場景中的功能。因此，我還附上了我用每個框架建造的實際專案。所有這些專案都已達到生產就緒狀態，擁有相當數量的活躍用戶和/或下載量（實際上，這些專案加起來擁有 100 萬年活躍用戶和 5 萬 GitHub 星標）。

由於前端框架數以百計，為了讓這篇文章篇幅合理，我只會介紹最新、最優秀的 10 個前端框架，並且我們主要關注開發者體驗（但也會包括效能基準測試）。

閒話少說，讓我們開始吧！

React

React無所不在，為超過130萬個網站提供支持，並被許多（或許是大多數）大型公司所採用。它已經存在超過12年，由Meta支持，擁有非常成熟的工具集和龐大的生態系統。因此，它成為許多團隊的首選也就不足為奇了。它非常穩定，並具有出色的向後相容性（但這實際上也是它的一個缺點，因為實現任何功能都有多種方法）。

但它並不完美。它加入了大量樣板程式碼，使得它的編寫比 Svelte 或 Vue 等框架更加冗長。虛擬 DOM 也帶來了相當大的效能開銷（實際上只是資料協調，但很容易誤用），記憶化通常需要手動操作，並發功能尚不成熟，即使進行了大量的 tree shaking，打包後的檔案仍然很大。

優點

• 工作機會很多

• 無所不在，龐大的生態系統，良好的社區支持，企業贊助

• 靈活性強，可以建立從單頁應用程式、電子郵件到行動應用程式（某種程度上）的任何東西。

缺點

• React雖然上手容易，但要精通卻需要時間，而且有很多地方容易讓初學者犯錯。

• 效能本身就比較差，而且虛擬 DOM 會增加額外的開銷。

• 與 Svelte 或 Solid 相比，Solid 的樣板程式碼量相當大。

我的想法

如果你在進行基於直覺的編程，React 具有巨大的優勢，因為人工智慧可以藉鏡的程式碼量非常龐大。同樣，如果你正在找工作，學習 React 絕對不會錯，因為它長期以來一直是大多數公司的主流框架。

話雖如此，我個人並不喜歡 React：它速度慢、體積大、枯燥乏味，而且有時比其他框架更複雜一些。

我發現，為了提升應用的效能，需要做很多手動工作，這令人沮喪。這導致程式碼冗長且容易出錯。儘管開發者工具非常完善，但檢查編譯後的輸出仍然相當繁瑣。由於 React 規格內容龐大且涵蓋面廣，我必須花費大量時間查閱文件。

我建造的

看法

Vue 是一個漸進式框架，這意味著它可以用於所有類型的應用程式，從簡單的 HTML 增強腳本到帶有 SSR 的完整單頁應用程式 (SPA)。與 Svelte 類似，它使用 SFC（單一檔案元件），每個.vue檔案都包含模板、邏輯和作用域 CSS。為了實現響應式，Vue 使用 ES2015 代理程式來追蹤依賴關係，並僅更新所需的內容，而無需手動進行快取。

優點

• 非常簡單、直覺、易學易用。

• 具有作用域樣式的優良單一檔案元件

• 簡單、細粒度的響應式設計和高效的依賴關係跟踪

• 官方路由、狀態和 SSR 工具（單獨打包）

缺點

• 雖然 Vue 的可擴展性很好，但在將其用於大型專案時，需要仔細考慮。

• 存在一些不一致之處（例如兩種相互競爭的選項 API 和組合 API）。

• 一些反應性注意事項（例如，對引用使用 .value，解構會失去反應性）

我的想法

Vue 可以被視為一個恰到好處的框架，它完美地融合了 React 的靈活性和 Angular 的結構性。 Vue 速度足夠快，也足夠有趣，並且經過了實戰檢驗，但在這些方面都沒有什麼特別突出的強項。

使用代理的響應式系統確實令人印象深刻。更改一個資料屬性，所有依賴它的資料都會自動更新。而且，這個生態系統比人們想像的要強大得多。

我選擇 Vue 作為 Dashy 的框架，因為它既具備我所需的一切，又非常容易上手，因此貢獻者可以加入自己的元件和功能，而無需經歷陡峭的學習曲線。

我建造的

苗條

Svelte 一直以來都是最受歡迎的框架之一，這並非偶然。它簡單、快速、輕量級，而且非常有趣。響應式程式設計直接內建在語言中，無需 hooks、代理或useEffect等繁瑣的操作；只需賦值給一個變數，它就會立即做出回應。

與其他許多框架不同，它不提供執行環境，也不使用虛擬 DOM。相反，元件會在建置時被編譯成高度最佳化的原生 JavaScript。因此，沒有執行時間開銷，你的打包檔案中也不會包含框架程式碼，並且在瀏覽器中可以獲得接近原生應用程式的效能。另外，編譯後的輸出也出奇地容易閱讀。

優點

• 比 React 或 Vue 更小、更快的打包

• 非常簡單的反應模型

• 比其他任何框架都少樣板程式碼

• 動畫是內建的

缺點

• 生態系統仍然比 React/Vue 小。

• SvelteKit 仍在完善中，穩定性可能略遜於 Next/Nuxt。

• 對於大型團隊或大型專案而言，這些工具的功能就不夠強大了。

我的想法

使用 Svelte 建立應用程式讓我感到很開心。我喜歡它既現代、直觀又快速，而且它的 SFC 與核心 Web 技術（僅包含 HTML、CSS 和 JS）高度契合。

Svelte 一直是我快速建立美觀且效能卓越的專案的首選框架。但我發現，如果不注意結構，大型專案很快就會變得一團糟。

對於有 15 個團隊在同一個程式庫上工作的大型企業儀表板，我可能不會使用它，在這些情況下，React 或 Angular 仍然能提供更高的可預測性、穩定性和工具支援。

我建造的

角

你可能認為 Angular 是一個老舊的框架，只用於遺留應用程式和企業環境。沒錯，後一種說法是正確的，但最近的版本（是的，它仍然非常活躍）包含了一些非常棒的功能，使其在 2025 年仍然是一個非常可行的選擇。

與其他框架不同，Angular 提供了所有必要的元件：路由、表單、HTTP、測試、國際化、動畫、SSR 等等——所有這些都由官方維護並深度整合。無需自行搭建技術棧。

但用這種語言寫作可能比較冗長。

優點

• 一開始就使用 TypeScript

• 如今非常穩定

• 大型應用程式所需的一切都已包含在內。

• AOT 模板編譯，使其速度比其他一些方法更快。

• 企業界有很多工作機會

缺點

• 更陡峭的學習曲線（RxJS、DI、模組、區域）

• 與 Svelte 或 Vue 等框架相比，它的語法過於冗長。

• 與 React/Vue 相比，開源社群或教學社群規模較小。

• 靈活性較低——你以 Angular 的方式建置。

我的想法

Angular 雖然不算酷炫，但它穩定、強大且可擴展。它幾乎沒什麼缺失，所以你不需要為了完成常見任務而安裝一大堆第三方依賴。

我覺得上手並不難，但確實需要從文件中學習很多東西，特別是模板語法、元件定義、指令、注入等等。唯一讓我感到棘手的是最初如何讓我的 SSR 路由啟用水合（hydration）。其他一切都很順利。

對於穩定性、結構和長期支援至關重要的大型應用程式，我會再次考慮使用 Angular，但對於小型應用程式則不太適用。

我建造的

點燃

Lit 是一個超輕量級的框架，用於建立基於標準的 Web 元件，它圍繞著現代瀏覽器 API（如自訂元素和 Shadow DOM）建置，當您需要與框架無關、可重複使用的 UI 元件時，它非常有用。

優點

• 使用原生 Web 元件和通用標準

• 效能優異，因為沒有虛擬 DOM，更新也最少且直接。

• 可與任何框架（或無框架）搭配使用

缺點

• 詳細文法：@click、?disabled、.value 等。

• 基於類別的元件感覺過時了。

• SSR 尚處於實驗階段，設定起來比較困難。

• 生態系和學習資源是小眾的

我的想法

我個人感覺，編寫 Lit 元件有點像回到了 React 的早期時代。元件是基於類別的，即使是最簡單的元件也相當冗長，包含大量樣板程式碼。

屬性表達式的語法很奇怪，我好幾次都搞錯了，忘記在屬性前面加點號（ . ），布爾值前面加問號（ ? ，事件監聽器前面加@ ），所有值前面加$

伺服器渲染仍處於實驗階段，在獨立的 Vite + Lit 專案中實現起來非常困難。

由於使用了 Web 元件和 Shadow DOM，每個元件都是完全隔離的。這有利有弊，但如果您不習慣這種方式，可能會發現全域 CSS 重設或樣式等操作無法如預期運作。

我建造的

馬可

Marko 是一種聲明式語言和高效能 Web 框架，由 eBay 建置和維護。

優點

• 語法簡潔，標記語言提供簡寫選項，無需匯入元件/自訂標籤

• 非常簡單的 SSR 和同構 UI 元件

• Marko run 輕鬆規劃路線

缺點

• 非常小眾且支援有限——你絕對不可能和 Marko 一起寫程式！

• 執行起來確實很棒，但如果你遇到問題，你就得自己深入研究 Marko 的源程式碼並解決它。

• 缺少文件（例如，底層 API部分為空）

我的想法

我其實很喜歡馬可的設計思路，模板化的設計很有道理。但感覺有點像在使用來自未來的框架，但同時又顯得有些過時，既具有未來感又帶有一絲懷舊氣息。

主要的缺點，而且是個很大的缺點，就是網路資訊非常有限。文件很少，你不能直接在 GitHub 上搜尋範例，AI 工具對 Marko 的基本原理一無所知，社群支援也很有限，甚至連智慧感知功能都非常有限。所以，如果你遇到問題，就只能自己去研究 Marko 的原始碼了。而且它還有一些怪癖，這些怪癖通常沒有文件說明（例如，如果你在頂級視圖或佈局中使用class {} ，所有互動功能都會失效，而且不會顯示任何錯誤訊息）。

儘管我很喜歡與 Marko 合作，但我並不認為它適合任何嚴肅的專案，原因很簡單，它的社區規模太小了。而且，我認為它不會再有持續的維護，因為過去幾年程式碼庫的活躍度一直在下降，eBay 似乎是唯一的核心維護者。

我建造的

jQuery

你以為我會忘記我們的老朋友 jQuery 嗎？ ！距離它首次發布已經快 20 年了，但 jQuery 仍然出現在排名前 10 萬的網站中的 70% 以上（這在很大程度上與 WordPress 的使用率相關）。

現在這個數字開始下降，而且理由充分——對於簡單的應用程式，jQuery 的許多功能現在都可以用現代 JavaScript 原生實現，而對於更複雜的應用程式，現代框架在這方面做得更好。

但今年早些時候，自 2016 年以來首次發布了新的主要版本jQuery 4 。

優點

• 沒有建構工具、依賴管理器、轉譯器等。

• 它經受住了實戰考驗

• 適用於支援不具備較新 JavaScript 功能的（非常）舊的瀏覽器

缺點

• jQuery 能做的很多事情，原生 JavaScript 也做不到。

話雖如此，我還是沒能下定決心用 jQuery 開發一款現代應用程式。雖然我（很多年前）曾用它做過複習測驗、實習生招募工具和使用者管理工具。

高山

它能讓你輕鬆地將響應式特性融入伺服器端渲染的 HTML 中（無需 SPA、水合或 SSR）。對於無需完整建置設定的簡單 UI 增強來說，它是理想之選。

Alpine 的巧妙之處在於它不會幹擾你的操作。 HTML 程式碼依然清晰易讀，JavaScript 程式碼量極少，即使 Alpine 載入失敗，頁面也能優雅地降級。這才是漸進增強的正確開啟方式——頁面在沒有 JavaScript 的情況下也能正常執行，載入 JavaScript 後即可互動。

語法非常自然： x-on:click="searchWeather()" , x-text="temperature" , x-bind:class="{'active': isExpanded}" 。它像 Vue 模板一樣聲明式，但直接存在於 HTML 中。當您修改資料時，響應式更新會自動發生。

優點

• 無需任何設定——只需一個<script>標籤即可工作

• 非常適合對 SSR 或靜態網站進行小幅改進

• 簡單易用的聲明式文法，靈感源自 Vue

• 預設啟用漸進增強

缺點

• 不適用於大型應用程式－缺少路由、狀態管理、服務端渲染等功能。

• 大型團隊的工具和架構有限

• 如果把大量邏輯塞進 HTML 屬性裡，可能會變得很混亂。

我的想法

Alpine 在實現簡單互動方面做得非常出色。如果您不需要完整的框架，而只需要模態框、下拉式選單、切換開關或輕量級的客戶端行為，那麼 Alpine 就是完美之選。

我建造的

堅硬的

Solid乍看之下與React非常相似，但其底層機制卻截然不同，速度也快得多。 Solid並沒有使用虛擬DOM，而是採用細粒度的響應式設計（類似Svelte和Vue的內部機制），只更新實際發生變化的部分。最終實現了極小的打包體積、幾乎零執行時開銷和卓越的性能。

你仍然需要編寫 JSX，仍然需要定義元件，仍然需要使用 Hooks——但預設情況下一切都是響應式的。訊號（ createSignal ）取代了useState ，計算會在依賴項變更時自動執行，並且不會出現不必要的重新渲染。這感覺很熟悉，但卻擺脫了 React 的那些繁瑣之處。

優點

• 速度極快：無虛擬 DOM、細粒度響應式設計、體積小巧

• 如果你有 React 背景，會覺得很熟悉。

• 可擴展性強，適用於大型、高度互動式介面

缺點

• 規模小得多的生態系統和社區

• SSR功能強大，但像SolidStart這樣的全端框架仍在發展完善中。

• JSX。

我的想法

Solid 感覺就像是「如果 React 是今天設計的，它本來應該是什麼樣子」。它擁有 React 的人體工學設計，卻避免了重新渲染的繁瑣、記憶化技巧以及性能陷阱。用它來建立程式碼真的非常流暢。但由於它仍然相對小眾，所以相關的庫、教程和招聘資訊並不多。

我建造的

星體

Astro與其說是框架，不如說是以內容為先的網站建立者。

Astro 使用靜態方式建立您的網站，預設幾乎不使用 JavaScript。互動性來自“島嶼”，這些島嶼是微小的獨立元件，可以使用您選擇的任何框架（例如 React、Svelte、Vue、Solid 等）編寫，用於加入互動功能，這些功能僅在需要時才在客戶端加載。

優點

• 最佳 SEO 選項（SSG、SSR），以及僅在需要時提供的所有互動優勢。

• 一流的MD/MDX支持

缺點

• 它適用於內容豐富的網站，但絕對不是單頁應用程式/互動式應用程式的理想選擇。

我的想法

對於部落格、文件、行銷網站，或「以靜態內容為主，輔以少量互動元素」的專案來說，Astro 的確很難被超越。我喜歡 Astro 的使用者體驗和靈活性，但它的確有其非常特定的應用程式場景。

我建造的

Van.js

Van 是一個非常小巧（真的非常小——不到 1kb）的即用型響應式 UI 框架，它不使用虛擬 DOM、建置工具、依賴項，也沒有複雜的抽象層。它完全基於普通的 DOM 節點，使用簡單的響應式原語（ van.state 、 van.derive ）在資料變更時更新 UI。它的使用體驗更接近“響應式原生 JavaScript”，而非傳統的框架。

API 的設計非常簡潔。你只需建立傳回 DOM 元素的函數來配置元件，直接在類似標記的呼叫中綁定狀態，就差不多了。沒有 JSX，沒有編譯器，沒有打包器，也沒有花俏的生命週期鉤子。只有 JavaScript 和 DOM API，以及一些響應式特性。

優點

• 體積小巧，速度極快，非常適合微型元件或嵌入式元件。

• 無需建置步驟；可在<script>標籤內執行

• 非常簡單的反應模型

• 如果你熟悉原生 JavaScript，那麼學習起來很容易。

缺點

• 絕對不適用於大型應用

• 沒有函數以外的元件抽象，沒有模板系統，沒有事件系統

• 對於簡單的響應式設計來說非常棒，但對於更複雜的情況來說很快就會變得難以駕馭。

我建造的

快的

Qwik 真是個神奇的東西。它徹底顛覆了 Web 應用的運作方式，實現了所謂的「可恢復性」——頁面無需任何 JavaScript 程式碼即可瞬間加載，然後各個元件只有在你與之互動時才會啟動。這就像一個網頁，在你觸碰它之前一直處於休眠狀態。

優點

• TTFB 超低，初始載入時 JS 檔案小於 1KB

• 對於具有複雜路由或動態內容的大型應用程式來說，它的擴展性非常好。

• 熟悉的開發者人體工學設計，採用 JSX + Vite + 訊號 + 基於文件的路由

缺點

• 需要伺服器端渲染（SSR），它不能完全在客戶端工作。

• 學習曲線較為陡峭，有些概念（例如斷點續傳和序列化）起初對開發者來說可能比較陌生。

• 除錯可能很複雜，因為邏輯分散在伺服器邊界之間。

我的想法

如果你正在開發一款規模龐大或結構複雜的應用程式，並且需要極高的效能，那麼 Qwik 無疑是最佳選擇。誠然，它的使用者群體較小，學習曲線較為陡峭，也比其他方案更為複雜，但當每一位元組都至關重要時，這些缺點都是可以接受的。

我建造的

等等——如果你開發的是不同的應用程式，那麼這個測試就不公平了！

你說得很有道理，但別擔心──我罩著你！

為了更公正地比較這些框架，我還分別在它們各自中建立了一個相同的迷你應用程式，並對每個應用程式進行了基準測試以比較效能。

您可以在這裡查看：https://github.com/Lissy93/framework-benchmarks。

我們使用一套共享測試套件來確認每個應用程式都符合相同的要求，每個應用程式都使用相同的共享資源和樣式。此外，我還有一套效能基準測試腳本來執行所有實際的效能測試。這些結果會被處理並放入results分支，同時也會產生一些圖表和摘要，這些內容可以在主自述文件和框架基準測試主頁上找到。

結論

好了，12 個框架，12 個應用程式（以及 12 年的痛苦經驗）。如果你正在為下一個專案選擇框架，不妨試試Stack Match這個框架比較工具。

如果你喜歡這類內容，不妨關注我🩷

我在 GitHub 上的用戶名是@Lissy93 ，在 DEV 論壇上的用戶名也是 @lissy93。我開發了很多開發者工具、安全和隱私應用以及適用於 Linux 的自託管軟體，你可以在我的網站 https://010000010110110001101001011000110110100101100001.com 上查看（沒錯，網域名稱很容易！

總之，感謝閱讀，祝您程式愉快，新年快樂！

哦，差點忘了──哪個框架才是最好的？嗯，那顯然是[字數限制已到]。

原文出處：https://dev.to/lissy93/i-built-an-app-in-every-frontend-framework-4a9g