前端未來的可能性 #

前言 #

之前看稀土开发者大会 2023·前端未来的演講，舉辦在在 2023 年 7 月，其中有一段下午場，是小米的工程師彭耀宗講的，主題是：快應用框架在 IOT 場景中的落地。

影片在這邊，下午場，大概 46:30 的時間點。

讓我驚豔的是，在硬體資源的吃緊的 IOT 環境，他們如何一步一步的去達到，不放棄前端豐富的生態還有開發效率，並達到超過golang的效能

傳統 IOT 的局限性 #

主要有三點：

• 缺乏安全性跟隔離性，只有內核態，一個 process，應用 crash，系統就直接 crash
• 缺乏模塊化機制
• C 開發需要針對不同的芯片，配置不同的編譯器、開發環境等等，開發難度高

IOT 引進前端生態 #

優點 #

• 提供應用容器
  • 應用 crash 不會擊穿，影響到內核
  • wasm 已經是 w3c 的標準
• 豐富的生態
  • npm package 是現在最豐富的，遠超其他套件系統，前端工程師也多
• 高效開發
  • 用前端框架去開發，降維打擊
  • 但是必須解決穩定性跟性能問題

缺點 #

• 應用卡頓
  • 相較於 C，JS 效能差了不只一個量級
• 內存佔用高
  • IOT 硬體沒什麼資源
• 內存泄露嚴重

IOT 引進 wasm #

優點 #

• sandbox
  • 處理安全性跟隔離性
• 高性能
  • 有近低階語言的效能
  • 優化空間更大
• 多語言
  • wasm 支持多種語言

缺點 #

• 目前只支持靜態語言，對動態語言的支持力不足

  • gc proposal 還在 phase 3，基本穩定，但是尚未被廣泛使用(V8 已經支援)

• 缺少模塊機制

  • 意味著只能作為 JS 生態的補充，沒有辦法做自己的獨立生態
  • 因為一次性的把所有模塊都加載進內存是很糟糕的事情

• 缺少通用的異常處理機制

  • 沒有 try catch
  • 只能 runtime 自己去實現 try catch

• 開發工具不完善

  • 沒有內存分析工具
  • 沒有性能分析工具

wasm 在前端的現況 #

wasm 技術棧缺少一個高效的前端開發語言，這極大的限制他在前端領域的應用

• C/C++/Rust - 高性能，開發效率低，很難融入前端現有生態（npm package）
• javascript/golang - 需要套娃，嵌入整個 runtime，效能降低

ts 引入 wasm 生態 #

使用其他語言寫 wasm，都不是真正意義上的前端，都有種割裂感

將 ts 引入 wasm 生態，把前端技術帶回前端

使用 ts 的優點 #

• 對接前端現有生態
  • 可以使用龐大的npm package生態，而且前端工程師很多
• 直接編譯到 wasm
  • 將 ts 的靜態類型轉譯到 wasm，利用 wasm 的 AOT 提速
• 兼顧開發跟運行效率
  • 開發者喜歡動態語言，IOT 需要運行效率，TS 就是一個平衡

WAMR 跟 ts2wasm #

• WAMR
  • wasm-micro-runtime縮寫
  • intel 開源，用 c 寫的，給類IOT用的 wasm runtime
• ts2wasm
  • intel 發起，小米聯合開發，將 ts 編譯為 wasm 在 WAMR 上運行
  • 還沒 open source

ts2wasm 如何優化效能 #

JS 是動態語言，為了開發的靈活性，他犧牲掉了一些效能，底層會幫你做一些類型判斷跟類型轉換，有個術語叫Coercion，在 ECMAScript 規格書上都會有轉換的規則。

現有前端生態的 ts 只做類型檢查，底層還是用 JS 的 runtime，並沒有辦法把靜態類型，帶到runtime，去做更多的JIT、AOT的優化。

ts2wasm就是另外一個編譯 ts 的runtime，像其他強型別語言一樣，有類型資訊做系統優化，編譯後的 code 直接是 wasm(bytecode)，性能非常好。

因為場景的需求跟性能要求，ts2wasm 也屏棄掉 JS 某些功能。

小結 #

前端其實很依賴平台，所有的能力都是平台賦予的。

在瀏覽器，就被瀏覽器的 JS runtime 限制住，這有好有壞。

而 ts2wasm 幫 javascript 開了一個想像力很大的門。

讓我想到 stack overflow 的 creator 講的 Atwood's law：

Any application that can be written in JavaScript, will eventually be written in JavaScript