I waited 10 billion cycles and only got a loading screen

“Because we are doing a lot more tasks.” So says a fan of late capitalism. Let me explain.

An excellent example of the power of modern "hardware" is video games. I can simulate huge 3D environments with physics and ray-traced lighting, while playing in real-time with friends from other states and even countries; a fairly affordable consumer-level computer outputs 124 million pixels per second¹.

^{[1. 1080p at 60 FPS = 1920 × 1080 × 60 = 124416000]}

You can look the other way: people manage to run DOOM on almost any device with a processor: calculators, iPods, cameras. Incredibly low-powered, often disposable devices have enough computing resources to run a state-of-the-art game from 1993. This is not particularly surprising, as three decades have passed, but it shows how far we have come.

“The web is bad”

The web is cool. In fact, the web is so cool that it is in its own class of backward compatibility, cross-platform, and accessibility. Moreover, the web has an event-based model that greatly simplifies writing UI. Of course, this convenience also comes at a cost: speed. Running such a flexible language as JS is a complex task in itself, and it is probably the first thing you will blame when comparing a fast native application to a slow web version. Of course, an interpreted language with dynamic typing inevitably requires more memory and runs slower.

In some cases, JS deserves criticism. For example, webpack has to parse thousands of files, create AST, and perform completely complex things that I don't fully understand, requiring large CPU resources, so it's logical that esbuild (Go) and swc (Rust) handle this much faster than webpack.

However, in the case of general-purpose web applications, this is not the case; the web is not the reason why your great IRC chat application runs at 5 FPS. A couple of weeks ago on Twitter, they recalled the McMaster-Carr website catalog. Thanks to aggressive preloading and server-side rendering, the website and navigation work incredibly fast, despite using technologies that are already decades old (ASP.NET, jQuery). Lovers of everything new are disgraced.

If you hate React, this might seem like a great argument against React and other "modern" JS frameworks, but this is completely² the wrong conclusion. Check out NextFaster (repository) — an equally fast copy of the McMaster catalog, if not surpassing it in speed, written in Next.js with hosting on Vercel.

^{[2. Yes, there is an argument about the "tower of complexity" and the endless abstractions we create just to display fields on the screen, but this argument does not apply to performance. You can write fast applications in almost anything.]}

Probably, the embodiment of web technologies is Figma. If you think about it, a full-featured design tool running at 60 FPS with real-time "multiplayer" is just madness. Although, to be honest, it's not entirely JS, most of the application runs on WebAssembly and WebGL. Could they squeeze even more performance out of a native application? Possibly. But for this, they would have to give up the convenience of a website, which is enough to just visit to work with. Instead, the developers put all their efforts into optimization and proved that the browser can demonstrate real power.

Note: huge thanks to the developers of V8, SpiderMonkey, and JavaScriptCore for making all this possible. It is thanks to your painstaking work that we can create anything at all.

"Electron is bad"

Note: here I mean Electron itself, CEF, WKWebView, Edge WebView2, and all other wrappers for turning web applications into native ones.

Electron allowed writing web applications and converting them into desktop applications. This is undoubtedly an attractive opportunity. Now you can hire developers with one skill set, write one application once, and create "desktop" applications for each architecture and operating system (yes, even for Linux).

What did they have to pay for this? The only reliable way to run web applications is through a web browser, so in Electron, there is simply... a web browser. What could go wrong? ¯\_(ツ)_/¯

It turns out, a lot. Over the past decade, it has become socially acceptable for the size of downloaded applications to exceed 500 MB, and they themselves require a huge amount of RAM and CPU resources, while quickly draining device batteries. But even despite the resources they consume, they are not very convenient to use. The non-nativeness of many applications "leaks" through strange scrolling and selection behavior, appearance, and navigation control, not to mention the terrible sluggishness when switching screens. Discord and Teams are excellent examples of such Electron-ification. They both have great mobile apps, but the desktop ones are just repackaged websites. Why?

