Roben Kleene

The Era of Visual Studio Code

VS Code Hero

The most important thing I look for when choosing which tools to use is longevity. Learning software is an investment, and if you have to switch to another application later, you lose some of that investment.

In most software categories, choosing the software with longevity is easy, the most popular tools are usually the ones that have been around the longest. Microsoft Excel and Adobe Illustrator were both released in 1987 and, for the most part, they’ve remained the most popular software in their categories since then.

Text editors, on the other hand, are a software category where the most popular options are not the oldest. According to the Stack Overflow Annual Developer Survey, Sublime Text was the most popular text editor available on the Mac from 2015–2017. Sublime Text was released in 2008, a sprightly youth compared to Excel and Illustrator. Text editors have been a category with a lot of movement: In the last 20 years, TextMate, Sublime Text, and Atom have all been the text editor with the most momentum1. For big complicated desktop software, has any other category ever had so much movement?

I believe the era of new text editors emerging and quickly becoming popular has now ended with Visual Studio Code. VS Code has reached unprecedented levels of popularity and refinement, laying a foundation that could mean decades of market dominance. If, like me, one of your priorities for your tools is longevity2, then that means VS Code might be a great text editor to invest in learning today.

The case for VS Code’s longevity comes from several points we’ll cover in this piece:

  1. Popularity: It’s crossed a popularity threshold that no earlier text editor in recent history has crossed.
  2. The Text Editor as Platform: It’s the endgame of a revolution that saw text editors be remade around extensions.
  3. Paradigm Transcendence: It’s transcended its paradigm as a desktop app by becoming a hosted web app, and even a reference implementation.
  4. Company Management: It’s managed by a powerful tech company, and it’s being developed aggressively.

Popularity

VS Code is the most popular text editor today. It’s so popular, that it could be the most popular GUI programming tool of all time. Since 2015, Stack Overflow has included questions about text editors in their survey3. Back then Notepad++ was the most popular text editor, with 34.7% of respondents saying they were “likely to use it”. In the following years, the popularities of different text editors moved around a bit, but nothing ever broke the 40% mark. That is, until its most recent poll in 2019, when VS Code jumped to 50.7%. This was the second year in a row that VS Code increased by ~45%, this time jumping from 34.9% in 2018, where it had already been the most popular.

Text Editor Popularity 2015–2019

Text Editor Popularity

(Note that Stackoverflow started allowing multiple answers between 2015 and 2016, so I’d take the changes between those two years in particular with a grain of salt.)

The Text Editor as Platform

So VS Code is objectively wildly popular; the next point we’re going to look at is more qualitative. For the past couple of decades, text editors have been on a trajectory that I believe VS Code is the final representation of. This is the progression of text editors becoming platforms in their own right by increasing the role and capabilities of extensions. What follows is the history of this progression4.

Pre-2004: BBEdit, Emacs, and Vim

BBEdit, Emacs, and Vim are all great text editors in their own right, but they all have idiosyncrasies that (while beloved by people like me) prevent them from ever being the most popular text editor.

Emacs, and Vim’s predecessor Vi, were both first released in 1976, before many of todays user-interface conventions were solidified. Predating conventions like using a modifier key with Z, X, C, and V for undo, cut, copy, and paste. These keyboard shortcuts were popularized by the original Macintosh, released 1985, and Windows, which in 1992 with the release of Windows 3.1. Neither Emacs5 or Vim use these keys, and instead use their own terminology. They both use the term “yank” for example (although to mean different things, it’s copy in Vim, and paste in Emacs).

BBEdit was released in 1992, around the time that some of the first GUI tools emerged that would become dynasties. Note the proximity to Excel (1987), Illustrator (1987), and Photoshop (1990). And just like those apps, BBEdit is still relevant today. But unlike those apps, it’s not the most popular in its category, by a wide margin. The reason seems to be at least partially that it never fully adapted to a world where text editors put so much emphasis on package-driven ecosystems.

2004: TextMate

