You’ve probably stared at a loading screen today. Maybe Slack took 15 seconds to load a single message. Maybe your browser ate 4GB of RAM just to keep three tabs open. We’ve been conditioned to accept this. We shrug, buy more RAM, and move on.
Then someone builds a fully functional paint application for MS-DOS. It runs on IBM PC-compatible hardware, requires only an MS-DOS shell, and is—as one Hacker News commenter put it—”fast as hell.”
And it takes up exactly 625 bytes.
625 bytes isn’t just a file size; it’s a middle finger to modern bloatware. That is smaller than a single high-res image file. It is smaller than the text of this very paragraph. Yet, it executes a complex, interactive task that modern developers would happily allocate 50 megabytes to achieve.
You might look at this and think it’s just a nostalgic hobby project, a cute weekend experiment for retro enthusiasts. It’s not. It’s a mirror reflecting how lazy modern software engineering has become.
We’ve traded elegance for convenience. We stack abstraction upon abstraction—frameworks on top of libraries on top of virtual machines—until the actual work the computer is doing is a microscopic fraction of the overhead required to manage the stack. We don’t have a hardware problem; we have an abstraction problem.
The developer of this DOS app built it from scratch in assembly. They didn’t have a save feature yet, but who cares? The point isn’t to replace Photoshop. The point is to show what happens when you strip away every single layer of modern crutch.
For developers, this is a brutal reminder that optimization and minimalism are still vital skills. For everyday users, it’s a wake-up call. You’ve been gaslit by the tech industry into believing that ‘more features equals better software.’ It doesn’t. More features usually just means more bloat, more bugs, and more battery drain.
True elegance isn’t adding features until it breaks; it’s stripping away until only the essential remains. The next time your laptop fan spins up just to open a text editor, remember the 625-byte paint app. It proves that we don’t need to accept software obesity as the status quo. We just need to start respecting the machine again.
FAQ
Q: But it doesn't even have a save feature. How is this better than modern apps?
A: It's not about feature parity; it's about proving what's possible at the absolute limit of constraint. It exposes how much invisible waste exists in modern tools that do the exact same basic tasks.
Q: What's the practical takeaway for modern developers?
A: Stop defaulting to heavy frameworks for simple tasks. Optimization and minimalism aren't dead arts; they are competitive advantages that lead to faster, more reliable software.
Q: Are you saying we should all go back to writing assembly?
A: No, but we should stop using a sledgehammer to crack a nut. If a 625-byte app can paint, your 500MB Electron app has no excuse.