The reason Emacs survived 50 years while countless modern IDEs rose and died is architectural: Emacs isn't just a text editor with a plugin API—it's an interactive Lisp runtime that treats text buffers as first-class citizens.
Modern editors build layers upon layers of IPC, JSON-RPC protocols, and sandboxed extensions to keep the user from touching the core. Emacs did the opposite: it gave the user direct access to the live execution state. You don’t "configure" Emacs from the outside; you mold it into the exact operational extension of your own thought process.
In an era where modern developer tools consume gigabytes of memory just to render a UI tree, there is something deeply grounding about a piece of software from 1976 that still offers the most malleable computing medium on earth.
GNU Emacs really didn't start until 1984, but I keep thinking it would be interesting to compare Emacs' resource usage to Zed (or Gram). Then I realize I can't be bothered to run either of those long enough to do it.
Compared to VSCode, Eight Meg And Constantly Swapping does sound ridiculously parsimonious in 2026.
> it would be interesting to compare Emacs' resource usage to Zed (or Gram)
The core of GNU Emacs is written in C, and there are GNU-licensed Emacs variants which are entirely written in C. I really doubt anything like a new Zed/Gram fork would perform better than, say, QEmacs.
Modern editors build layers upon layers of IPC, JSON-RPC protocols, and sandboxed extensions to keep the user from touching the core. Emacs did the opposite: it gave the user direct access to the live execution state. You don’t "configure" Emacs from the outside; you mold it into the exact operational extension of your own thought process.
In an era where modern developer tools consume gigabytes of memory just to render a UI tree, there is something deeply grounding about a piece of software from 1976 that still offers the most malleable computing medium on earth.