TextMate, released in 2004, is arguably the most influential text editor ever. Among the numerous features it popularized are abbreviation-based snippets, automatic paired characters, and fuzzy finding by file name. All of these features became staples in every popular text editor that followed. The implementations of Scope Selectors and theming that TextMate pioneered have also formed the basis for themes and syntax highlighting in every subsequent popular text editor.

That’s already a lot to originate from a single app, but it still doesn’t even include TextMate’s most significant innovation; the one that would go on to re-shape text editors, solidify niche status for every text editor that came before it, and pave the way for VS Code to become the most popular text editor in history a decade later. TextMate’s most important innovation was that it was the first popular text editor that was primarily built around extensions.

While TextMate popularized the concept of a text editor built around extensions, in hindsight, it didn’t go far enough. TextMate’s extensions had limitations that later text editors would thrive by removing.

2008: Sublime Text

Sublime Text, released in 2008, popularized the minimap and multiple cursors. And unlike TextMate and BBEdit, it’s cross-platform, running on Linux, MacOS, and Windows, which helped it reach a wider audience than those editors. But Sublime Text’s biggest impact was greatly expanding the capabilities of extensions.

Sublime Text’s extensions run in an embedded Python runtime with an extensive API, unlike TextMate which uses the scripting languages built-in to macOS, and rather than having a proper extension API, mainly centers on processing standard out.

Sublime Text greatly expanded what extensions could do, allowing more sophisticated integrations such as linters that included GUI components. And Package Control, the enormously popular package manager for Sublime Text built by Will Bond6, features a centralized source for package management, reducing the friction to browse, install, and update packages; a model that all subsequent popular text editors would also adopt.

Even with Sublime Text’s expanded extensions, it still didn’t go far enough. Package Control wasn’t built-in, and, while Sublime Text does have an API, its use of Python with custom calls for GUI components still left room for future text editors to make extensions more accessible to build.

2014: Atom

Atom, released by GitHub in 2014, finally brings extensions to their final form. Atom’s package manager is built in7, displays extension READMEs complete with inline images (and early extensions made by GitHub themselves popularized the convention of using animated GIFs to illustrate functionality), creating an extension experience reminiscent of an app store.

Then there’s the matter of HTML and CSS8. Atom is built on Electron9, which means the editor itself is written in JavaScript and runs on Node10. Compared to Sublime Text’s Python API; HTML, CSS, and JavaScript are some of most widely-known languages in existence, which greatly lowers the barrier of entry for creating extensions.

Atom had essentially perfected the extension-based editor, there was just one problem: It’s slow. Performance complaints have plagued Atom since its release, and market ended up split with Sublime Text, which is lightning fast by comparison.

2015: Visual Studio Code

VS Code was released in 2015, based on the Monaco Editor that Microsoft had first released in 2013 that could be embedded into websites. When GitHub released Electron along with Atom. Microsoft used it to create a desktop version of the Monaco Editor called Visual Studio Code.

VS Code takes the same formula as Atom11—a local web-based text editor written in Electron with an emphasis on extensions—and makes it more performant. VS Code makes extensions even more visible, by putting them in the sidebar, raising to the same level as file browsing, searching, source control, and debugging. VS Code extensions can have rich user-interfaces, being written in HTML, CSS, and JavaScript, and with full-access to Node, they can essentially do anything any other application can do. And indeed, some extensions start to look like apps in and of themselves.

With VS Code, the extension-based text editor has seemingly reached its final form. Ever since TextMate, extensions have increased in prominence and capabilities, and with VS Code, that progression appears to have culminated. There just isn’t anywhere else to go. Correspondingly, there isn’t a way a new text editor can leapfrog VS Code the same way previous text editors have been leapfrogging each other by improving extensions.

Paradigm Transcendence

