### English Translation:
---
English Original: Are mobile web apps slow?
Drew Crawford's article *"Web Apps Are Slow"* sparked heated discussions upon its release, with countless comments and tweets debating the performance of web apps versus native apps. According to Drew's argument—web apps are built using JavaScript, but JavaScript is inherently problematic for web apps because it is too slow and negatively impacts user experience. He further claims that this situation will not significantly improve in the medium term (5-10 years).
Does this mean developers should abandon web apps and return to the native app camp as the better choice?
No.
Drew argues that when garbage collection is required, JavaScript offers very few alternatives, forcing developers to manage memory carefully. He suggests that apps prone to instantaneous interruptions caused by garbage collection should consider the advantages of native apps, which can handle memory management more effectively.
However, Drew overlooks an important fact: JavaScript is just one sub-factor affecting the performance of web apps. Besides JavaScript, HTML, CSS, and SVG also consume CPU/GPU resources. In some cases, the layout and rendering of HTML/CSS/SVG in web apps account for the majority of CPU usage (it's even possible to create a game without writing any JavaScript). This indicates that garbage collection only occupies a small portion of the overall computation in web apps. In other words, JavaScript is merely part of the code in web apps, and its pros and cons only influence the computations it directly handles.
But some might ask: Why would we choose a language that runs slower than native? Isn't "faster is better" something everyone wants?
The answer to this question aligns with what Drew points out in his article: For developers, productivity is an essential metric. He uses hashmaps (a Map interface based on hash tables that provides optional mapping operations) as an example. Many managed languages come with built-in hashmaps, whereas in native apps, hashmaps are either too slow to update or developers prefer to write their own instead of using existing interfaces. This motivates many developers to use JavaScript because it is simple, dynamic, and supports cross-platform compatibility across various devices, unlike native code, which is specific to a single platform. Therefore, even though there may be some performance loss, the multi-platform support and broad audience reach still attract many developers to choose JavaScript.
Additionally, if JavaScript is used effectively, it can achieve results similar to native apps within browser engines. I have personally experimented with this—short JavaScript code can enable browser engines to perform tasks such as CSS layout, reshaping, and hardware-accelerated animations, all mimicking native functionality. In fact, even if we assume that native graphics libraries could provide graphical, animation, and layout capabilities comparable to browser engines, I don't believe native apps can match the flexibility and universal accessibility that the web platform brings to desktop applications.
Finally, web apps are not just about client-side code. At the core of the web concept, "distribution," "content," and "code" are equally important. Web apps can distribute their computational demands via the web itself. A great example is Lagoa, a 3D collaboration app. Lagoa offloads its computational needs to the cloud, achieving effects that native code alone cannot accomplish.
Therefore, speed is not the decisive factor for developers choosing between web apps and native apps. Jumping into native apps solely for performance reasons is an unwise argument. The ultimate decision depends on how developers weigh high productivity, wide accessibility, and runtime performance.
---