Software Disenchantment

Original article: Software disenchantment

I came across this article online, and I recommend that every software engineer give it a read. While some of the perspectives are a bit radical, I agree with it for the most part.

Why is software so “slow”?

At the beginning, the author points out that fields like automobiles, aviation, and architecture have reached a point where established paradigms exist—the wings, shape, and functions of airplanes are mostly standardized, and their proven success is clear to all.

Recently, I’ve also been wondering: why can these fields get it right, while in software development, things seem to just get worse? Every time I run npm install on a MacBook Pro or an iMac, the fans kick up to full blast. Web development feels like it’s built on a shaky tower of sand, with an overwhelming, endless number of frontend frameworks and state management tools available.

However, comparing software development to things like airplanes seems a bit unfair. Airplanes (passenger jets, for instance) are designed to transport passengers from point A to point B quickly and safely; houses are built to provide people with solid and durable shelters. Both serve clearly defined purposes that rarely shift over time.

What about software? Because of rapid iterations, it opens up far more possibilities. A webpage’s initial purpose might have simply been browsing information, but now it encompasses almost everything—watching videos, listening to music, posting updates, uploading images, and playing games. Thanks to hardware upgrades and technological advancements, we can accomplish all sorts of different tasks within a single browser.

Another factor is probably the original sin of JavaScript: a programming language created in a remarkably short period of time, which has now evolved into the most popular programming language in the world. Even its creator probably never saw that coming.

Using Java to ridicule JavaScript feels somewhat unfair to me. Java has its own VM, Runtime, JDK, and so on. In web development, we are at the mercy of a fragmented landscape of diverse browsers, which is precisely why tools like Babel and Webpack had to come into existence.

From this perspective, it seems too arbitrary to simply declare: “Hardware got faster, but software got slower.” Could a browser alone do this much 20 years ago? Did software 20 years ago have the same functionality and complexity as software today?

As computer users, perhaps what we still need is minimalist software—a streamlined browser (without history, file downloads, or devtools) that users can turn to whenever they want.

The author also complained about how ridiculously bloated modern web pages are—even Gmail can’t scroll smoothly, and the Slack app is an absolute resource hog. On this point, I’m also curious: why is the resource consumption so high? I know it’s built on Electron behind the scenes, but why does using Electron cause such immense resource consumption?

Personally, I maintain an optimistic attitude toward the possibilities Electron brings to GUIs. Although many people complain about how resource-heavy Electron is—which I agree is something that needs improvement in the future—look at Slack and VS Code; they are both remarkably successful examples built on Electron.

The author continued to complain, moving on to text editors. He mentioned that Emacs, developed 42 years ago, had lower input latency than modern text editors, and that 3D games can render millions of polygons within 16ms, so why can’t a simple text editor do the same?

While my current laptop is at least a MacBook Pro, there are definitely plenty of users on lower-end devices. We certainly shouldn’t optimistically assume that all users have great setups just because we do, nor should we blame users for having underpowered machines. There’s no doubt about that—seeing the resources consumed by Slack and VS Code shocked me as well.

Another issue the author mentioned is: We’re stuck with it. I agree wholeheartedly with this part. More and more engineers don’t really care about how everything is implemented under the hood. Is it slow? Doesn’t matter, as long as it meets business requirements. Don’t understand how it works? Doesn’t matter, just toss in another package. This “good enough” attitude is not how a professional engineer should approach their work. That’s not engineering; that’s laziness.

I’ve been feeling this more and more lately. While there are certainly enough tools today to help you build a decent product (or website) with only a superficial understanding, the attention to detail and appreciation of foundational principles are fading. To me, that’s not a healthy trend. That’s why I constantly remind myself to understand the underlying principles. Most of the time it’s not that hard (though operating systems are indeed tough QQ).

This year, I also plan to get back to the basics: the three great romances of computer science—“Operating Systems, Compilers, and Computer Graphics.” When I learned WebGL in 2017, computer graphics already battered me once. The remaining two—Operating Systems and Compilers—will probably be my biggest challenges for this year.