So far we’ve looked at VS Code’s popularity, and its extensions implementation, as indicators of longevity. The third indicator we’ll look at is how VS Code has moved beyond the confines of the desktop. The code-server project runs VS Code as a regular web app, in other words, hosted on a server and accessed through the browser. GitHub’s Codespaces also run VS Code as a web app, this time by spinning up an ad hoc development environment.

Transcending a paradigm, like going from a desktop app to a web app, is a great indicator of longevity. For one, it means it’s more likely to be ported to more paradigms in the future. It takes herculean effort to port to a new paradigm, and expending that effort is a great indicator of value. Emacs and Vim were both ported from the terminal to GUI applications; they were too valuable not to have GUI versions. Photoshop and Excel both run on mobile12, and Illustrator is coming soon. Excel also has a web version13, and there’s a streaming version of Photoshop (although it’s been in closed beta for six years).

Not only has VS Code transcended the parameters of its initial implementation by becoming a web app, it’s also became something of a standard. Version 1.0 of the Theia IDE maintained by the Eclipse Foundation is a re-implementation of VS Code. VS Code is now not only a text editor, but also a model of how a text editor should behave.

Company Management

TextMate is largely the work of one developer, Allan Odgaard, the same with Sublime Text and Jon Skinner. Both of these applications eventually ran into trouble with frustrated users for perceived slow release schedules.

Here’s the history of major releases for these two applications:

  • 2004: TextMate 1
  • 2008: Sublime Text 1
  • 2011: Sublime Text 2 Alpha
  • 2012: Sublime Text 2
  • 2012: TextMate 2 Alpha
  • 2013: Sublime Text 3 Beta
  • 2017: Sublime Text 3
  • 2019: TextMate 2

Here’s a graph of the number of years between stable major releases (contrasted with the release dates for BBEdit 10–13 for comparison):

Text Editor Release Schedule

A couple things jump out from this graph immediately:

  1. TextMate 2 took a long time.
  2. Sublime Text has been consistent with their release schedule.

The complaints about Sublime Text seem to center around the gap between the Sublime Text 3 Beta being announced in 2013 and released in 2017, and a perceived lack of sufficient changes during that period. Sublime Text’s release schedule is slow when compared to BBEdit’s which has released three major versions (11, 12, and 13), while Sublime Text 3 has been in beta. Although Coda 2 from Panic was released in 2012, and wasn’t updated until just recently when its spiritual successor, Nova, was released. That’s a gap of around eight years, so it’s unclear whether Sublime Text’s release schedule is really an anomaly for a commercial text editor.

The current version of VS Code is 1.49, but VS Code is open source, so it plays by different rules than commercial apps. Major versions exist at least partially as an opportunity for companies to charge for upgrades.

Since VS Code is developed out in the open, we can evaluate its pace of development directly by reviewing its commit history. VS Code’s commit graph on GitHub tells a story of aggressive development, out pacing Atom, and even other large open source project like Facebook’s React (note that these graphs have different scales on the Y-axis).

Visual Studio Code Commit Graph

Visual Studio Code Commit Graph

Atom Commit Graph

Atom Commit Graph

React Commit Graph

React Commit Graph

Aggressive development pulls platforms away from the pack because the combination of forward momentum, and third parties building on the platform, is difficult to compete with14. This is the same combination that makes it so hard for new entrants to compete with popular browsers or OSes.

Conclusion

The goal of this piece is to determine if VS Code is a good investment in learning if you value longevity. An implication of the Text Editor as Platform, is that since TextMate’s introduction in 2004, every few years the text editor with the most momentum has changed. These would be short reigns by any standard, but they’re positively miniscule compared to apps like Excel and Photoshop. Learning a new text editor is a questionable investment if you expect something new to come along every few years.

VS Code is giving indications that the era of short reigns for text editors is over. It has the potential to maintain its position as the most popular text editor for a much longer time, possibly for decades, if we use examples of popular software in other categories as a guides. As we’ve outlined in this piece, the case for this is following:

  1. It’s crossed a popularity threshold that’s eluded other text editors by being used by over 50% of developers.
  2. It’s the final form of progression towards maximizing the power and visibility of extensions, making it immune to being leapfrogged by a new text editor with a more capable extension model.
  3. It’s moved beyond its origins as a desktop app, it’s also a web app, and it’s even become a model of how a text editor should behave.
  4. It’s managed by a company, so it’s unlikely to run into the development stagnation that’s plagued other text editors.

