Twenty years ago, text editors were a hotbed of innovation. Comparative round-ups of these indispensable programming tools were read with great interest in technical magazines of the era, in much the same way that developers pored over the stats of compiler reviews.

Text editors—mostly from small companies—competed intensely with each other, so the lead would frequently flow back and forth among BRIEF, Multi-Edit, Emacs, KEDIT, SlickEdit and numerous other entrants. Likewise, the list of checkbox features they supported grew lengthier each year.

IDEs were still viewed as a beast rather than a solution. They had yet to establish themselves. The delay was largely due to the fact that hardware platforms could simply not deliver IDE performance that made them a notably better option than a good editor. The fate of two companies in the Unix market—Lucid and Centerline—both hinged on the inability of even workstation-class machines to run development environments quickly.

Lucid, which had some inkling of the problem because it also sold a version of Emacs (Lucid Emacs), foundered on the inability of hardware to keep up with its ambitions. How this played out is something I have debated with the company’s founder, Richard Gabriel, but there is no doubt that had today’s hardware been available then, Lucid would have been far more viable.

Centerline, an excellent interpreter-based IDE for C developers, ran large programs so slowly that catching a bug or memory leak frequently meant running the program overnight. This delay was the original inspiration for Reed Hastings (later the founder of Netflix) to write Purify, the memory-leak detector that became the basis of his first company, Pure Software.

In counterpoint, today’s multicore desktops, each churning at more than 2GHz, backed by at least 4GB of high-speed RAM, can provide so much muscle power that the advantages editors once enjoyed (speed, support for multiple languages, etc.) have evaporated and IDEs unarguably are the home where most developers work. The effects of this shift can be seen by visiting the websites of editor vendors—the few, that is, who still survive.

BRIEF—an extremely popular high-end editor, disappeared long ago, as did Polytron. KEDIT (from the Mansfield Group) and Multi-Edit (from what was American Cybernetics) have websites that look more like product graveyards. Even SlickEdit, which a decade ago was still standing up successfully to IDEs, has become frozen in time. Its latest version, 15.0, lists only Subversion among modern SCM tools (no Bazaar, Git, Mercurial or even Perforce), and it does not ship with language support for Groovy or Scala (although some later languages, such as F#, are supported).

There are some editors, such as UltraEdit on Windows and TextMate on the Mac, which find enough of a user base to keep going as commercial ventures, but it’s hard to believe their prospects are rosy. Emacs and Vim, of course, remain used in good part because they’re free and open source, and they had large user bases long ago.

Today, probably (I have no stats on this) the most widely recent editor is Notepad++, which continually ranks as one of the top projects on SourceForge. Despite its lack of documentation, especially on supporting new languages, it is small, fast and intuitive, and supports lots of language and traditional features. A similar open-source success is jEdit, which strides the barrier between editor and IDE.

Commercial editors are finding their prospects dimming because computing is becoming ever more visual. Client endpoints are shrinking and relying more on visual cues to function. This is true of all mobile devices and larger products such as tablets and iPads.

At the same time, applications on desktops and the Web are increasingly using RIA front ends. Laying out rich visual interfaces is the province of IDEs, not editors. The more visual the front end and the more multilingual the code, the more the IDE, not the editor, is the tool of choice.

I expect editors will become tools of the past, consigned to niche areas, and dominated by open-source implementations. An interesting business-school study can be made of the fact that not one of the editor vendors successfully made the transition to IDEs, even though the trend was clear and the transition took place over an extended period of time. So it goes.

After nearly 12 years of writing this column, I am transitioning to new work. I’ll be heading to Dr. Dobb’s Journal. If you’ve enjoyed my column, please check in on me at your convenience. My work at SD Times has been an unalloyed pleasure due in large part to working with Alan Zeichick, Dave Rubinstein, co-columnist Larry O’Brien, as well as other contributors to the publication, such as Alex Handy. I shall be attentively reading their words, albeit from a different remove. Thanks to them and, especially, to you!

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.