21世紀已經過去四分之一,瀏覽器悄悄演變成遠不止於一個使用者介面層。它可以執行複雜的運算、利用GPU、處理音訊、模擬物理現象,甚至執行機器學習模型。然而……大多數時候,我們仍然把它當作表單和儀表板的工具。

我想展示一下,當我們真正利用平台已經提供的功能時會發生什麼。

波隆那的 jsday 大會剛落下帷幕,真是太棒了!如果你還在猶豫是否值得參加這類活動-我的答案是:絕對值得!它能為你提供源源不絕的靈感,遠遠超過你從文章或教學中獲得的。如果你有空,請幫我點個贊,我的LinkedIn 貼文就太好了。

| 一位女士在大會上發言 | 一位女士站在會議橫幅附近 | 冰淇淋 |

|---|---|---|

如果你一直關注我的帖子,你可能知道我的演講是關於 WebGPU 和 WebAssembly,以及我們在瀏覽器中使用它們可以獲得什麼好處。

那麼這兩種技術是什麼呢?為什麼將它們放在一起討論比分開討論更有意義?

它們的設計初衷就是互補的。 WebAssembly 執行在 CPU 上,讓我們可以直接在瀏覽器中執行底層編譯程式碼。顧名思義,WebGPU 讓我們能夠存取 GPU——不是以某種抽象的、受限的方式,而是以相對直接且強大的方式。

如果你想深入了解,我在這裡寫了更多相關內容:

WASM → https://dev.to/sylwia-lask/will-webassembly-kill-javascript-lets-find-out-live-demo-43ln

WebGPU → https://dev.to/sylwia-lask/why-webgpu-feels-like-the-future-of-the-web-live-demo--2bjh

但我不想孤立地談論它們,而是想舉一個具體的例子來說明當它們結合在一起時會發生什麼。

因為我不喜歡沒有實踐的理論,所以我做了一個小示範。

👉 程式庫: https://github.com/sylwia-lask/text-goes-boom

👉 線上示範: https://sylwia-lask.github.io/text-goes-boom/

(友情提示-尤其是 JS canvas 基準測試,會讓你的 CPU 溫度很高😅)

它的作用是什麼?你在輸入框中輸入文字,文字會被轉換成粒子。當你點擊並拖曳滑鼠時…文字就會爆炸。

完全沒用?是的。有點上癮?也算吧😅

應用程式截圖


底層發生了什麼事?

首先,使用純 JavaScript 和 Canvas 2D 將輸入的文字渲染成點陣圖影像。這類任務完全可以使用經典的瀏覽器 API 來完成,沒有理由將其遷移到其他地方——尤其是在像這樣的演示中。

接下來,點陣圖被傳遞給 WebAssembly。在這裡,我執行了一個故意設計得「有點過於複雜」的演算法,將圖像映射到粒子上。我希望 WASM 能真正做些有意義的事情,而且說實話——看起來也更酷。出於好奇,我把它和用 JavaScript 寫的等效實作進行了基準測試。

WASM 與 JS 的效能比較測試。 WASM 的速度是 JS 的 2.5 倍。

如你所見,這是我們獲得第一個實質優勢的地方。在這種情況下,WebAssembly 的速度大約是 Rust 的 2-3 倍。而且這還不是最佳情況——為了公平起見,不讓 Rust 輕鬆勝出,我還投入了相當多的精力來優化 JavaScript 版本。

在這個特定的演示中,差異並不大,因為這一步驟在重建過程中只執行一次。但這並非個例,而是關乎數量級。如果你需要執行類似的操作成百上千次,會發生什麼事?這時,問題就變得非常現實了。

接下來,事情就變得有趣起來了。

粒子被傳遞給 WebGPU——而這正是瀏覽器真正開始展現強大效能的地方。

在我的機器上,「經典」的 JavaScript + Canvas 2D 實作方式在處理大約 4 萬個粒子時就開始吃力了。

應用程式畫布 2D 實現

幀率下降,一切都變慢了,你很快就會感受到效能瓶頸。

同時,WebGPU……卻絲毫沒有受到影響。

超過50萬個粒子,每個粒子都有其獨特的物理特性。動畫流暢,幀率穩定。

WebGPU渲染超過50萬個粒子

這時,它不再只是小幅優化,而是帶來了完全不同的效能提升。同樣的瀏覽器,同樣的應用程式,同樣的電腦——但性能卻截然不同,僅僅因為用了合適的工具。


這到底有什麼意義?

這顯然不是典型的前端 CRUD 設定。你可能不需要 WebGPU 來建立儀錶板或表單,而且在很多情況下,真正的瓶頸是網絡,而不是計算。

但對於某些類型的問題,這種方法可以帶來巨大的改變:即時資料視覺化、實體模擬、圖形密集型介面、音訊處理、遊戲、影像或視訊轉換,當然還有像機器學習和 LLM 這樣的矩陣密集型工作負載,這些工作負載直接在瀏覽器中執行。

有趣的是,你平常並不需要它……直到突然間你真的需要它。產品不斷發展,需求增加,效能變成問題,或你想把部分工作負載從後端轉移到客戶端。這時,事情就開始變得有趣。


還有一件事

如果你查看程式碼庫,你可能會注意到一些重要的東西。

這是一個普通的 React 應用。

這裡沒有奇特的架構,也沒有什麼「來自外星球」的技術堆疊。沒錯,它確實使用了編譯成 WASM 的 Rust 程式碼,也用到了 WebGPU 著色器——但它們只是簡單地嵌入到標準的前端架構中。應用程式的其餘部分看起來和明天就可以在自己的專案中開始開發的東西完全一樣。

這是有意為之。我想表明,這並非遙不可及、只適用於小眾應用場景的實驗性平台。它完全可以整合到實際應用中——在真正需要的時候,逐步整合即可。

當然,WebGPU 目前尚未得到普遍支持,因此您需要一個備用方案。但就目前而言,對於絕大多數用戶來說,沒有理由不開始探索這項技術。


最後想說的

瀏覽器不再只是渲染使用者介面的地方。

這是一個強大的運算平台——它開箱即用,讓我們能夠同時使用 CPU 和 GPU。

並非每個專案都需要 WebAssembly 或 WebGPU。大多數情況下,沒有它們也完全沒問題。

但是,一旦你開始遇到性能瓶頸,或者你的問題從“移動資料”轉變為“實際計算”,你可能會意識到平台其實一直都有解決方案。

你只需要使用它就行了。 🚀


原文出處:https://dev.to/sylwia-lask/most-apps-are-slower-than-they-need-to-be-heres-why-live-demo-2hh8


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝4   💬4   ❤️2
346
🥈
我愛JS
📝1   💬3   ❤️2
110
🥉
Gigi
2
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
📢 贊助商廣告 · 我要刊登