What exactly is a "high-performance web app" or "frontend"?
Since the decline of the Internet Explorer era, the JavaScript ecosystem has grown increasingly powerful, and the term "frontend" has become synonymous with high-performance, modern web clients. At the core of this "frontend" world lies React. In fact, not using React in frontend development often makes one seem like an outlier.
But just as not every game is AAA, we must carefully consider what we mean by "high-performance" when discussing web apps. This distinction is crucial to the topic at hand today.
1. The Scope of High-Performance Web Apps
In most cases, the term "high-performance web app" refers to an interactive, dynamic web client built using JavaScript-based frameworks like React, Vue, or Svelte. These apps typically boast fast load times and client-side routing, and React’s virtual DOM plays a major role in enhancing rendering speed.
However, there are web apps that utilize all 4GB of the WASM module’s memory limit, are built with systematic memory management in mind, and aim for performance on par with native programs like Blender or 3Ds Max. These apps align more with the concept of "programs" that harness every resource of a browser tab, rather than traditional "web pages" optimized for SEO.
Though current browser environments might still struggle to deliver native-like performance due to memory limits and overhead, the goals of such apps are fundamentally different. They handle large datasets and aim to use the full 2-4GB of memory, all while pursuing the highest rendering speeds.
Given that the issues faced by these types of web apps differ from those faced by typical "high-performance" apps, the directions they pursue also diverge.
The "high-performance web app" mentioned at the beginning and the one I describe here are fundamentally different in their paths. To lump them together under a single term would be problematic. We need different terminology to reflect these differences.
That’s why I propose we stop referring to the latter as a "high-performance web app" or "frontend" and instead use the following terms:
- Browser-Based High-Performance Framework Engineering (BBHPFE)
- (Browser-Based) High-Performance System Engineering (HPSE)
I believe these terms clearly define the difference in requirements between frontend and HPSE. Not every browser-based client is a frontend; some are HPSEs. Consider the following example to understand why this distinction matters:
[Conversation 1]
A: "I’m developing a frontend app but not using React."
B: "A frontend app without React? React has over 60% market share in frontend! Why wouldn’t you use it?"
[Conversation 2]
A: "I’m developing an HPSE app but not using React."
B: "That makes sense for HPSE. Game companies often customize their engines extensively, but React's internal functions and rendering pipeline can’t be modified. It was never designed for that purpose."
Now, let’s discuss the essential components that an HPSE must have.
2-1. Memory Management
You can't talk about high-performance programs without addressing memory. Whether using a garbage collector or manually freeing dynamically allocated memory, unused memory must always be freed.
Consider a browser-based game where the player moves to a new map. The game will need to fetch new map data from the server asynchronously, create new meshes, and remove old ones. The data used to generate the old mesh must also be freed.
If the references to the old data aren’t properly released, the memory usage will keep growing with each map transition. Once it reaches around 2GB, you may encounter an "Out of Memory" error, and the browser will crash.
It’s true that JavaScript wasn’t designed for low-level memory control—neither the language nor the philosophy of its developers prioritize it. I’m not saying memory management is always crucial, but as they say, "there’s no such thing as a free lunch." If memory management is necessary, it must be done.
2-2. Flexibility in Meeting Requirements
I once heard someone say, "By the time you move from being a junior developer to an intermediate, you should be able to build anything requested of you."
JavaScript is already an impressive language with few inherent limitations (aside from memory limits). If you want to build something, it can likely be done.
The real question is whether your current project can truly accommodate a wide variety of requirements.
Just as machines in a factory break down after continuous operation, pursuing high-performance, customized features inevitably leads to encountering unexpected challenges. When this happens, flexibility and the ability to meet unique requirements are essential.
For example, have you ever heard that Lost Ark was built on Unreal Engine 3? Unreal Engine 5 is out now, yet they still use Unreal Engine 3, which was created in 2004. To sustain the project until now, they must have made extensive modifications to the engine—practically a complete overhaul. Due to the game's characteristics, they had to constantly customize the rendering pipeline and loop with techniques like deferred rendering, instancing, culling, and screen-space reflection to meet performance and aesthetic requirements.
The ability to modify the engine's source code was critical. If the engine had been closed off or too tightly coupled to allow for modifications, Lost Ark may never have been developed.
HPSE is the same. While the environment has changed to a browser-based one, the need for custom functions and flexible modifications remains the same. Therefore, libraries and external modules used in HPSE must be modifiable, and if the browser’s rendering pipeline or internal module coupling is too rigid to allow for these changes, it becomes a significant problem.
2-3. The Inevitable Object-Oriented Approach
When dealing with large-scale programs, one thing becomes inevitable: object-oriented programming (OOP).
JavaScript is a multi-paradigm language, and functional programming (FP) is widely used. However, FP, while suitable for web clients, is rarely used in large-scale programs where multiple objects interact in complex ways because instances in FP lack internal states.
React compensates for this with global state management and useEffect, but it’s not as intuitive as having each instance maintain its own state and controlling method calls through public methods.
While OOP isn’t always the best choice, it’s hard to think of a better alternative when considering the highly customized development needs of HPSE. Many large-scale programs, including operating systems and games, are built using OOP principles. Even the most popular engine sources are object-oriented, with minor variations in methodology.
Developers who have participated in large-scale projects are likely familiar with OOP. This makes OOP-based development conducive to collaboration.
That said, there's no need to discard JavaScript’s strengths. Since JavaScript supports functions and const declarations, simple module functions that don’t require instances can be defined as object literals using const or functions. This can enhance productivity and take advantage of JavaScript’s versatility.
In conclusion, I believe that a multi-paradigm approach, incorporating object-oriented principles, would be ideal for HPSE.
Top comments (0)