“高性能网络应用程序”或“前端”到底是什么？

自从 Internet Explorer 时代衰落以来，JavaScript 生态系统变得越来越强大，“前端”一词已成为高性能、现代 Web 客户端的代名词。这个“前端”世界的核心是 React。事实上，在前端开发中不使用 React 常常会让一个人看起来像个异类。

但正如并非所有游戏都是 AAA 级游戏一样，我们在讨论 Web 应用程序时也必须仔细考虑“高性能”的含义。这种区别对于今天的主题至关重要。

1。高性能 Web 应用程序的范围

在大多数情况下，术语“高性能 Web 应用程序”是指使用基于 JavaScript 的框架（如 React、Vue 或 Angular）构建的交互式动态 Web 客户端。这些应用程序通常拥有快速加载时间和客户端路由，而 React 的虚拟 DOM 在提高渲染速度方面发挥着重要作用。

但是，有些 Web 应用程序利用了 WASM 模块的全部 4GB 内存限制，在构建时考虑了系统内存管理，并且旨在实现与 Blender 或 3Ds Max 等本机程序相当的性能。这些应用程序更符合“程序”的概念，利用浏览器选项卡的所有资源，而不是针对 SEO 优化的传统“网页”。

尽管由于内存限制和开销，当前的浏览器环境可能仍难以提供类似本机的性能，但此类应用程序的目标根本不同。他们处理大型数据集，目标是使用完整的 2-4GB 内存，同时追求最高的渲染速度。

鉴于这些类型的网络应用程序面临的问题与典型的“高性能”应用程序面临的问题不同，它们追求的方向也有所不同。

一开始提到的“高性能网络应用程序”和我在这里描述的“高性能网络应用程序”在路径上有根本的不同。将它们归为一个术语是有问题的。我们需要不同的术语来反映这些差异。

这就是为什么我建议我们停止将后者称为“高性能网络应用程序”或“前端”，而是使用以下术语：

• 基于浏览器的高性能框架工程（BBHPFE）
• （基于浏览器）高性能系统工程 (HPSE)

我相信这些术语清楚地定义了前端和 HPSE 之间的要求差异。并非所有基于浏览器的客户端都是前端；有些是 HPSE。考虑以下示例以了解为什么这种区别很重要：

[对话 1]

A：“我正在开发一个前端应用程序，但没有使用 React。”
B：“没有 React 的前端应用？React 在前端市场占有率超过 60%！你为什么不使用它？”

[对话2]

A：“我正在开发 HPSE 应用程序，但不使用 React。”
B：“这对 HPSE 来说是有道理的。游戏公司经常广泛定制他们的引擎，但 React 的内部功能和渲染管道无法修改。它从来不是为此目的而设计的。”

现在，让我们讨论 HPSE 必须具备的基本组件。

2-1。内存管理
不谈内存就谈不上高性能程序。无论是使用垃圾收集器还是手动释放动态分配的内存，都必须始终释放未使用的内存。

考虑一个基于浏览器的游戏，玩家移动到新地图。游戏需要从服务器异步获取新的地图数据，创建新的网格物体，并删除旧的网格物体。用于生成旧网格的数据也必须被释放。

如果对旧数据的引用没有正确释放，内存使用量将随着每次映射转换而不断增长。一旦达到2GB左右，您可能会遇到“内存不足”错误，浏览器将崩溃。

确实，JavaScript 并不是为低级内存控制而设计的——无论是语言还是其开发人员的理念都没有优先考虑它。我并不是说内存管理始终至关重要，但正如他们所说，“天下没有免费的午餐”。如果需要内存管理，就必须要做

2-2。满足要求的灵活性
我曾经听到有人说，“当你从初级开发人员转变为中级开发人员时，你应该能够构建任何需要你的东西。”

JavaScript 已经是一种令人印象深刻的语言，几乎没有固有的限制（除了内存限制）。如果你想构建一些东西，它很可能可以完成。

真正的问题是您当前的项目是否能够真正满足各种各样的需求。

就像工厂里的机器在连续运转后就会出现故障一样，追求高性能、定制化功能必然会遇到意想不到的挑战。当这种情况发生时，灵活性和满足独特要求的能力至关重要。

例如，您听说过《失落的方舟》是基于虚幻引擎 3 构建的吗？虚幻引擎 5 现已发布，但他们仍然使用 2004 年创建的虚幻引擎 3。为了使该项目维持到现在，他们必须对引擎进行大量修改——实际上是彻底检修。由于游戏的特点，他们必须不断地通过延迟渲染、实例化、剔除、屏幕空间反射等技术来定制渲染管线和循环，以满足性能和美观的要求。

修改引擎源代码的能力至关重要。如果引擎被关闭或耦合得太紧而无法进行修改，失落的方舟可能永远不会被开发出来。

HPSE 是一样的。虽然环境已经变成了基于浏览器的环境，但对自定义功能和灵活修改的需求仍然没有改变。因此，HPSE中使用的库和外部模块必须是可修改的，如果浏览器的渲染管道或内部模块耦合过于严格而不允许这些更改，那就成为一个重大问题。

2-3。不可避免的面向对象方法
在处理大型程序时，有一件事是不可避免的：面向对象编程（OOP）。

JavaScript是一种多范式语言，函数式编程（FP）被广泛使用。然而，FP 虽然适合 Web 客户端，但很少用于多个对象以复杂方式交互的大型程序，因为 FP 中的实例缺乏内部状态。

React 通过全局状态管理和 useEffect 来弥补这一点，但它不如让每个实例维护自己的状态并通过公共方法控制方法调用那么直观。

虽然 OOP 并不总是最佳选择，但在考虑 HPSE 的高度定制开发需求时，很难想到更好的选择。许多大型程序，包括操作系统和游戏，都是使用 OOP 原理构建的。即使是最流行的引擎源也是面向对象的，在方法上有微小的变化。

参与过大型项目的开发人员可能熟悉 OOP。这使得基于 OOP 的开发有利于协作。

也就是说，没有必要放弃 JavaScript 的优势。由于 JavaScript 支持函数和 const 声明，因此不需要实例的简单模块函数可以使用 const 或函数定义为对象文字。这可以提高生产力并利用 JavaScript 的多功能性。

总之，我相信结合面向对象原则的多范式方法对于 HPSE 来说是理想的选择。