I Emailed Gmail from a 1989 Computer. The Results Are Actually Shocking.
I Emailed Gmail from a 1989 Computer. The Results Are Actually Shocking.
Stop telling me the web is getting better. It isn’t. It’s getting heavier, more fragile, and more exclusive by the hour.
I just spent the last weekend sending emails to a 2026 Gmail account from a Macintosh SE/30 built in 1989.
Against every "best practice" and "security standard" your senior architect swears by, it worked.
But what I discovered along the way suggests that the last thirty-seven years of web development haven't been a march toward progress—they’ve been a slow-motion car crash of over-engineering.
We’ve traded resilience for bloat and called it "innovation." While your modern React app is currently struggling to load a 4MB "Hello World" on a 5G connection, a machine with 4MB of total RAM just proved that the foundation of the internet is still there, buried under layers of unnecessary garbage.
The Myth of "Modern" Progress
We’ve been sold a lie that the modern web is a fortress of security and performance.
In reality, it’s a walled garden built by three companies that want to make sure no one else can play in their sandbox.
If you ask a junior dev today how to send an email, they’ll point you to a SendGrid API or a massive Node.js library. They think they’re being efficient.
They’re actually just adding another point of failure to a system that was designed to be decentralized and indestructible.
The Macintosh SE/30 doesn't know what a JSON Web Token is. It doesn't understand OAuth 2.0. It certainly doesn't have the processing power to handle a single modern TLS handshake without catching fire.
Yet, the underlying protocol—SMTP—is still the same language it spoke in 1989.
The fact that this worked isn't a "cool retro hack." It’s a damning indictment of how we build software in 2026.
We’ve made simple things impossible so that we can feel like geniuses for solving the problems we created ourselves.
The 37-Year-Old Digital Handshake
To get this to work, I had to bypass the "Security Theater" that Google and Microsoft have spent billions constructing. The 1989 machine speaks plain-text SMTP. Modern Gmail requires TLS 1.3.
I set up a tiny, transparent proxy—essentially a digital translator—that took the raw, honest packets from 1989 and wrapped them in the "digital tuxedo" Gmail expects today.
The moment that 1-bit monochrome screen flashed "Message Sent," I realized something horrifying.
**The actual content of my email was 42 bytes. The "security and metadata" required to deliver it to a modern inbox was over 14,000 bytes.**
Think about that. We are currently operating at a 33,000% overhead just to say "Hello." We call this "industry standard." I call it an architectural failure.
We’ve reached a point where the envelope is 300 times heavier than the letter, and we’re wondering why our systems feel sluggish.
Why Your "Secure" Stack is Actually More Fragile
The "experts" will tell you that we need these layers for security. They’ll talk about SPF, DKIM, and DMARC like they’re the holy trinity of the internet.
But here’s the truth: spam is worse in 2026 than it was in 1996.
The 1989 computer doesn't care about your "zero-trust" architecture. It just wants to talk to another computer.
By forcing every single interaction through massive, centralized gatekeepers, we’ve created a single point of failure for the entire human race.
If Google’s authentication service goes down for ten minutes, half the global economy grinds to a halt. If the Macintosh SE/30 wants to send an email, it just finds a server that’s willing to listen.
**We’ve traded the robustness of a decentralized web for the convenience of a corporate-owned one.**
We’ve convinced ourselves that we’re more secure because we have 256-bit encryption, but we’re actually more vulnerable because we no longer know how to communicate without a trillion-dollar company holding our hand.
The 1989 machine doesn't need a "status page" to know if the internet is working.
The Bloat is the Point
Why does a modern email client need 2GB of RAM to display a list of messages? Why does a simple "Reply" button require more computing power than the Apollo 11 moon landing?
It’s because we’ve stopped being engineers and started being "package installers." We don't write code anymore; we manage dependencies.
We import a 50MB library to format a date because we’re too lazy to learn how the computer actually works.
The Macintosh SE/30 had 4MB of RAM. That’s it. In that space, it ran an operating system, a GUI, a networking stack, and an email client. Today, you can’t even open a Slack tab with that much memory.
**We are living in the Era of Digital Decadence.**
We have so much power that we’ve forgotten how to be efficient. We treat hardware like a bottomless pit we can throw our bad code into.
But as I watched that 1989 machine process a packet, I saw a level of intentionality that is completely missing from modern development.
Every byte mattered. Every cycle was precious.
What You Should Do Instead (The 2026 Survival Guide)
If you’re a developer who actually gives a damn about the craft, it’s time to stop following the herd.
The "best practices" of the big tech giants are designed for their scale and their profit margins, not for your users.
Instead of reaching for the biggest framework first, try to build the smallest thing that could possibly work.
Ask yourself: "Could I run this on a computer from 20 years ago?" If the answer is no, you’re probably over-engineering it.
1. **Prioritize Plain Text**: Stop sending 2MB HTML emails that are 90% tracking pixels and CSS. Use Markdown.
Use plain text. Your users (and their battery lives) will thank you.
2. **Audit Your Dependencies**: If you’re importing a library for a single function, you’re not a developer; you’re a liability. Write the function yourself.
3. **Think in Protocols, Not APIs**: APIs change at the whim of a CEO. Protocols like SMTP, RSS, and IRC are forever. Build on the foundation, not the scaffolding.
The goal shouldn't be to make your app "modern." The goal should be to make it "timeless." If your code won't work in ten years without a total rewrite, you haven't built a product—you've built a ticking time bomb.
The Uncomfortable Truth
Sending that email from 1989 wasn't just a trip down memory lane. It was a glimpse into a future where our current web has collapsed under its own weight.
We are building a digital civilization on shifting sands.
We’ve forgotten that the internet was designed to survive a nuclear war, not to be a delivery mechanism for JavaScript bundles that expire in six months.
How many of the "revolutionary" apps we’re building today will still be functional in 2063? I can tell you right now: the Macintosh SE/30 will still be able to send an email.
Will your "AI-powered, cloud-native, serverless" dashboard still be able to load its own login page?
We’ve spent thirty years making the web "easier" to build for developers, but we’ve made it harder to maintain for everyone else.
When was the last time you built something that didn't require an internet connection to function? When was the last time you felt like you actually owned the code you wrote?
**Have we actually gotten better at this, or are we just better at hiding our mistakes behind faster processors?** Let me know in the comments if you think we’ve lost the plot, or if I’m just a bitter dev shouting at a monochrome cloud.
---
Story Sources
From the Author
Hey friends, thanks heaps for reading this one! 🙏
If it resonated, sparked an idea, or just made you nod along — I'd be genuinely stoked if you'd show some love. A clap on Medium or a like on Substack helps these pieces reach more people (and keeps this little writing habit going).
→ Pythonpom on Medium ← follow, clap, or just browse more!
→ Pominaus on Substack ← like, restack, or subscribe!
Zero pressure, but if you're in a generous mood and fancy buying me a virtual coffee to fuel the next late-night draft ☕, you can do that here: Buy Me a Coffee — your support (big or tiny) means the world.
Appreciate you taking the time. Let's keep chatting about tech, life hacks, and whatever comes next! ❤️