But blaming Electron for this would not be entirely fair. Electron just said, "There is a way to put your web application in a window."

The real culprits are the companies that create these applications. Good Electron applications can definitely be created, the best examples are Slack, Obsidian, and Notion. It's just a matter of being responsible.

A section dedicated to Electron would not be complete without mentioning Brackets, Atom, and most importantly, VS Code. Honestly, I am impressed with how well VS Code works, considering that editing large files in JS is like shooting yourself in the foot and then participating in a marathon: you will prove something, but it's not entirely clear what.

A large part of VS Code's success is undoubtedly due to its plugin ecosystem, and this is largely due to the availability of the web stack. Recently, I wrote a plugin for SWC, and I can confidently say that the degree of developer experience (DX) of native plugins is nowhere near the super-fast iteration cycles of the web.

"Nativeness is bad"

My dismissive reviews of web technologies might give the impression that I love native applications. Most native applications are wonderful to use (Postico, Zed), and I try to use them whenever possible.

Having switched to Zed a couple of months ago, I will never go back to VS Code. Everything in it (really everything) happens instantly. You might think that VS Code is "fast enough", but it's like comparing the speed of sound to the speed of light. The difference is barely noticeable, but that's the whole point. How did Zed manage to achieve this? The developers wrote their own GPU framework from scratch and created the editor entirely in Rust. When you use modern hardware wisely, it is truly fast. Who would have thought?

I would like to delve deeper into React Native for desktops. The DOM-like rendering model of RN appeals to me as a web developer; moreover, I think it provides the right balance between excellent DX and performance, especially with the New Architecture. I still don't quite understand why RN for desktops is not very popular, as theoretically it looks like the perfect balance (although the reason may be insufficient quality support from RN developers).

Unfortunately, not everything is good in the world of nativity either. Adobe products are notorious for their frequent crashes. The search menu in Windows 11 is laughably bad. Activity Monitor in macOS takes 5 seconds to compile a list of running programs.

So, are we doomed?

Obviously, these problems are not related to a specific programming language, operating system, or industry. The reason is a broader trend of releasing "faster and worse". Release speed is more important than quality.

The Tragedy of the Commons

The situation has worsened especially in recent years because modern computers have become much faster than the average person needs. If you start scrolling through YouTube Shorts in a desktop browser, memory leaks (more than 2 GB!) will begin, and finally, everything will hit the resource limit. This would have been unthinkable in the old days when computers had only 2 GB of RAM. The seemingly unlimited computing resources of modern machines become an excuse for creating lower quality software.

The "Acceptability" Trick

As you have noticed, it is very important to me that programs are easy to use, but after talking to different people, I realized that this approach is not so popular. Most people are fine with waiting 500 ms for the context menu to appear after right-clicking, and they don't notice the lag when resizing the window. This is either a habit from the times when it took 15 seconds to load an image, or learned helplessness in the face of poor user experience. But we can improve quality, we have the technology.

“Ship It” Culture

You can create projects, and create them quickly. With this article, I don't want to blame anyone for quick iterations with new ideas, but there is a huge difference between considering performance degradation as technical debt and completely ignoring performance. It seems that in many programs we use every day, performance was not considered even after their release; it looks like developers are just waiting for hardware capabilities to catch up with their needs. This approach is acceptable if you are creating something super-progressive, but if your task is to display text on the screen, then I am unlikely to agree with you.

Productive Performance

From reading this article, one might conclude that I recommend optimizing everything down to individual CPU commands. While this in itself would be an impressive result, for most software this is completely unrealistic (unless you are Chris Sawyer developing RollerCoaster Tycoon). This article is not about performance for the sake of performance. I just realized that developers of large-scale modern software seem to care little about its usability because you will use it anyway. This is not the future I strive for.

If you are a software developer, then I urge you to create it with precision and quality in mind. Pay attention to milliseconds. Appreciate what you enjoy using. Keep the bar of your craft and be proud of it.

Stop spending more on fewer features.