I waited 10 billion ticks and only got to the loading screen
Modern equipment is incredibly fast. The M1 Max I'm writing this article on runs at 3.2GHz. That is 3.2 BILLION ticks per second. However, Microsoft Teams takes 3 seconds to open a link, and I refuse to believe that it takes 9.6 BILLION ticks to open a link. Obviously, I'm simplifying, but the point remains the same: how is it that hardware gets faster, but applications only get slower?
“Because we do a lot more tasks.” He thinks so lover 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 ray-traced physics and lighting, while playing in real time with friends from other states and even countries; a fairly affordable consumer-grade computer produces 124 million pixels per second1.
[1. 1080p при 60 FPS = 1920 × 1080 × 60 = 124416000]
You can also look in the opposite direction: people succeed run DOOM on almost any device with a processor: on calculators, iPods, cameras. Incredibly low-power, often disposable devices have enough computing power to run a state-of-the-art game in 1993. This is not particularly surprising, since three decades have passed, but it shows how far we have come.
“Web is bad”
The web is cool. In fact, the web is so cool that it is in a class of its own in backwards compatibility, cross-platform, and accessibility. In addition, the web has an event-based model that makes writing UI much easier. Of course, this convenience also comes at a price: speed. Making a language as flexible as JS is a challenge in itself, and it's probably the first thing you'll blame when comparing a fast native app to a sluggish web version. Of course, a dynamically typed interpreted language inevitably requires more memory and is slower.
In some cases, JS deserves criticism. For example, webpack has to parse thousands of files, create ASTs and do completely complex things that I don't understand that require a lot of CPU resources, so it's logical that esbuild (Go) And swc (Rust) handle this much faster than webpack.
However, this is not the case for general purpose web applications; the web is not the reason your awesome IRC chat app runs at 5 FPS. A couple of weeks ago at Twitter remembered McMaster-Carr website catalog. Thanks to aggressive preloading and server-side rendering, the website and its navigation are incredibly fast, despite using technologies that are decades old (ASP.NET, jQuery). Lovers of everything new are put to shame.
If you hate React, this may seem like a great argument against React and other “modern” JS frameworks, but it's completely2 wrong conclusion. Check it out NextFaster (repository) is an equally fast copy of the McMaster catalog, or even faster, written in Next.js and hosted on Vercel.
[2. Да, существует аргумент о «башне сложности» и бесконечные абстракции, которые мы создаём, чтобы просто выводить поля на экран, но этот аргумент не относится к производительности. Можно писать быстрые приложения практически на чём угодно.]
Probably the epitome of web technology was Figma. If you think about it, a full-featured design tool running at 60 FPS with real-time “multiplayer” is just crazy. Although to be fair it's not entirely JS, most of the application runs on WebAssembly and WebGL. Could they squeeze even more performance out of a native app? Maybe. But to do this, you would have to give up the convenience of the website, which you only need to visit to work with. Instead, the developers made every effort to optimize 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 made it possible to write web applications and convert them into desktop applications. This is certainly an attractive opportunity. Now you can hire developers with one skill set, write one application once, and create “desktop” applications for every architecture and operating system (yes, even Linux).
What did you have to pay for this? The only reliable way to run web applications is through a web browser, so Electron just… has a web browser. What could go wrong? ¯\_(ツ)_/¯
It turns out that there is a lot. Over the past ten years, it has become socially acceptable for applications to be downloaded in size in excess of 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 suck, they are not that convenient to use. The non-native nature of many applications “leaks through” the strange behavior of scrolling and highlighting, appearance and navigation controls, not to mention the terrible lag when changing screens. Discord and Teams are great examples of this Electron-ification. They both have great mobile apps, but the desktop apps are just a repackaged website. For what?
But blaming Electron for this would not be entirely fair. Electron simply said: “There is a way to put your web application in a window.”
The real culprits are the companies that create these apps. It is definitely possible to create good Electron applications, the best examples are Slack, Obsidian and Notion. It's enough just to be responsible.
A section dedicated to Electron would not be complete without mentioning Brackets, Atom and, most importantly, VS Code. Honestly, I'm impressed by how well VS Code works, considering that editing large JS files is like shooting yourself in the foot and then running a marathon: you'll prove something, but you're not entirely sure what.
A large part of VS Code's success is certainly due to its ecosystem of plugins, and this is in no small part due to the accessibility of the web stack. I recently wrote plugin for SWCand I can confidently say that the developer experience (DX) of native plugins is nowhere near the ultra-fast iteration cycles of the web.
“Nativity is bad”
My disparaging comments about web technologies may give the impression that I love native applications. Most native apps are great to use (Postico, Zed), and I try to use them whenever possible.
Having switched a couple of months ago to ZedI won't be going back to VS Code. Everything (really everything) happens in it instantly. You may think that VS Code is already “fast enough,” but that’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 achieve this? The developers wrote own GPU framework from scratch and created an editor entirely in Rust. When you use modern equipment wisely, it for real fast. Who would have thought?
I'd like to explore deeper React Native for desktops. RN's DOM-like rendering model appeals to me as a web developer; Plus I think it strikes the right balance between great DX and performance, especially with New Architecture. It’s still not clear to me why RN for desktop is not very popular, because theoretically it seems like a perfect balance (although the reason may be insufficient support from the RN developers).
Unfortunately, not everything is good in the world of nativeness either. Adobe products are notorious for their frequent crashes. The search menu in Windows 11 is laughably bad. Activity Monitor on macOS takes 5 seconds to list running programs.
So are we doomed?
Obviously, these problems are not specific to a specific programming language, operating system, or industry. The reason is the broader trend of “faster and worse” releases. Release speed is more important than quality.
Tragedy of the Commons
The situation has gotten especially worse in recent years because modern computers have become much faster than the average person needs. If you start scrolling YouTube Shorts in a desktop browser, RAM leaks will begin (more than 2 GB!) and finally everything will come down to resource limitations. This would have been unthinkable in the old days, when computers only had 2GB of RAM. The seemingly unlimited computing resources of modern machines become an excuse for creating inferior software.
The “acceptability” trick
As you noticed, it is very important to me that programs are easy to use, but after talking with different people, I realized that this approach is not so popular. Most people are happy with having to wait 500ms for the context menu to appear after right-clicking, and they don't notice any lag when resizing the window. This is either a habit from the days when you had to wait 15 seconds to load an image, or learned helplessness in the face of bad user experience. But we can improve the quality, we have technology.
Ship It Culture
You can create projects, and create them quickly. With this article, I don't want to blame anyone for quickly iterating with new ideas, but there is a huge difference between treating productivity degradation as technical debt and ignoring productivity completely. It seems that many of the programs we use every day didn't think about performance even after they were released; It looks like developers are just waiting for hardware capacity 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’m unlikely to agree with you.
Productive Performance
From reading this article, you can come to the conclusion that I recommend optimizing everything down to individual CPU commands. While this in itself would be an impressive result, it is completely unfeasible for most software (unless you're Chris Sawyer of RollerCoaster Tycoon). This article is not about productivity for productivity's sake. I just realized that the developers of large-scale modern software seem to care little about usability, because you're going to use it anyway. This is not the future I strive for.
If you are a software developer, I encourage you to build with precision and quality in mind. Pay attention to milliseconds. Appreciate what you enjoy using. Maintain your craft and be proud of it.
Stop spending more on less opportunities.
