我承認我不確定今年是否會寫這篇文章。撰寫讓人們對新技術的潛力感到興奮的文章很容易。但 2024 年是接受現實的一年。
過去的幾年是對未知事物的探索。我們興奮地進入了今年。終於到了對這些進步進行改進的時候了。他們有。但有一點是非常清楚的:
對簡單性的追求並沒有讓 Web 開發變得更簡單。
顯然,有些事情變得更容易做,但整體情況並沒有變得簡單。我們已經知道這一點了。但 2024 年情況發生了變化,部分原因在於全球經濟緊縮預算和確保解決方案走在安全道路上的壓力。我認為人們終於承認沒有靈丹妙藥。困難的問題很難解決。
不僅工具複雜,問題也很複雜。在回歸基本面的同時,我們必須在每個角落都遇到障礙,只有重新發明輪子才能回到那個根本的地方。
這是一個發人深省的想法,但它給了我希望,我們可以在 2025 年花一些時間重新評估。這要從反思 2024 年開始。
讓事情變得「伺服器優先」一直是過去 5 年前端領域的主題。這不是一個新概念,網路誕生於伺服器上,但經過十年以客戶端為中心的單頁應用程式後,很明顯鐘擺已經擺動得太遠了。特別是對於頁面負載敏感的網站,它們並沒有從增加的互動性中受益太多。
隨著網上購物習慣的興起和低利率推動的資本湧入,這種流行病只會加劇這種情況。結果是我們得到了一堆新的伺服器優先元框架,如 SvelteKit、Astro、Remix、SolidStart、Qwik、Fresh 和 Analog,以及對 Next 和 Nuxt 等現有框架的重大升級。
在過去的幾年裡,受SPA 影響的同構(相同的程式碼在客戶端/伺服器上以不同的方式執行)方法與受MPA 影響的分割執行(孤島/伺服器元件)方法進行了對抗,以尋找適合所有人的通用解決方案。這是兩個對立面試圖在中間接近對方的練習。這導致了 Next App Router 和 View Transitions Routing 等路由以及伺服器功能、樂觀更新、伺服器孤島和單次飛行突變等技術的驚人發展。但即便如此,差距仍然比任何人想像的都要大。
當您組裝所有這些功能時,事情就不再那麼簡單了。我們是否正在解決我們所要解決的問題是值得商榷的:
衡量成功非常困難。我們已經看到基準測試失敗了
我們已經看到,當根本原因在其他地方時,性能卻歸因於新技術
由於不想費力地解決這個混亂的問題,我們又回到了更傳統的伺服器方法。存在於「SSR」之外的那些。您不嘗試在伺服器上執行客戶端 JavaScript 框架。對於有意義的專案來說,這一直是個不錯的選擇。但這也無趣。
如果不需要改進以前的情況,我們就不會取得今天的成就。這可能需要大量的試驗和錯誤。最簡單的工具就是正確的答案,但是當問題不再簡單時,您將需要適合您的選項。
如果說 2021/22 是重置為更簡單的基礎,回到我們在伺服器上的起點,那麼 2024 年提醒我們簡單並不總是有效。
編譯是 JavaScript 開發中始終存在的一個面向。每當我們遇到障礙時,無論是瀏覽器功能支援、笨重的語法,還是解決語言缺點的能力,我們都會為此建立一個編譯器。
目前它已經無所不在,標準委員會正在考慮朝這個方向引入新功能。編譯和擴充捆綁是現代 JavaScript 應用程式建立方式的核心。它也是 JavaScript 工具中最複雜的根源。
好處是巨大的。類型、Linting、Treeshaking、程式碼分割、縮小、同構、巨集、DSL、整體創作/分散式部署。過去15年該領域的每一項進步都是建立在這個基礎上的。相比之下,沒有任何替代方案可以被認為是足夠的。稱之為不幸。稱其為 JavaScript 語言的限制。稱之為必要的複雜性。但否認這一點是徒勞無功的。
然而,如果我們想了解複雜性,那麼了解其來源至少很重要。 2024 年最有趣的發展,很大程度上要歸功於 React Compiler 和 Svelte 5 Runes 的發布,這使得對話變得多麼混亂。
一方面,我們有 React Compiler,一種自動最佳化編譯器,它可以以減少不必要的重新執行而無需手動幹預的方式轉換程式碼。原則上與 2019 年發布的 Svelte 3 編譯器非常相似。
這是兩個主要的編譯器專案,它們的差異令人質疑這兩個專案的基本性質。 React 承認重新渲染對於優化來說確實很重要。 Svelte 放棄了其最少的語法,換成了一種更具表現力的語言,具有增強的功能和更好的性能基礎。諷刺的是,這些立場都與其最初的賣點完全相反。
有趣的是,與現有方法相比,這兩種選擇都是以工具複雜性增加為代價的。
這些最終是否會對這些專案有利,目前還沒有定論。共同點是,當我們嘗試建立解決方案以使開發變得更容易時,我們所建立的基礎變得越來越複雜。
如果編譯和捆綁是基礎,那麼很明顯,這些是為人工智慧提供未來建立非常動態的解決方案所需的工具的基礎部分。雖然我們每年都看到這些工具在改善本地開發人員體驗方面產生了更大的影響,但人工智慧對 JavaScript 框架本身的影響仍然很小。
今年年初,我們看到 Devin 透過建立簡單的應用程式而成為頭條新聞。儘管它確實讓人質疑我們對這項技術的期望。僅僅讓某些東西發揮作用就足夠了還是需要做得很好?
從這個意義上說,像 Vercel v0 這樣的技術在建立原型方面已經取得了巨大的成功。也許這就是目前最大的優點。
MillionJS 開發人員 Aiden Bai 的 React Scan 再次引起了我們的注意,它可以掃描您的應用程式是否有效能問題。
雖然有人可能會認為重新渲染不一定是問題的徵兆,或者在 React 中尋找重新渲染的練習就像在桶裡射魚,但它確實讓我看到了開發工具的潛力。
如果任務很複雜且核心工具也更複雜,那麼支援工具的出現來滿足這一點是有意義的。這不僅僅是發展中的左移。整個領域的需求都充分整合了。雖然 Biome(以及先前的 Rome)設定了這個目標,但該領域的新玩家,如 VoidZero(來自 Vue/Vite 的建立者 Evan You)表明,這個基礎對於下一步的發展至關重要。
我們已經開始看到鐘擺在 2024 年中期出現一些回擺,Sveltekit、SolidStart 和 Remix 中的 SPA 模式。 Remix 將其非伺服器功能移植回 React Router。 SolidStart 對伺服器功能和單次飛行突變的附加方法為基於相同原理建置的 Tanstack Start React 框架奠定了最終基礎。
我們也看到本地優先/同步引擎技術的成長。這將如何體現仍有待觀察,但我預計這將成為 2025 年的持續趨勢。
今年 JavaScript 調查結果吸引我的一件事是,在人們對我們的工具日益增長的不滿情緒中,有些工具比其他工具表現出更多的正面成長。這與保留(滿意度)略有不同,後者專注於該工具的當前用戶並迎合較小的玩家(SolidJS 和 Svelte 多年來一直位居該列表的首位)。
它們不是我經常談論的工具,但當經濟緊張且維護成為問題時,它們往往會大放異彩。 Vue 和 Angular 都是我明年關注的框架。並不是因為我期望這裡的一些創新會讓我震驚,而是因為這些工具在讓開發人員感到高興方面付出了額外的努力。有時最好的工具並不是「最好」的工具。
眾所周知,現在幾乎所有非 React 框架都執行 Signals。但一段時間過去了,開發人員開始了解目前權衡的深度。雖然這是作者的偏見,但這些都是小問題,但我確實希望人們能對 React 有新的認識。這是他們應該一直擁有的感激之情,但這並不能成為 React 任何缺陷的藉口。但一切都是一連串的權衡,只有了解了雙方,你才能欣賞自己所做的選擇。
話雖這麼說,訊號仍在不斷發展。過去幾年,這一領域的集體經驗得到了極大的成長。我預計明年較小創新的集體成果將以我們從未見過的方式展示這種方法的獨特價值前景。
……真的是笑話。
與往年不同,我並不預測未來 12 個月內會出現重大技術飛躍。我不知道整個社會是否會接受。我看到對話從可恢復性與部分水合是否有意義,轉向誰擁有最好的模板語法。這是循環的一部分,有助於即將到來的反思和創新。但今天不行。沒關係。
我們有很多複雜的事情要處理。關於哪些技術值得我們投資和努力,需要做出很多艱難的決定。下一代解決方案的原始功能現已存在,但我不確定我們是否已經以可消耗的形式看到了正確的各個部分的組合。但至少我們開始承認,在追求簡單性的過程中,我們走上了一條以新方式增加複雜性的道路。
單一的解決方案還沒有出現。 HTMX 不會佔領世界,但它是一個很好的選擇。 React 不一定比其他解決方案更複雜。非同步和客戶端/伺服器互動是一件複雜的事情。編譯器不能解決所有問題。但他們可以做很多事:
我們生活在一個充滿複雜性的世界,而且這種情況似乎不會很快改變。因此,2025 年感覺是靜下心完成工作的好時機。
對於那些尋找下一個偉大事物的人?環顧四周。有很多有趣的問題需要解決。在你我之間,這就是我茁壯成長的環境。
原文出處:https://dev.to/this-is-learning/javascript-frameworks-heading-into-2025-hkb