Before VS Code, I expected to never learn another general-purpose text editor that wasn’t Emacs or Vim again, it was just too risky. I’ve found a good way to make predictions is to assume things will stay the same; with text editors, that means expecting a new text editor will emerge every few years that gains most of the momentum. Expecting anything else to happen requires extraordinary evidence.

I believe VS Code has presented extraordinary evidence. I’m hoping it moves into the category with apps like Excel, Illustrator, Photoshop, software that has held the most popular position in its category for decades. These applications are reliably time investments that repay their cost of learning over the course of a career. Emacs and Vim have always been like that, but it’s always good to have more choice.


  1. If you think about it, the fact that the most popular text editor is newer than popular software in other categories is pretty strange, since text editing predates almost every other computer task. I think there are a couple of reasons for this. The first is that, on a technical level, writing a text editor is easier than other categories. While I don’t want to downplay the difficulty, text files are the lingua franca of computers, and nearly every major software development framework has at least some built-in support for them. Modern hardware also gives you a lot of performance headroom to develop a text editor that you don’t have if you’re developing, say, a video editor.

    The second reason is that it’s easier for users to switch text editors. While learning new complex software packages is always difficult, at least with text editors you can just open your existing projects with a new one and start editing them, since development projects are just made up of plain text files. There’s almost no other software category where this is true, most applications use proprietary formats that only their application can read. Another reason text editors tend to be easier to pick up is that it’s usually, but not always, easy to figure out the basics: How to enter and edit text. The basics are usually easier to figure out than, say, Adobe Illustrator, which is almost impossible to use without reading the manual.

    These factors combine to make text editors a particularly competitive market, and competition is effective in driving innovation. For my money, it’s made text editors the best software there is: They have the best balance of form and function of any software category. The closest competition are browsers and terminals, which also combine power and flexibility into an elegant package, but I give the edge to text editors, because browsers and terminals achieve their power by simply wrapping powerful concepts, a protocol and standard streams respectively. With text editors in contrast, the user interface is the application in a way that just isn’t true for those other types of applications. (This is also why browsers and terminals all feel roughly the same, while text editors are wonderfully diverse.) ↩︎

  2. If longevity is my priority, then why not use Emacs or Vim? For Vim, the answer is easy, I do already use it. But I don’t like writing prose in Vim’s modal editing model, so I started seeking out a non-modal editor to complement Vim.

    I’ve also spent a fair amount of time with Emacs, but it started crashing for me with an issue similar to this one. The author of that post solved their problem by compiling Emacs locally to run it in lldb, which is farther than I was willing to go to solve my problem.

    Emacs has a difficult balancing act to walk: It’s incredibly customizable, but it’s also fragmented. For the Mac, there are several popular ports. And, macOS isn’t a high-priority platform for Emacs. There’s a history of blocking macOS-only features from Emacs, as well as removing features that are already working. All-in-all this makes Emacs a hard sell on macOS. Customizability and fragmentation aren’t a great combination to begin with, because customizations will often work in one version and not another. But when combined with relatively low market-share (4.5% in 2019), and being on a platform that’s a second-class citizen relative to GNU/Linux, it’s hard to recommend, despite its strong points. ↩︎

  3. For some reason Stack Overflow removed the questions about developer tools like text editors for the 2020 survey unfortunately. ↩︎

  4. The progression of text editors becoming a platform is adapted from a previous post, which is in turn adapted from a Twitter thread↩︎

  5. Emacs does include cua-mode, which when turned on, defines C-x, C-c, C-v, and C-z as “cut (kill), copy, paste (yank), and undo respectively”. (The name cua-mode, is a bit of a misnomer because IBM Common User Access never used these key bindings.) ↩︎

  6. Will Bond was hired by Sublime HQ in 2016↩︎

  7. TextMate 2, released in December 2011, also had the first built-in extension browser in a popular text editor. ↩︎

  8. Light Table, released in 2012, is another important milestone in the web-based text editor journey. Light Table uses NW.js (formerly node-webkit), a predecessor to Electron, and it had an integrated package manager—foreshadowing the same combination that Atom would use a couple of years later.

    What’s most interesting about Light Table that it focused on innovative new features first, like watching variables change as code executes, evaluating code inline, and embedding running projects in the editor itself (some of these features inspired by Bret Victor’s seminal “Inventing on Principle” talk). These are features that even now, eight years later, have been slow to make it into the text editors that followed.

    Light Table was about new features that weren’t available anywhere else, whereas Atom, its closet successor that used a similar web-based approach, was about incremental improvements over previous text editors. Atom’s main feature was that it was web-based, whereas Light Table was about new features that had never been done before. ↩︎

  9. Electron was originally called “Atom Shell”↩︎

  10. Atom was originally written in CoffeeScript↩︎

  11. VS Code is less “hackable” than other text editors. For example, it doesn’t have an “init” file in the tradition of .emacs.d and .vimrc (Atom does have one). This makes VS Code harder to customize, since the only way to do it is to create an extension. ↩︎

  12. Presumably, VS Code would already exist on iOS were it technically feasible to do so, since it’s open source and so popular. It makes an interesting case study for the future of iPadOS as a platform. Because, if it’s not technically possible to port VS Code to iPadOS, then, as VS Code becomes ubiquitous, that increasingly becomes synonymous with iPadOS not supporting programming at all.

    The point is probably moot, because an iOS native version of VS Code would probably work with the same client-server model described in Paradigm Transcendence. But it’s still an interesting thought experiment, because I often see the prediction that iPadOS will [disrupt] the industry from the bottom(https://en.wikipedia.org/wiki/Disruptive_innovation). I wonder how can that happen if a platform puts up so many technical barriers for creating a text editor? ↩︎

  13. Another nice thing about having a web version is that web apps don’t have to abide by the App Store Review Guidelines, so applications prohibited by Apple can still exist on the platform. ↩︎

  14. As I’m fond of saying, if you’re looking for areas that will be disrupted by new technology, look for areas of neglect↩︎


Remembering the O'Reilly Mac OS X Innovators Contest

From 2003 to 2004, O’Reilly Media ran the O’Reilly Mac OS X Innovators Contest, sponsored by Apple via the Apple Developer Connection (now just Apple Developer). I still think of these winners as some of the high watermarks of app innovation. Many concepts we take for granted today were either introduced, or popularized, by apps on this list. Here are a few of my favorite examples:

  • NetNewsWire, while not necessarily the first RSS feed reader, was one of the most popular early ones. RSS feed readers are the origin of consuming media through streams of content, now exemplified by Twitter and Facebook’s Newsfeed.
  • SubEthaEdit was one of the earliest practical implementations of multiple simultaneous live document editing, a concept later brought to a much wider audience by Google Docs in 2006.
  • LaunchBar popularized many features we take for granted in search user interfaces today, such as seeing search results live as you type, fuzzy string matching, and combining search results of various types, such as apps, bookmarks, contacts, events, and files all into one unified interface.

I’ve listed the winners below, and linked to all the ones that are still maintained, so you can see visually just how many these apps are still around. All of these apps are over fifteen years old now.

2003 Round One Winners

2003 Second Round Winners

2003 O’Reilly Mac OS X Conference Winners

  • First Place, US Category: OmniOutliner
  • Second Place, US Category: iBlog
  • First Place, International Category: iStopMotion
  • Second Place, International Category: ACSLogo
  • Honorable Mention: F-Script

2004 Winners

  • First Place, U.S.: Delicious Library
  • First Place, International: FotoMagico
  • Second Place, U.S.: Curio
  • Second Place, International: iDive
  • Honorable Mention, U.S.: Nicecast
  • Honorable Mention, International: Process

macOS Big Sur: Has the Dust Finally Settled on Limiting Third-Party Apps?

Apple’s strategy for years has been to trade desktop power for cross-device feature parity. As expected, macOS Big Sur continues this trend, emphasizing a consistent user interface across devices, and focusing on cross-device development technologies like SwiftUI and Catalyst.

Personally, I wish Apple had different priorities. I’d like to see more apps like Sketch, an industry-leading creative app that’s built top to bottom on Apple technologies. But Sketch was released in 2010, and Apple hasn’t created any new frameworks like Core Graphics and Core Image that support these kinds of apps in over a decade. So I wasn’t holding my breath for them to announce anything new for these kinds of apps at WWDC this year.

Since Apple isn’t prioritizing powerful desktop apps with their own technologies, that means supporting these use cases mostly falls on third parties. This is where companies like Adobe, Avid, Maxon, and Microsoft come in. While Apple’s priorities regarding their own technologies have been clear for awhile now, what hasn’t been clear is their priorities for third-party apps, in particular, ones that aren’t sandboxed. The trend for the last few years has been making it harder to develop these kinds of apps for macOS. AEpocalypse (2018), Catalina’s security features (2019), and Notarization (2018) are all examples of this trend.

The overarching reason behind the changes that make developing these kinds of apps harder is “Security”. And unlike cross-device feature parity, it’s unclear exactly where this all ends. Because after all, the most secure system there is is the one that doesn’t run any software at all. That’s why it’s such a pleasant surprise, that, as far as I can tell, Apple has done everything they can to make Big Sur, and the accompanying transition to Apple Silicon, as seamless as possible, even for apps that aren’t sandboxed.

Some were predicting that Macs on Apple Silicon wouldn’t even run apps from outside of the Mac App Store, that didn’t happen. It seemed more likely that Apple would drop OpenCL and OpenGL, but those are sticking along for the ride. No details were known about whether there would be an emulation layer like the original Rosetta from the 2006 Intel transition. Apple appears to have gone above in beyond with Rosetta 2, which even supports plug-ins like VSTis, giving lots of options for migration paths for powerful modular software.

I’m still frustrated that there probably won’t be another Sketch for the foreseeable future, but that ship sailed a long time ago. And no other platform has a Sketch either, an industry defining app that’s a platform exclusive, so while Apple has lost a unique advantage that only they had, they haven’t lost anything that other platforms already have. Other platforms can run powerful modular software that’s distributed outside the Mac App Store, but today, so can new Macs running Big Sur. Here’s to hoping that the dust has settled, and the last of the restrictions on third-party apps are behind us now.




Software to Die For

Before I switched to being a full-time developer in 2010, I worked as a user-interface designer for seven years. Something that always bothered me during that time is that so much of what I was learning was just how to use Photoshop really well. After I switched to development, I was hesitant to ever invest that much in just learning a big software package again. “What if I choose wrong? And waste all those years of learning by switching to another software package?” I asked myself. Recently, I’ve re-evaluated that decision, based on my analysis of the market share of major creative applications. It turns out if I’d just chosen which software I want to learn ten years ago, for most categories, it would still be the same today. For some categories, it would still be the same if I’d chosen twenty years ago, and it’s often the first software that was ever introduced to solve a problem, even if that application is over 30 years ago, that’s still the best choice today. So it turns out I was overcorrecting relative to the risk in learning big complex packages, so now I’m investing in doing it again.

This is the list of software I’ve chosen to learn:

Some of these I already know quite well (Vim, Photoshop), and some I’ve barely touched (Premiere Pro, Final Cut Pro). I’m not happy with the duplication, and frankly, this is probably just too much for one person. Learning any one of these applications is an lifetime of work, let alone all of them. But I can’t decide what to cut, so here we are.