（目前唯一的替代方案：Vanilla JavaScript

我見過長期使用 C 語言的開發人員，仍然使用 MFC（微軟基礎類別）進行開發。原因很簡單：沒有真正的替代方案可以用 C 建立 UI。雖然 Qt 存在，但它需要商業許可證才能用於專業用途，這使得 MFC 成為唯一的選擇。

MFC 提供了基本的 UI 元件，但它仍然能夠創建生產級程序，例如 CAD 軟體或醫院應用程式。

JavaScript 生態系的目前狀態非常相似。

沒有專門為實現 HPSE 目標而建造的框架。雖然有像 Babylon.js 這樣的遊戲引擎，但它們只提供 3D 圖形功能，並沒有像 React 那樣提供整體結構。

所以，最終，一切都回到了 Vanilla JavaScript 和 TypeScript。開發人員使用 Vanilla JavaScript 並不是因為他們喜歡它；而是因為他們喜歡它。他們使用它是因為沒有其他選擇。就像早期由於缺乏商業框架，開發人員必須用 C 從頭開始建立一切一樣，現在我們在 JavaScript 中也面臨著同樣的情況。目前還沒有完全滿足 HPSE 需求的框架，因此我們只能使用 Vanilla JavaScript 進行手動開發。

坦白說，這並不是 JavaScript 獨有的。對於大多數其他語言也是如此。

俗話說「天下沒有白吃的午餐。」

許多最初雄心勃勃地想要突破新界限的程式最終都嚴重依賴直接在程式語言中建立的自訂功能。 HPSE 也是從有一天在瀏覽器中執行本機程式的願景開始的，而現在，它必須用 Vanilla JavaScript 一點一點地編寫。

有些人可能會爭論，「為什麼不放棄 JavaScript 並使用 C 或 Rust 來創建 WebAssembly (WASM) 模組並在瀏覽器中運行它？」

有一個很好的故事可以回答這個問題。

Babylon.js 和 Three.js 的領導者曾在評論中被問到 WASM 技術是否會成為他們引擎的未來。他們的回答是「否。」

原因很簡單：C/Rust 程式碼不能直接在 Web 環境中執行，這使得偵錯變得更加困難。並且由於 V8 引擎的進步，JavaScript 現在可以實現高效能。 JavaScript 是一種直接在瀏覽器中運行的腳本語言，具有很高的生產力——沒有必要放棄這些優點。

過去，程式設計師透過開發自己的作業系統來競爭。但在 Windows、Mac 和 Linux 成為標準之後，焦點轉移到如何建置在這些系統上運行的程式。同樣，今天的瀏覽器已經發展到可以合理考慮如何建立在其中運行的程式的程度。

如果有明確的界限說明 JavaScript 應該做什麼、不應該做什麼，並且如果高端任務確實不適合 JavaScript，那麼 Microsoft 永遠不會啟動 Babylon.js 項目，Three.js 也永遠不會已被創建。 WebGPU 也是如此，它正在建立為新的 Web 標準。

最近，我一直在反思自己作為一名開發者的身份，質疑「前端」到底意味著什麼，以及這個術語是否能夠真正涵蓋 Web 用戶端開發的範圍。

我確信我的想法中有很多錯誤訊息，但我會將其作為我的第一篇部落格文章發布，以鞏固我一直在思考的內容。

以上是（目前唯一的替代方案：Vanilla JavaScript的詳細內容。更多資訊請關注PHP中文網其他相關文章！