我曾看過長期使用 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 用戶端開發的範圍。

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