Skip to main content

Featured

Ring buffer and audio streaming

Ring buffer and audio streaming

REAL-TIME MULTIMODAL AI — PART 1/5 Day 1: The Acoustic Frontier — Full-Duplex Audio Streaming, PCM Ring Buffers, WebSockets vs. WebRTC & Silero VAD 25 min read Series: The Dharma of Development Multimodal AI (Day 1 / 5) Level: Principal / Real-Time AI Systems Architect 🎙️ Context: Text-based chat interfaces are forgiving: if an LLM takes 1.5 seconds to emit its first token, the user barely notices. But human voice conversation operates under ruthless biological constraints. In natural human dialogue, the average gap between one person finishing a sentence and the other responding is 200 to 300 milliseconds . Anything above 800 milliseconds feels robotic, awkward, and broken. When engineers build their first voice agent, they often record a complete `.wav` file on the client, upload it over an HTTP POST request, run batch transcription, query an LLM, synthesize speech, and download the response—resulting in a painful 4-to-6-second latency stall . Worse, if the...
Post a Comment
Read more

Why Modern Software Is Slow, Heavy, and Unstoppable

The Everything-Is-Bloated Thesis: Why Modern Software Is Slow, Heavy, and Unstoppable

"Software is getting slower more rapidly than hardware becomes faster." — Niklaus Wirth (1995)

In 1969, the Apollo 11 Guidance Computer navigated humans through 240,000 miles of space and landed them on the moon using 4 kilobytes of RAM and 72 kilobytes of ROM.

Today, opening a basic chat application on a $2,000 laptop requires:

  • 1.5 Gigabytes of active system memory
  • 14 background helper processes
  • An entire bundled instance of Chromium
  • 400 MB of JavaScript frameworks, asset bundles, and tracking pixels

We have multi-GHz CPUs with 16+ cores, NVMe SSDs transferring 7 GB per second, and dedicated Neural Processing Units. Yet, clicking a button in a desktop calendar app introduces 300ms of input latency, and typing in a web-based text editor regularly drops frames.

Modern software bloat isn't just about JavaScript web apps on the desktop. It is a systemic, multi-layered crisis spanning from the silicon up to the user interface—fueled by developer convenience, corporate surveillance, and economic traps that keep users locked in.

comparing lean native software to modern bloated software. On the left, a sleek rocket labeled "Native App (Lean)" powered by Rust, Swift, and C++ logos launches


1. The Electron Paradigm: Web Browsers Disguised as Apps

The most visible front of desktop bloat is the widespread adoption of web-runtimes-as-desktop-apps, spearheaded by Electron and similar execution environments.

+-----------------------------------------------------------+
|                      Your App Logic                       |
+-----------------------------------------------------------+
|                   React / Vue / Svelte                    |
+-----------------------------------------------------------+
|                      Node.js Runtime                      |
+-----------------------------------------------------------+
|                   Chromium Engine (V8)                    |
+-----------------------------------------------------------+
|                     Operating System                      |
+-----------------------------------------------------------+

Historically, native applications compiled directly to machine code and linked against system dynamic libraries provided by the OS (Win32, Cocoa, GTK/Qt).

Today, almost every app running in your system tray bundles:

  1. A complete copy of the Chromium browser engine
  2. A complete Node.js runtime
  3. Megabytes of JavaScript framework runtimes and virtual DOM reconciliation engines

If you run Slack, Discord, VS Code, Spotify, and Microsoft Teams simultaneously, you aren't running five native applications. You are running five separate, isolated web browsers, each consuming 500MB to 1.5GB of RAM to render what is essentially styled HTML and CSS.

2. Dependency Hell & Abstraction Stacks

Modern software development heavily prioritizes developer velocity over runtime efficiency. While this trade-off makes short-term economic sense for tech companies, it leads to staggering dependency chains.

Consider a standard modern frontend or backend service build tree:

Your Code (50 KB)
  ├── Dependency A (2 MB)
  │    ├── Sub-dependency A1
  │    └── Sub-dependency A2
  ├── Dependency B (15 MB)
  └── 1,400 deeper transitive dependencies...

To pad a string, parse a date, or position a tooltip, developers routinely pull in heavy third-party packages. A standard npm install for a simple single-page web app routinely pulls down hundreds of megabytes and tens of thousands of individual files into node_modules.

The Cost of Layered Abstractions

Every layer in the execution stack adds performance overhead:

Layer Technical Responsibility Real-World Overhead
High-Level UI React / Component State Virtual DOM diffing & state garbage
Script Runtime JavaScript V8 Engine JIT compilation overhead, GC pauses
Cross-Platform Electron / WebView Bridge IPC serialization, DOM rendering pipelines
Operating System OS Scheduler & Virtual Memory Excessive process context switching

3. The Telemetry & Surveillance Tax

Software today is rarely just a tool; it is an active data-extraction engine.

When you launch a modern application, a non-trivial portion of your system resources is dedicated not to handling your input, but to measuring you:

  • Always-On Analytics: Crash reporting SDKs (Sentry), product analytics (Mixpanel, Amplitude), user recording tools (FullStory), and A/B testing engines (LaunchDarkly) execute continuously in the background.
  • Network & UI Stutter: Event batching, background serialization, and heartbeat pings saturate UI threads and flood local network stacks even when the app sits idle.

Your machine isn't running slow because processing your keystrokes is hard. It is running slow because it is continually packaging up telemetry, serializing JSON, and transmitting user interactions to remote logging endpoints.

