我們都希望我們的網站看起來有吸引力，並且在多種設備和螢幕尺寸上感覺快速且響應靈敏。前端生態系統中開發了一些通用工具來幫助建立此類介面。

最常見和眾所周知的是React ，還有許多其他共享這個空間，例如Svelte 、 SolidJS 、 Angular 、 Vue 、 Qwik等等。所有這些都是令人印象深刻的工程壯舉，並帶有大膽的陳述。

反應：

Web 和本機使用者介面的庫

堅硬的：

用於建立使用者介面的簡單且高效能的反應性。

VueJs：

一個用於建立 Web 使用者介面的平易近人、高效能且多功能的框架。

無論如何，他們都有一些共同點…

JavaScript

如果您打算使用這些框架之一編寫整個專案，那麼無論好壞，您都將用 Javascript（或 Typescript）編寫所有邏輯。畢竟，Javascript 是網路語言，對吧？它就在瀏覽器中，用同一種語言編寫 Web 應用程式似乎是很自然的事。

只是，如果您要編寫一個全端應用程式並具有伺服器渲染或靜態渲染的頁面，您很可能會使用元框架，例如NextJs 、 Remix 、 SvelteKit 、 SolidStart 。

這意味著您將需要一台伺服器，它也將執行 Javascript。您在這裡實際上沒有選擇，框架在這種情況下強制要求您的架構。

方便勝過簡單

但這不是問題吧？我的意思是，上手非常簡單。讓我們看幾個啟動和執行的範例。

下一個J：

npx create-next-app@latest
cd my-project
npm run dev

固體啟動：

npm init solid@latest
cd my-project
npm install
npm run dev

在這兩個範例中，它都會使用一些合理的預設值引導專案，並讓您在幾分鐘內啟動並執行具有開箱即用熱重載功能的開發伺服器。這太棒了，感覺像是一次很棒的開發者體驗，對吧？

假設您想要為您正在開發的專案建立一個新的 Web 應用程式。您可以在幾分鐘內讓 NextJs 中的伺服器端渲染互動式應用程式啟動並執行，然後開始建置。這可能感覺很棒，但是您的應用程式真的需要如此設計才能滿足其需要執行的功能嗎？

您是否真的需要一個建置步驟來將模組和 JSX 轉譯為 JS 包，該包可以在伺服器上執行以生成初始 HTML，使用一堆 JS 流式傳輸到客戶端以水合 dom 節點並保持客戶端狀態跟踪虛擬DOM 並在每次更改時重新渲染？

快速啟動和執行可能很方便，但我們不要忘記方便性並不等於簡單。在幕後，抽象層層疊加，讓「魔法」發生，隨著時間的推移和專案規模的擴大，這可能會給你帶來困擾。

跟上依賴關係

在上面的範例中，我們設定了一個基本專案以在 NextJs 和 SolidStart 中啟動並執行。不過，這裡有一些有趣的事情我想強調一下。安裝 NextJs 後（在多個已棄用的軟體包警告下方），npm 會輸出這一行：

added 361 packages, and audited 362 packages in 10s

對於 SolidStart：

added 569 packages, and audited 572 packages in 18s

這些是我們初始化專案時 NextJs 和 SolidStart 分別需要和下載的套件的數量。

這僅適用於框架，它不包括您在專案中可能需要存取的任何套件。想要有一個程式碼格式化程式來強制格式化一致嗎？下載更漂亮。想要強制執行一些程式碼規則嗎？下載 ESLint。想要有類型嗎？下載打字稿。想要執行測試嗎？下載 Jest（或可能是 Vitest），這樣的情況就會持續下去。

雖然這看起來微不足道，但我認為這表明我們可能沒有按照預期使用 Javascript，我們最終不得不使用套件來執行相對常見的操作。這會導致依賴關係與依賴關係之間的依賴關係（在此處插入node_modules meme）。

