Are Modern IDEs Getting Too Fat?

A few weeks ago, I opened the same Java project in three different editors — IntelliJ, VS Code, and Zed — mostly out of curiosity. I wasn’t benchmarking, just observing.

What happened next was… revealing.

🧮 IntelliJ: multi-GB memory, high CPU usage
🧮 VS Code: slightly better, but still heavy
⚡ Zed: a fraction of both — instantly responsive

All three loaded the same codebase, yet their behavior couldn’t have been more different.

The Paradox of Modern Tools

IntelliJ and VS Code are remarkable pieces of engineering. They’ve evolved into ecosystems — not just editors — offering deep language integration, refactoring, and debugging features that make serious development easier.

But with that power comes weight. Over time, we’ve grown used to development tools that quietly consume gigabytes of RAM and peg CPUs at idle. We shrug it off. “It’s fine — machines are fast now.”

Except… sometimes it’s not fine. The cumulative friction adds up: sluggish autocompletion, delayed UI feedback, slow project indexing. Small delays chip away at the mental flow developers depend on.

When Speed Becomes a Feature

Zed, the newcomer in this small experiment, flips that expectation. It’s written in Rust, built as a native app, and renders its UI using the GPU — design choices that prioritize responsiveness from the ground up.

Opening the same project in Zed felt different. Not “different because it’s new” — but different because it snapped. There was no visible lag between thought and action. That immediacy reminded me of something we rarely talk about: performance can be a design principle, not an afterthought.

Why We Tolerate Bloat

It’s easy to see how we got here. Developer tools have expanded to cover everything from Git workflows to cloud deployment. That convenience hides the architectural cost: frameworks on top of frameworks, each abstracting a little more away from the metal.

This deep desire of feature over anything makes companies use forgiving platforms like the web stack (VS Code) or Java (IntelliJ). Computer memory and storage is cheap so all of us don't really feel the bloat. However, a tool like Zed exposes this bloat and shows you how much better things can be and how much bloat gets added by prioritizing features over performance.

We’ve accepted it because productivity features are tangible while latency is subtle.
You can see a new refactoring option. You can’t see the 120ms delay it adds to a keystroke.

The paradox of progress is that tools meant to make us faster can quietly slow us down.

A Return to Craft

Zed’s performance isn’t just about Rust. It’s about intent. Its creators treated speed as a core user experience metric, not a secondary optimization. In a sense, it’s software that respects your time.

This philosophy isn’t limited to editors. Figma, Fastmail, and even small command-line utilities that start instantly remind us that quickness is kindness.
Fast software feels invisible. It lets the idea stay in motion.

Flow State, Interrupted and Restored

For developers, milliseconds matter because they compound. Every pause in an autocomplete or laggy click is a micro-context switch. When tools get between thought and execution, creativity erodes.

That’s why lightweight, native, GPU-accelerated environments feel refreshing — not just because they’re fast, but because they get out of the way. They protect flow.

Where We Go From Here

None of this is an indictment of IntelliJ or VS Code. They’re phenomenal and essential for countless workflows. But experiments like Zed remind us that the pendulum can swing too far toward complexity.

Maybe the future of developer environments isn’t about more — it’s about refinement. Lean, native, GPU-powered, and close to the metal — tools that respect both the machine and the mind using it.

This reflection started as a short LinkedIn post that sparked thoughtful discussion. Developers pointed out that rich features justify heavier resource use — and they’re right. But it also raised a bigger question: how often do we make “fast” a design requirement, not an optimization task left for later?

“Performance can be a design principle, not an afterthought.”

Maybe it’s time we treat it that way again.