4. OS-Level Bloatware & Degradation

The bloat starts long before you launch a user-installed app. Operating systems themselves have degraded into ad platforms and service aggregators.

  • Pre-Installed Background Services: Modern Windows and macOS installations ship with dozens of forced background daemons for cloud syncing, search indexing, AI assistant agents, and cross-device communication.
  • OEM Partner Ware: PC vendors bundle trial antivirus software, display utilities, and hardware control suites that duplicate kernel functionality while running heavy background hooks.
  • Notification & Web Widgets: OS shell processes now render dynamic web content inside taskbars and start menus, requiring web rendering engines to be permanently resident in OS core processes.

5. Feature Creep and the 80/20 Trap

Software is built by corporate committees, not minimalist artisans.

  • The Feature Arms Race: To justify subscription renewals and maintain parity with competitors, product teams continuously bolt on new features.
  • The 80/20 Reality: 80% of users only need 20% of a tool's features. However, every user segment requires a different 20%. Software grows to accommodate the union of all feature requests, resulting in an application where 90% of the executable code is dead weight to any individual user.

6. WHY AREN'T PEOPLE SWITCHING? The Lock-In & Subsidization Trap

If modern software is so bloated, slow, and resource-hungry, why don't users switch to lightweight, native, or open-source alternatives?

The answer lies in structural economic traps deliberately designed to prevent migration.

A. The UI Subsidization Engine & API Price Asymmetry

Why does everyone use heavy, ad-laden, web-based interfaces instead of clean, lightweight native clients? Because the raw data APIs are priced exponentially higher than the "free" bloated web UIs.

Take Google Search as a prime example:

  • Google Search UI: Completely free to use in a browser. Cost: $0. But it comes bundled with megabytes of JavaScript, ad trackers, sponsored results, and layout shifts.
  • Google Search API (Custom Search JSON API): Costs around $5.00 per 1,000 queries. If a developer built a ultra-fast, 2MB native desktop app that executed 50 searches a day for a user via official APIs, that app would cost $7.50/month per user just in raw backend query costs.

We saw this same phenomenon play out across the web:

  • Reddit & Twitter/X: Devastated third-party, lightweight native apps (like Apollo, Tweetbot, and Sync) by raising API prices to millions of dollars per year.
  • The Economic Incentive: Companies force you to use their bloated web UI because that UI is where they recover costs via advertisements, tracking data, and upselling. The bloat is structurally subsidized by the ad-tech business model; lightweight native clients are economically priced out of existence.

B. Walled Gardens & Proprietary Network Lock-In

You cannot simply switch from Slack or Microsoft Teams to a lightweight IRC or Matrix client if your employer uses proprietary workspace protocols.

  • Closed Ecosystems: Protocols are intentionally kept proprietary or unstable to prevent third-party native clients from connecting without breaking every few weeks.
  • Network Effects: The value of a communication platform lies in who is on it. Even if a user desperately wants a 10MB C++ chat client, they cannot use it if their team demands Huddle integrations, custom canvas features, and enterprise audit logs.

C. Feature Loss & Interoperability Penalties

When users attempt to switch to lean, open tools, they face an immediate "feature bankruptcy":

  • Document Fidelity: Switching from Microsoft Word to a lightweight markdown editor or a fast native office suite (like LibreOffice) often results in broken formatting when sharing files with clients.
  • Enterprise Compliance: Lean tools rarely ship day-one support for Single Sign-On (SAML/Okta), Data Loss Prevention (DLP), or corporate security agents. The enterprise forces the use of the bloated monolith because it satisfies the compliance checklist.

7. The Counter-Movement: Lean, Native, and Lightweight Software

Despite these structural hurdles, a growing engineering counter-movement is proving that high-performance, resource-efficient software is still possible.

Modern Lean Alternatives

Category Bloated Monolith Lightweight Native Alternative Why It Wins
Code Editor VS Code (Electron / Chromium) Zed / Sublime Text Written in C++/Rust, GPU-accelerated, starts in <50ms
App Desktop Shell Electron Tauri Uses OS native WebView; bundle size <10MB, tiny RAM footprint
Media Player Heavy OEM Media Players mpv Direct hardware decoding, zero interface overhead
Database Engine Enterprise DB Clusters SQLite Zero config, single C file, billions of deployments
Terminal Web-based Terminals Alacritty / Foot Direct GPU rendering, written in Rust/C

Conclusion: How We Fix the Bloat Culture

Software bloat isn't an unchangeable law of physics—it is a cultural and architectural choice. Hardware improvements should make software feel instantaneous, not merely keep pace with increasingly heavy runtimes.

To break the cycle:

  1. Enforce Strict Performance Budgets: Treat RAM footprint, cold-boot time, and input latency as hard technical constraints during CI/CD builds—not optional post-launch polish.
  2. Audit Dependencies Aggressively: Question every package brought into node_modules or Cargo.toml. Before adding a massive library for a handful of functions, write the native code yourself.
  3. Decouple Logic from Runtimes: Use lightweight wrappers like Tauri or native toolkits instead of bundling entire browser platforms for simple desktop tools.
  4. Demand Open APIs: Push back against platforms that price-discriminate against clean, third-party native software interfaces.

What's the most egregiously bloated app on your system right now? What lean software alternatives do you rely on every day? Let's talk in the comments below!

Comments

Post a Comment

?: "90px"' frameborder='0' id='comment-editor' name='comment-editor' src='' width='100%'/>