需要如此多的依賴關係本質上使您的專案變得熱血沸騰。如果您 6 個月不碰這個專案，當您再回來時，您可能會發現它已經過時了。

不用擔心！您不需要讓事情保持最新，對嗎？嗯，這取決於。假設您具有安全意識，並使用Dependabot之類的工具來掃描您的依賴項是否有漏洞。您可能會發現每週都有幾個依賴項，特別是如果您的專案有數千個依賴項，這對於中型到大型專案來說並不少見。

假設您根本不關心更新。專案越老，避免釋放依賴瀑布就會變得越困難。最終，當需要更新 Node、想要使用新發布的功能或加入與另一個過時相依性不相容的新套件時，您將不得不打開閘門。

另一方面，我看到一些專案想要保持所有依賴項的最新狀態，這可能會導致每天更新多個包，有時會引入一系列有趣的錯誤和怪癖，使其通過測試並投入生產。

將其推斷到多個專案，突然之間，它會讓人感覺像是一種持續的背景壓力，並且每週都要測試和更新專案以保持它們的相關性並避免積滿灰塵，這成為每週的苦差事。

快速發展的生態系統

您可能已經看過“又一個 JS 框架”這個梗。從更積極的角度來說，我們可以說生態系統不斷創新、進化和變化。這些專案投入的大量工作和熱情確實令人印象深刻。但是，在生產中使用 Web 應用程式時，這也會產生負面影響。

如果您已經在這個領域工作了一段時間，您可能已經使用create-react-app建立了您的第一個 React 專案來啟動並執行。太糟糕了，現在它已被棄用，也許你應該轉向 Vite。也許您使用 Gatsby 製作了第一個靜態 React 專案。嗯，現在已經不建議使用了，您可能應該遷移到 NextJs 或 Remix。已經在使用 NextJs 了嗎？您可能應該遷移到應用程式路由器。也許您開始將 React 元件編寫為具有邏輯生命週期掛鉤的類別。嗯，這是舊方法，您現在應該編寫功能元件，並希望將正確的依賴項傳遞給useEffect掛鉤。但是等等！等一下，React 伺服器元件已經出現，並且智慧編譯器即將推出。

這種不斷的轉變和試圖保持領先地位增加了技術債務，並增加了保持專案最新的負擔。想想今天使用 React 時需要了解的所有概念，與 2016 年新推出的 React 相比。最佳實踐。

開發者經驗謬誤

這讓我想到了開發者體驗。當然，到目前為止我們所看到的一切都可以被視為對這些框架所能提供的出色開發人員體驗的權衡？

雖然我確實相信目前的開發人員體驗很棒，但我覺得經常被忽略的是隨著時間的推移開發人員的體驗。當然，在幾秒鐘內啟動一個新的開發伺服器，並且幾乎可以即時熱重新加載更改，感覺很棒- 但如果您多年來跟踪每次需要重構、升級或維護專案的情況，那麼突然之間，這種體驗就變得很糟糕。

那麼，有哪些要點呢？

使用適合工作的正確工具

在建立 Web 應用程式時，不要只接受 Web 框架是預設且最佳的選擇。查看您的用例。它需要是單頁應用程式嗎？您需要這樣級別的客戶端互動嗎？您可以使用HTMX之類的東西和您選擇的任何語言來產生頁面來實現類似的目標嗎？

保持簡單

技術很酷，但有時我們只需要足夠好的東西，並以簡單的方式完成它需要做的事情。這可以幫助我們保持理智並避免倦怠感。避免過早的抽象，嘗試堅持網路標準並且不要擴展到月球。

作為開發人員，我們可能會擔心太多，並專注於完美和最好的做事方式。讓我們不要忘記享受樂趣、探索和學習。如果不起作用，那就意味著你學到了一些東西，以後隨時可以改變它。

原文出處：https://dev.to/manonbox/hidden-cost-of-frontend-frameworks-5pi