We need to talk about an uncomfortable truth in tech: modern software is accidentally exclusionary, built by the privileged for the privileged. While developers debate framework choices on their M3 MacBooks, most of the world is trying to participate in the digital economy with phones that overheat opening a browser.
This isn't just about RAM or processing power. It's about systematic barriers preventing billions from accessing education, employment, and economic opportunity.
The Hardware Reality Gap
According to StatCounter Global Stats, here's what "normal" looks like for most of the world:
- •Most common Android RAM globally: 3-4GB (DeviceAtlas 2024 Mobile Web Intelligence Report)
- •Median mobile connection globally: 43.5 Mbps download, but with high variability (Speedtest Global Index)
- •Top selling phones in India/Africa: Xiaomi Redmi 9A, Tecno Spark - budget devices under $150
- •Desktop browser distribution: 35% of users still on Windows 7/8 (StatCounter)
Now here's what modern software actually demands:
- •Slack desktop app: Measured at 1.2GB RAM at idle, entire Chromium instance for chat
- •Microsoft Teams: Consistently uses 500MB-2GB RAM, users report system freezes
- •Median webpage 2024: 2.2MB transfer size, 70+ requests (HTTP Archive)
- •Average React app: 300KB+ of JavaScript, before any actual application code
The mismatch isn't a bug—it's a systemic blind spot.
Loading diagram...
Real People, Real Impact
Let me share some stories that should keep us up at night:
A computer science student in Dhaka:
"I download PDFs of web articles because the actual websites make my laptop overheat. The CPU throttles, the fan screams, and I can't even type. The modern web assumes I have a gaming PC just to read text."
A freelance designer in Lagos:
"I lost a client because I couldn't run Figma smoothly during our call. They asked why I wasn't sharing my screen. How do I explain that their 'simple' design tool uses more resources than my entire computer has?"
A developer in Karachi:
"I can code for 6 hours on battery, or I can run Slack for 45 minutes. So I use IRC and get called 'unprofessional' by clients who don't understand the constraint."
These aren't edge cases. They represent the majority of global users.
The Electron Elephant in the Room
Let's look at actual memory usage for common developer tools:
Text Editors (editing same 1000-line file):
- VS Code (Electron): ~400MB RAM
- Sublime Text (Native): ~80MB RAM
- Vim: ~10MB RAM
- Notepad++: ~15MB RAM
Chat Applications:
- Slack (Electron): ~1.2GB RAM (idle)
- Discord (Electron): ~800MB RAM (idle)
- Element (Web): ~300MB RAM
- IRC (HexChat): ~25MB RAM
The pattern is clear: Electron apps use 10-50x more memory than native alternatives.
Loading diagram...
But it's not just Electron. Modern web development has normalized excess:
- •JavaScript bundle growth: Median grew from 100KB (2011) to 450KB (2024) per HTTP Archive
- •Framework overhead: React (45KB) + React-DOM (130KB) before writing any features
- •Third-party scripts: Average page loads 21 third-party scripts
- •Memory usage: Chrome regularly uses 150MB+ per tab, even for simple sites
Success Stories: It Doesn't Have to Be This Way
Some organizations understand that performance equals access:
Facebook Lite:
- •2MB APK (vs 65MB+ for regular Facebook)
- •Works on 2G networks
- •5x higher engagement in emerging markets
- •50% of new signups in 2019 came from Lite version
Twitter Lite (PWA):
- •600KB over 3G (vs 23MB iOS app)
- •65% increase in pages per session
- •75% increase in Tweets sent
- •20% decrease in bounce rate
Pinterest PWA rebuild:
- •40% less bandwidth than native app
- •44% increase in user-generated ad revenue
- •60% increase in core engagement
Wikipedia Zero:
- •Average page: 50KB
- •No JavaScript required for reading
- •Serves 15 billion+ page views monthly
- •Works on feature phones from 2005
Performance Archaeology: The Web's Memory Problem
Let's look at how popular sites have bloated over time:
Gmail Evolution:
2004: ~100KB total page weight
2010: ~400KB, still mostly HTML
2024: 20MB+ initial load, 2.5GB memory after an hour
Reddit:
old.reddit.com: 200KB, loads instantly
new.reddit.com: 3MB JavaScript, constant loading states
Slack Web:
2014: 700KB total
2024: 3.2MB gzipped, 26MB uncompressed JavaScript
Twitter/X:
2010: 200KB total
2024: 2MB+ JavaScript bundle
Alternative (nitter): 70KB, no JavaScript required
The HTTP Archive shows median page weight grew from 468KB (2010) to 2.2MB (2024), a 470% increase. During the same period, global average connection speeds grew from ~5 Mbps to ~46 Mbps (Ookla), roughly 9x faster. We got 9x more bandwidth and made pages feel the same speed by bloating them 5x.
Loading diagram...
The Framework Industrial Complex
JavaScript framework churn hits emerging markets hardest:
javascript
1 // Silicon Valley developer:2 npm create vite@latest my-app3 cd my-app4 npm install // 2 minutes, 200MB node_modules5 npm run dev // Instant hot reload, buttery smooth6 7 // Developer in Bangladesh on 5-year-old laptop:8 npm create vite@latest my-app9 cd my-app10 npm install // 45 minutes, laptop overheating11 npm run dev // 30 seconds to start, 100% CPU usage12 // Battery dies after 40 minutes
Every "developer experience" improvement assumes developer privilege. Fast machines, unlimited bandwidth, stable power. The rest of the world pays the price.
The Thermodynamics of Waste
Here's what we don't discuss at tech conferences: every line of inefficient code is a small act of environmental vandalism. Not metaphorically—literally.
When your React app re-renders unnecessarily, somewhere a server farm burns more coal. When your webpack bundle includes three date libraries because you forgot to check, a data center in Virginia spins up another cooling unit. When you ship an Electron app that idles at 1.2GB RAM, you're demanding that millions of users either upgrade their hardware (creating e-waste) or accept permanent thermal throttling, burning more electricity to do less work.
We treat computation as if it were free. It isn't. Every CPU cycle has an energy cost. Every bit transmitted heats a wire, powers a router, spins a disk. The second law of thermodynamics doesn't grant exceptions for "developer experience."
The math is uncomfortable:
Global data centers consume 460-500 TWh annually (IEA 2023)—roughly 1-2% of worldwide electricity demand. That's more than some countries. Digital technology's carbon footprint exceeds commercial aviation. And unlike aviation, which has arguably plateaued, our industry's energy appetite grows exponentially.
✨
Wirth's Law: "Software is getting slower more rapidly than hardware is getting faster."
Named after Niklaus Wirth (creator of Pascal), this observation from 1995 predicted our current predicament: we've become so accustomed to Moore's Law bailing us out that we've stopped optimizing entirely. Hardware doubles in speed every 18 months, so we let software bloat 4x in the same period.
The result? Your new laptop feels exactly as slow as your old one.
Consider the cascade:
- •Your bloated SPA forces users to upgrade from a 4-year-old laptop to a new one
- •Manufacturing that laptop requires mining rare earth minerals, often in environmentally catastrophic ways
- •The old laptop becomes e-waste—59.4 million metric tons generated globally in 2022, only 22.3% properly recycled
- •The new laptop, being more powerful, demands more electricity throughout its lifetime
- •Your app still runs poorly because you've already expanded to fill the new capacity
There's a perverse irony here. We optimize developer iteration speed (hot module reloading, instant builds, preview environments) at the cost of user iteration speed. We've accepted that our tools should be fast, but our products can be slow. We've built an entire industry on the assumption that user time is worthless, user electricity is free, and user hardware is infinitely upgradeable.
It isn't charity to write efficient code. It's basic engineering ethics.
When we ship a 5MB JavaScript bundle to render a login form, we're not just inconveniencing users. We're participating in a system that:
- •Accelerates hardware obsolescence
- •Increases global energy consumption
- •Contributes measurably to climate change
- •Produces literal mountains of toxic e-waste
The tragedy is that none of this is necessary. The web worked in 2010. Gmail loaded fast in 2007. Wikipedia still serves billions with kilobytes, not megabytes.
We've simply forgotten that efficiency is a virtue.
The Economics of Exclusion
Data costs matter when you're not on unlimited wifi:
Cost of 1GB mobile data (% of average monthly income):
- India: 0.68% ($1.50 USD)
- Nigeria: 2.73% ($2.80 USD)
- Brazil: 0.82% ($3.50 USD)
- USA: 0.16% ($8 USD)
Your 5MB JavaScript bundle costs:
- USA: $0.04 (irrelevant)
- India: $0.007 (small but adds up)
- Nigeria: $0.014 (meaningful for daily users)
A family sharing 2GB/month can visit your site:
- 50KB page: 40,000 times
- 2MB page: 1,000 times
- 5MB app: 400 times
Source: Alliance for Affordable Internet
Loading diagram...
Building for the Next Billion
The next billion internet users aren't coming from San Francisco or London. They're coming from:
- •Nigeria: 200 million people, mobile-first, data-conscious
- •Indonesia: 270 million people, archipelago geography, variable connectivity
- •Bangladesh: 165 million people, dense urban areas, older devices
- •Philippines: 110 million people, mobile-primary, budget devices
They're brilliant, motivated, and ready to participate in the digital economy—if we let them.
Practical Solutions for Inclusive Software
Performance Budgets That Reflect Reality
- •JavaScript:
<200KBcompressed - •First paint:
<1 secondon 3G - •Time to interactive:
<5 secondson budget devices - •Memory usage:
<500MBmaximum - •Works fully offline after initial load
Technical Approaches That Work
Use progressive enhancement, not client-side rendering by default:
html
1 <!-- This works everywhere -->2 <form action="/search" method="get">3 <input name="q" type="search">4 <button>Search</button>5 </form>6 7 <!-- Enhance when possible -->8 <script>9 if ('serviceWorker' in navigator) {10 // Add offline search11 }12 </script>
Choose lightweight alternatives with real numbers:
UI Libraries (minified + gzipped):
React + ReactDOM: 45KB + 130KB = 175KB
Preact: 3KB (95% API compatible)
Lit: 7KB
Alpine.js: 15KB
Vanilla JS: 0KB
CSS Frameworks:
Tailwind: 90KB (with PurgeCSS: ~10KB)
Bootstrap: 25KB (CSS only)
Milligram: 2KB
Custom properties: 0KB runtime
Build Tools:
Webpack bundle: Often 200KB+ of polyfills
Vite/esbuild: Modern browsers only, minimal polyfills
No build: Ship ES modules directly
Implement offline-first patterns:
javascript
1 // Cache essential resources2 self.addEventListener('install', event => {3 event.waitUntil(4 caches.open('v1').then(cache =>5 cache.addAll([6 '/',7 '/offline.html',8 '/style.css',9 '/app.js'10 ])11 )12 );13 });
Developer Tooling for Performance
Enforce budgets in your build process:
json
1 // .bundlesize.json2 [3 {4 "path": "./dist/js/app.*.js",5 "maxSize": "200KB",6 "compression": "gzip"7 },8 {9 "path": "./dist/css/app.*.css",10 "maxSize": "50KB"11 }12 ]
javascript
1 // webpack.config.js performance budgets2 module.exports = {3 performance: {4 maxAssetSize: 200000, // 200KB5 maxEntrypointSize: 250000, // 250KB6 hints: 'error' // Fail the build7 }8 };
Lighthouse CI configuration:
javascript
1 // lighthouserc.js2 module.exports = {3 ci: {4 assert: {5 assertions: {6 'first-contentful-paint': ['error', {maxNumericValue: 2000}],7 'interactive': ['error', {maxNumericValue: 5000}],8 'max-potential-fid': ['error', {maxNumericValue: 130}],9 'total-byte-weight': ['error', {maxNumericValue: 500000}]10 }11 }12 }13 };
Organizational Changes
Test on real constraints: Buy a Redmi 9A ($80). Use Chrome DevTools with "Slow 3G" and 6x CPU throttling. Test with WebPageTest on emerging market presets.
Hire globally: Teams in emerging markets understand these constraints viscerally.
Make performance a feature: Track it, celebrate it, prioritize it.
The Path Forward
This isn't charity—it's opportunity. The organizations that figure out how to serve these markets will win the next decade. More importantly, they'll enable human potential currently locked out by thoughtless software design.
Every time we ship another bloated app, we're saying technology is only for the wealthy. We're building a digital caste system where your hardware determines your opportunities.
But it doesn't have to be this way. We have the knowledge. We have the tools. We just need to care.
What We Need to Do
Performance isn't an optimization—it's a fundamental requirement. Test on real constraints. Set hard limits. Design for interruption. Measure what actually matters.
The question is simple: will you build for the next billion users, or just for people like you?
Performance is a moral issue. When we build software that only works on expensive hardware, we're choosing who gets to participate in the digital future. Choose wisely.