我见过长期使用 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中文网其他相关文章！
