Why Are We Still Waiting for Our Computers?

Slack, with three teams configured, regularly takes over 30 seconds to load on my machine. When I made that claim recently, I was accused of hyperbole. A video I captured of the full launch process, spanning 45 seconds, made my point for me: this kind of delay is not an anomaly, it's the norm we've all quietly accepted.

It's a strange situation. We carry devices with more computing power than anyone could have imagined a few decades ago, yet we spend a significant portion of our day waiting for them. We've been conditioned to think that a 30-second app launch or a half-second animation interrupting our workflow thousands of times a day is acceptable behavior for software.

How the Web Took Over the Desktop

In the late 90s and early 00s, we collectively abandoned desktop development for the web. The reasons were practical: remote server communication became feasible, cross-platform UI frameworks were elusive or intimidating (Qt and similar SDKs never quite hit the mark for universal adoption), and web languages like Perl and PHP were more approachable.

There was also a cosmetic appeal. HTML and CSS gave developers total control over the look and feel of their applications, enabling pixel-perfect, branded experiences. This seemed like progress over the constraints of desktop toolkits, but it came at a cost. We traded the consistent, uniform interfaces of the past for a landscape where every application has a different shape, size, and set of conventions, eroding the common usability standards we once had.

Today, web technology is still seen as the future, with Electron-based apps championed as flexible and productive. But as these frameworks accumulate ever more complex retrofits, the gap between what they can deliver and what a well-written native app achieves is widening. Web software loads too slowly, relies too heavily on synchronous network calls, and often prioritizes visual flair over the responsiveness that allows expert users to work at full speed.

Even the Titans Know Native Wins

This isn't a new debate. After the iPhone's release in 2007, Steve Jobs told developers they could build apps for it immediately—in HTML5. He reversed course within a year, acknowledging how compromised the web experience was compared to native. Mark Zuckerberg echoed the sentiment in 2012, admitting that Facebook's biggest mobile mistake was betting on HTML5.

We all know that on a smartphone, we'd choose a native app over a browser-based one. Yet on the desktop, we tolerate Gmail, Reddit, Trello, and JIRA. The hardware and networks are fast enough to make these tools "good enough," but it's telling that we avoid them whenever better options exist—like our terminals and text editors.

The Real Problem Isn't Just Technology

The inefficiency isn't solely a technical issue. UX design has developed an addiction to catchy but unnecessary interface effects. Consider the animations the average user endures daily: switching spaces in macOS, the 1Password unlock sequence, waiting for the iOS SpringBoard after pressing the home button, entering full screen, or switching tabs in mobile Safari.

The first time you see these effects, they're impressive. The next five thousand times are less so. These flourishes look great in demos but don't help anyone be more productive; they actively work against it. Imagine if Apple decided to animate every Cmd+Tab task switch. Multiplying that animation's duration by the average number of daily task switches, across all users, would amount to millions of dollars in lost productivity each year.

Animations are the most egregious gimmick, but not the only one. Excessive whitespace that crams only a sliver of content on screen, oversized fonts, submenus where a simple row of links would work, unlabeled icons that force users to guess their function—the list of modern design anti-patterns is long.

What Terminals Get Right

Developers are a good case study in hypocrisy: we build web applications for others while avoiding them ourselves as much as possible. While users wade through sluggish pages, many of us work in terminal environments that are not only fast but offer enormous productivity gains to anyone willing to master them.

Terminals have several virtues worth noting:

  • Startup and loading times are effectively zero.
  • Transitioning between screens is instant, with no animations.
  • Interface elements are limited but uniform.
  • The steep learning curve is rewarding; they are optimized for the experienced user, which makes sense for software that someone might use for tens of thousands of hours over a lifetime.
  • Composability is a key feature; most terminal programs produce output that can be piped into another program. This is far more flexible than even copying text out of a modern web app, which can be a challenge if HTML elements aren't nested optimally.

Speed as a Design Principle

Ask a web designer about the principles of practical interface design, and you'll hear about text legibility, intuitiveness, and whitespace. But these priorities are misplaced. Pretty and friendly interfaces are nice, but the true measures of a good UI are speed and efficiency—the ability to make the user as productive as possible.

Consider the interface from Minority Report, which is remarkable for reasons beyond its futuristic gesture controls. We now have thinner screens and better touch technology than the film depicted, often displaying in full color unlike its monochrome aesthetic. What makes that interface truly amazing today is that it keeps up with its user. It doesn't pause for text completion, animate every app switch, or delay startup. It waits on the human, not the other way around. Except for terminals and a few other fringe technologies, our user interfaces fall far short of that ideal. A successful interface isn't one that looks great in a static screenshot—it's one that lets its user keep moving.

What the Future Needs to Borrow (From Both Sides)

Neither the terminal nor the current web app represents an ideal future, but the terminal is undeniably closer. This isn't to say terminals are great—they're often terrible. Consider what they could learn from the web:

  • Rich media: Terminals have needed support for images, videos, and tabulated results since 1985.
  • Fonts: Monospace is excellent for code but poor for reading. A capable terminal should allow mixing fonts within a single interface for better legibility.
  • Spacing: Moderate whitespace and line-height help distinguish UI elements and improve text readability.

They also need UI elements that go beyond ASCII bar characters before they can replace conventional interfaces for most people.

The way forward requires a reboot. We need toolkits that produce fast, consistent, composable interfaces by default—so excellent design isn't the domain of a few top practitioners, but something even junior developers can achieve.

We need to stop defending flashy but inefficient design anti-patterns. We should cease treating our users like beginners by designing for the lowest common denominator. Instead, we need more applications like Vim and Emacs that reward users for improving their skills, and we need to train people to use them. Networked applications can cache content and make remote API calls asynchronously, removing the human from the data-fetching loop.

A future where filing a bug or paying a bill is fast and efficient is within reach, but it won't arrive by doubling down on today's design trends.