🔧 阿川の電商水電行
至少在過去的八年裡，我一直聽到前端即將消亡——或者至少是 JavaScript 即將消亡的說法。據說， WebAssembly （以下簡稱 WASM）是將會徹底取代前端的工具之一。
很久以前就有人告訴我，JavaScript 基本上已經過時了，我們很快就會用 Rust 或 Go 來寫前端應用程式。
同時——儘管我有很多缺點——但我確實有一個優勢：我可以簡單而有趣地解釋事物，即使話題非常枯燥乏味（比如 80 年代波蘭的畜牧業——相信我😅）。
我在網路上找到的文章大多屬於以下兩種情況：
-
WASM 統治力嚇壞了所有人☠️
-
或一些非常專業的深度解析，不太適合初學者。
所以我想稍微揭開WASM的神秘面紗，並寫一篇客觀的文章：
-
為什麼它不會很快扼殺 JavaScript
-
而當它真的徹底擊敗JS的時候
TL;DR 🧠
這裡有一個包含 WASM 與 JS 基準測試的小型線上演示以及 GitHub 程式碼庫。
如你看到的：
-
JavaScript 本身速度已經非常快，完全可以勝任大多數任務。
-
但說到繁重運算，WASM 就具有很大的優勢，即使沒有像 SIMD 這樣的高階優化也是如此。
你的機器上也會出現類似的結果嗎？
歡迎在留言區分享！ 😊
⚠️ 我故意沒有驗證輸入內容 - 請小心，很容易導致瀏覽器標籤頁凍結。
示範： https://sylwia-lask.github.io/wasm-js-bench/
倉庫位址： https://github.com/sylwia-lask/wasm-js-bench
我們到底該如何寫 WebAssembly 程式碼呢？ 🤔
讓我們從基礎知識開始。
編譯成 WASM 的程式碼通常是用以下底層語言寫的：
-
鏽
-
去
-
C/C++
為什麼不選擇更方便的語言，例如 Python 或純 JavaScript 呢？
首先，一個雖小但很重要的澄清🙃
WebAssembly不是 CPU 原生機器碼。
它是一種可移植的字節碼格式，瀏覽器隨後會將其即時編譯成機器程式碼——這與它們對 JavaScript 的處理方式非常相似。
那麼，為什麼選擇這些語言呢？
Python 或 JS 的主要問題不在於“笨重的編譯器”，而在於：
-
動態型別
-
執行時間長
-
垃圾收集
-
不可預測的記憶模型
WASM 的設計圍繞著一個簡單、可預測的執行和記憶體模型，這更適合 Rust 或 C++ 等語言。
（是的，WASM GC 確實存在並且正在發展——但它距離主流生產應用還很遠。）
我為什麼要用 Rust 🦀
在我的演示中，我使用了Rust ，主要是因為它的執行時間幾乎為零，並且可以讓你非常明確地控制記憶體。
我發誓——它的基本配置其實並不難設定。
我甚至在Windows系統上也成功做到了！
我只需要安裝整個 Visual Studio 工具鏈…這正是我們喜歡 Linux 的原因😌
Rust 本身經常被描述為「打了興奮劑的 TypeScript」 。
這顯然不是一回事，但：
-
它對類型要求非常嚴格。
-
any -
這對TypeScript開發者來說，一開始可能會比較惱人…
但你很快就會意識到它能防止多少bug❤️
Rust 也引入了所有權和借用等概念，但這裡我就不深入探討了。
如果你想深入了解，光是 dev.to 就有大量的優秀 Rust 文章。
編譯為 WASM
編譯過程本身非常簡單，可以輕鬆整合到您的 CI/CD 管道中。
如果你好奇編譯後的輸出是什麼樣子，以及它實際上是如何在 JS 中使用它的，請查看倉庫 - 我特意提交了編譯後的文件，以便你可以檢查它們。
好的，但是…什麼時候該用WASM，什麼時候用JS比較好呢？ ⚔️
您可以在演示中自行查看所有內容。
基準測試程式碼已在 GitHub 上公開，所以你可以驗證我沒有對 WASM 或 JS 作弊 😄
再次提醒：輸入值由您自行負責－瀏覽器標籤頁很容易凍結。
JavaScript 速度真的很快🏎️
WASM 的速度快得驚人——但瀏覽器引擎的開發者們也絲毫不懈怠。
在V8或SpiderMonkey等引擎中，JIT 編譯的效果好得驚人。
所以如果：
-
你正在編寫一個普通的前端應用程式
-
一個簡單的 CRUD
-
大量的 DOM 交互
純 JavaScript整體上速度可能更快。
即使是相當繁重但簡單的計算。
例如：
n × n 矩陣乘法並傳回一個數字（mod 1 000 000 007）
JS 可以完美地處理這類數學運算，而且通常比 WASM 「更快」。
為什麼會出現？
因為我們還要考慮到跨越 JS ↔ WASM 邊界的開銷。
JS 和 WASM 之間的邊界代價很高——你越頻繁地跨越它，複製的資料越多，所有效能提升就越快消失。
JS開始走下坡的地方💥
當涉及到非常繁重的計算時，情況就不同了。
拿：
n！反對 1 000 000 007
這裡 JavaScript 的速度比 WASM 慢很多。
在這個小例子中，絕對時間仍然很短——但想像這樣的情況：
-
物理模擬
-
數值求解器
-
大型統計模型
核心問題在於數字。
JavaScript 使用IEEE-754 雙精度數，對於非常大的值，它必須切換到BigInt ，這很慢。
另一方面，Rust 可以在u64上正常運作。
單單這一點就會造成巨大的效能差距。
有趣的是，結果會因以下因素而異：
-
瀏覽器
-
JS引擎
-
硬體
例如，在我的電腦上，Firefox 中的差距比 Chrome 中的差距小得多。
影像處理方面呢？ 🖼️
WASM 常被提及在以下脈絡中：
-
影像處理
-
影片
-
聲音的
是的——它在這方面確實非常出色。
不過，這裡有個驚喜哦😄
當我嘗試一個非常簡單的基準測試——只是對圖像應用高斯模糊——JS完全碾壓了 WASM 。
為什麼？
因為我必須將整個Uint8Array複製到 WASM 記憶體中。
WASM 直到我：才開始贏得比賽
-
建構了完整的影像處理流程。
-
連續應用多個篩選條件
-
在 WASM內部盡可能地完成了工作
吸取教訓👇
「WASM 非常適合處理影像」這句話沒錯——但前提是操作夠繁重。 （當然，一些優化（例如共享記憶體）可以降低這種開銷，但代價是增加了複雜性。）
即使是處理數百萬像素的高斯模糊，JS 也能出人意料地處理得很好。
額外提示：WASM 並非唯一工具🧰
同樣值得注意的是：
-
Web Workers
-
螢幕外畫布
-
GPU解決方案（WebGPU）
……有時也可能是完全可行的替代方案。
並非所有繁重的任務都需要 WASM——有時JS + worker就已經「夠好了」。
所以…JavaScript 要消亡了嗎？ ☠️
不😄
如你看到的：
-
JavaScript 仍然非常活躍。
-
現代框架足以滿足日常前端工作的需求。
但當需要進行大量計算時：
-
不要害怕WASM
-
它實際上是面向普通開發者的工具，而不僅僅是面向資深系統程式設計師的工具。
WASM 不是 JavaScript 的替代品，而是一個強大的補充，尤其是在運算引擎方面。
輪到你了！ 👋
基準測試結果如何？
歡迎在留言區分享你的想法——我真的很好奇😊
原文出處：https://dev.to/sylwia-lask/will-webassembly-kill-javascript-lets-find-out-live-demo-43ln
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
