JavaScript Creator Criticizes Bloated Web Software: Brendan Eich Attacks Electron and Slow Apps

Hello HaWkers, Brendan Eich, the creator of JavaScript, caused controversy by harshly criticizing the "bloat" of web-based applications in Windows 11. He pointed out that many modern software applications are slow and consume excessive resources due to their dependence on web technologies.

Have you ever felt frustrated watching a "simple" app consume gigabytes of RAM? Brendan Eich feels the same way, and he created the language many blame for it.

What Brendan Eich Said

In a series of social media posts, Eich criticized the trend of packaging entire browsers in desktop applications:

Main Points of Criticism

Identified problems:

• Electron apps load a complete Chromium for each instance
• Windows 11 has several web-based components that are slow
• RAM is wasted with multiple instances of web runtimes
• Performance sacrificed for developer convenience
• Users pay the price with more expensive hardware needed

Examples cited:

• Teams (Microsoft) - notoriously slow and heavy
• Slack - consumes GBs of RAM
• VS Code - Electron-based (though well optimized)
• Discord - another popular Electron app
• Spotify desktop - packaged web interface

The Irony of the Situation

The critic makes an ironic observation: he created JavaScript in 10 days in 1995 to run in browsers. He did not imagine that decades later, entire browsers would be packaged to run applications that could be native.

The Electron Problem in Numbers

To understand Eich's criticism, let us look at the numbers:

Resource Comparison

Simple chat app:

Implementation	RAM at Rest	App Size	Startup Time
Native (Swift/C++)	15-30 MB	5-20 MB	< 1s
Tauri (Rust + WebView)	30-60 MB	3-10 MB	1-2s
Electron	150-300 MB	150-400 MB	3-5s

What each Electron app includes:

• Complete Chromium (~100 MB)
• Node.js runtime (~30 MB)
• V8 JavaScript engine
• Entire web rendering stack
• Multiple processes (main, renderer, GPU)

Why Developers Choose Electron

Despite the problems, Electron dominates for practical reasons:

Advantages for developers:

• Single codebase for Windows, Mac, Linux
• Use familiar JavaScript/TypeScript, HTML, CSS
• npm ecosystem available
• Fast prototyping
• Easy to find web developers

The hidden cost:

• Users need more RAM
• Laptop battery drains faster
• Apps compete for resources
• Degraded user experience

Lighter Alternatives

Eich's criticism does not come without solutions. Modern alternatives exist:

Tauri

Tauri uses the operating system's WebView instead of packaging Chromium:

// Backend in Rust - native performance
#[tauri::command]
fn greet(name: &str) -> String {
    format!("Hello, {}! You've been greeted from Rust!", name)
}

fn main() {
    tauri::Builder::default()
        .invoke_handler(tauri::generate_handler![greet])
        .run(tauri::generate_context!())
        .expect("error while running tauri application");
}

Tauri benefits:

• Apps 10x smaller than Electron
• Uses less than 1/3 of RAM
• Backend in Rust (security and performance)
• Still allows using React, Vue, Svelte on frontend

Final Comparison

Framework	Minimum Size	Typical RAM	Backend Language
Electron	~150 MB	200-500 MB	JavaScript/Node.js
Tauri	~3 MB	30-80 MB	Rust
Neutralino	~2 MB	20-50 MB	JavaScript
Native	~1 MB	15-40 MB	C++/Swift/Rust

The Defense of Electron

On the other hand, Electron defenders argue:

Productivity Matters

Arguments in favor of Electron:

• Faster time-to-market
• Lower development cost
• Simpler maintenance
• Synchronized updates across platforms
• Guaranteed visual consistency

VS Code: The Counter-Example

Visual Studio Code is often cited as proof that Electron apps can be fast:

What Microsoft did differently:

• Aggressive performance optimizations
• Lazy loading of extensions
• Virtualization of long lists
• Smart use of Web Workers
• Constant profiling and bottleneck fixes

This shows the problem is not Electron itself, but how it is used.

The Future of Desktop Apps

The industry is responding to the criticism:

Emerging Trends

WebAssembly + WebView:

• Hybrid apps with WASM for critical parts
• Near-native performance
• Still uses web technologies

Advanced PWAs:

• Progressive Web Apps as alternative
• Light installation
• Automatic updates
• Growing OS support

Modern Native Frameworks:

• SwiftUI (Apple)
• Jetpack Compose (Android/Desktop)
• Flutter (cross-platform)

Conclusion

Brendan Eich's criticism resonates with many developers and users frustrated with heavy apps. The creator of JavaScript is not criticizing the web itself, but the excessive and unnecessary use of resources when lighter alternatives exist.

For us developers, the lesson is clear: consider the impact of your technology choices on end users. Not every app needs to load a complete browser. Sometimes less is more.

If you feel inspired by performance discussions, I recommend checking out another article: HTMX 2.0 Arrives With Revolution: Interactive HTML Without Heavy JavaScript where you will discover an alternative approach to web interactivity.

Let's go! 🦅