When I first saw Codespaces, I immediately wanted it. With ubiquitous high-speed internet, why not offload more work to the cloud? What could our devices look like if most of their power came from the server? What would their battery life be like?
Seamlessly leveraging remote resources has always felt like an idea that’s just around the corner, but never arrives. Just having a big beefy machine on site usually ends up being the most practical solution (outside of some specialized use cases)1.
Codespaces is perhaps the biggest play ever to take remote development more mainstream. Development has always been a prime candidate for remote computing, because with time-sharingmachines, it’s how the roots of programming itself began2.
Visual Studio Online to GitHub Codespaces
GitHub Codespaces began as a different product, called Visual Studio Online. Visual Studio Online was announced on the Visual Studio Blog in November 2019. Then, in April 2020, it was renamed to Visual Studio Codespaces, Nik Molnardescribed the motivation behind the name change on the same blog:
We learned that developers are finding Visual Studio Online to be much more than just an “editor in the browser”. They are saying that “the capabilities of this cloud-hosted dev environment make it the space where I want to write all my code“.
To better align with that sentiment, and the true value of the service, we’re renaming Visual Studio Online to Visual Studio Codespaces.
Visual Studio Codespaces was similar to GitHub Codespaces, but it did have some key differences. Visual Studio Codespaces wore more of its implementation details on its sleeve, in particular, as being built on top of Microsoft Azure. When you setup a Visual Studio Codespaces, it was linked to an Azure subscription and location, and you chose a “Default Instance Type” for new codespaces3.
The decision to remove these details from GitHub Codespaces, and provide quick access to launch a codespace from a repository, was highlighted in the announcement letter about shutting down Visual Studio Codespaces in favor of GitHub Codespaces:
During the preview we’ve learned that transitioning from a repository to a codespace is the most critical piece of your workflow and the vast majority of you preferred a richly integrated, native, one-click experience.
This is a great example of iterative product design. From a practical perspective, Visual Studio Codespaces is essentially the same product as GitHub Codespaces (and GitHub Codespaces is presumably also running on Azure), but hiding the virtual machine implementation details makes GitHub Codespaces feel different, and a bit more revolutionary4.
Tour
Once you’re in the Codespaces beta, a “Codespaces” item appears in the navigation menu when you click your user icon in the upper right5. Click it, and you’re brought to a screen where you can manage the Codespaces you’ve already created, including removing them by clicking “Delete” under the three disclosure dots.
Every repository also has an “Open with Codespaces” option, which can either create a new Codespace or open an existing one for that repository.
After opening a codespace, you’re brought to a browser window running Visual Studio Code. It works similarly enough to the desktop version that it’s practically indistinguishable6.
Alternatively, you can connect to the codespace directly from the desktop version of VS Code by using the Visual Studio Codespaces extension. The extension adds a “Remote Explorer” icon to the Activity Bar where you can connect to, and manage, your codespaces.
The About Codespaces section of the documentation explains a couple of details about the relationship between codespaces are repositories:
Each codespace is associated with a specific branch of a repository. You can create more than one codespace per repository or even per branch. However, each user account has a two-codespace limit during limited public beta.
Implementation Details
CodespacesusesDocker containers to setup development environments. GitHub and Microsoft calls a running codespace a “development container” presumably after Docker containers, emphasizing their close relationship.
Regarding what’s running locally, and what’s running in the development container, the Remote Development FAQ describes how the user-interface runs locally, i.e., in the browser or VS Code app, while a separate process running on the server (“VS Code Server”) handles the operations that need to happen on the server, such as file system access:
The VS Code Server is quickly installed by VS Code when you connect to a remote endpoint and can host extensions that interact directly with the remote workspace, machine, and file system.
The FAQ also includes this handy diagram illustrating what’s running on the server and what’s running locally:
Whether extensions runs locally or on the development container depends on whether they “contribute to the VS Code user interface”. If they do, they’re called “UI Extensions” and run locally, if they don’t, they’re called “Workspace Extensions” and run on the server.
Whether extensions are UI Extensions or not, they’re all installed on the development container at the path ~/.vscode-remote/extensions/:
% ls ~/.vscode-remote/extensions/
castwide.solargraph-0.21.1
davidanson.vscode-markdownlint-0.37.0
dbaeumer.vscode-eslint-2.1.8
dbankier.vscode-quick-select-0.2.9
eamodio.gitlens-10.2.2
editorconfig.editorconfig-0.15.1
...
The Rise of Virtualization
The story of server-side infrastructure over the last couple of decades is the story of the rise of virtualization, and, its sibling, containerization. Both are ways of abstracting the hardware away from the software running on it, which has some powerful benefits. It makes it easier add or remove hardware at will, for example, which simplifies scaling. It also facilitates automating configuration, which eases deployment. Both of these qualities of virtualization are leveraged by Codespaces.
AWS, Azure, Docker, Heroku, and Kubernetes are all examples of services or technologies that leverage virtualization or containerization. It’s also the backbone of most CI/CD and serverless systems. While virtualization has revolutionized the server-side, it hasn’t had much impact on development environments outside of specialized use cases.
There are two, equally valid, ways of seeing the origins of Codespaces: one, is as a natural extension of an editor that began as a browse-based version of Visual Studio (formerly called “Visual Studio Online” now “Azure DevOps Services”), the other is as another step in the march of virtualization revolutionizing every aspect of development. These could even be considered the same story: Azure DevOps Services is of course also built on virtualization.
The Promise of Remote Development
Just being able to quickly spin up a remote development machine from git repo to make an open source contribution, or to get a quick development environment to spelunk into a dependency’s implementation details, is already enough benefit to make Codespaces popular. But the ceiling of Codespaces’ success hinges on how useful it is for day-to-day development.
On the VS Code blog, the vision is expressed with admirable restraint, focusing on the benefits for large code bases and data models requiring “massive storage and compute services”:
Because the code bases are so large, we see engineers at shops like Facebook (and Microsoft!) use editors like vim to work remotely against secure and powerful “developer VMs”, using alternative cloud-based search and navigation services that scale beyond what even the best laptop can handle.
Data Scientists building and training data models often need massive storage and compute services to analyze large datasets that can’t be stored or processed even on a robust desktop.
In Facebook’s later announcement of their partnership with Microsoft on remote development, the advantages are expressed in broader terms, suggesting that “any developer can gain” from remote development:
As Microsoft’s Visual Studio Code team stated when they first released the remote extensions, remote development is an emerging trend. While our use cases may be more advanced than most development teams given our scale, any developer can gain the benefits of remote development:
Work with larger, faster, or more specialized hardware than what’s available on your local machine
Create tailored, dedicated environments for each project’s specific dependencies, without worrying about errors due to mixed or conflicting configurations
Support the flexibility of being able to quickly switch between multiple running development environments without impacting local resources or tool performance
Those are compelling advantages that most developers could benefit from. So what are the chances of Codespaces supplanting local development, not just for specialized use cases, but developer’s day-to-day work on their main project?
Remote development isn’t new, it’s been around since the dawn of programming, and VS Code already has best-in-class support for it. But remote development in VS Code, while frequently praised, hasn’t moved the needle much on its own for day-to-day development. Which means we can look at the advantages of remote development that VS Code already had before Codespaces, and note that they probably won’t be enough on their own to make remove development more popular. Here are the often cited advantages of remote development before Codespaces:
Developing in the same server environment that production code runs in.
Using more powerful hardware.
Accessing the same development environment from any machine.
In addition to those advantages, Codespaces has a new trick up it’s sleeve: Automatically setting up development environments when a new codespace is created, by installing dependencies via Docker7. In other words, Codespaces brings the same automated configuration advantages to the development side that virtualization and containerization have already brought to the deployment side. Configuring development environments is surprisingly complex, and subtle differences between manually-configured development machines creates its own problems.
It remains to be seen whether reproducible development environments is enough of a draw to move more developers over to remote development, but it’s certainly a compelling solution to a real problem.
Finally, there’s another important trait about Codespaces: It works with locked-down devices, like iPads, which normally can’t download and execute source code due to App Store Review Guideline 2.5.2. It also doesn’t require source code to be checked out locally, which many companies already consider a big security risk. These advantages will likely make some developers uncomfortable, those that see current computing trends as the gradual erosion of user freedoms, but the purpose of this piece is to predict the impact Codespaces will have on the development process, and that it aligns well with both the direction some devices are going, and many company’s security goals, are both important traits to consider.
Remote Development in Practice
Codespaces creates a fairly convincing illusion of working locally8. This is especially true when using the VS Code app with the Codespaces extension. Performing tasks like editing text, project-wide find-and-replace, or file management in the Explorer don’t exhibit any major differences from editing files locally.
One of VS Code’s best tricks is automatically forwarding ports for URLs printed in the console when connected to a remote machine. If, for example, a server process prints 127.0.0.1:3000 (because it’s running on port 3000) then port 3000 is automatically be forwarded to your local machine. You can then open that URL in a local browser window (or just ⌘-click the URL in the console), just like you would be able to if the server process were running locally9. This is another example of how VS Code creates the illusion of working locally.
But there are some situations where the illusion breaks down. Developing offline is obviously no longer an option. Another example is that when developing remotely, VS Code becomes the only easy way to edit files. If you want to edit a bitmap in Photoshop, or open a CSV file in Excel, you’ll have to figure out another way of doing so.
The vastness of VS Code’s ecosystem is an interesting tangent to explore from the limitation of not only being able to edit files with anything besides VS Code. There are extensions for tasks like editing raster graphics, a Draw.io editor for diagrams, and a tabular data viewer. If you squint, VS Code starts to look more like a general purpose platform, rather than just a text editor. The fact that this platform provides in many ways a better experience than say, VNC, is quite powerful10.
Setting up and tearing down development environments at will, which Codespaces encourages, also has its downsides. If your development environment requires installing a lot of additional tools, such as compilers, linters, and other shell tools, then those tools will all need to be installed each time you create a new codespace. While Codespaces’ dotfiles support can automate this, having more dependencies will make it take longer to spin up a new codespace.
Finally, the last issue I observed while using Codespaces is that each project being in its own codespace makes it harder to make changes spanning multiple projects. This comes up when performing maintenance tasks (like updating continuous integration settings for several projects at once), making changes that span multiple projects (like many an API change and then updating consumers of that API), or even just trying to search through several projects to find a piece of code I know I’ve already written, but I don’t know where. These are all problems where organizing projects in the file-system hierarchy makes it easier to work on several related projects at once. But with Codespaces, every project is an island11.
It’s also worth mentioning that there are many types of development that Codespaces isn’t applicable for at all. Anything that needs access to local hardware, like mobile development, is obviously going to be out. The biggest audience for Codespaces is web developers (which not coincidentally, is the biggest audience of VS Code itself). Web development is a natural fit for remote development, since the deployment target of the project is also remote.
Conclusion
Codespaces provides enough utility that I suspect it will find its way into many, if not most, developers’ workflows. Just being able to open a Codespace to quickly explore, or make contributions to, a repository seems like enough to make it popular on its own. Not to mention being able to quickly edit a project from a machine that hasn’t been setup for development12. But the question I find the most interesting is whether Codespaces also has the potential to replace local development entirely, at least for some kinds of developer (those that aren’t deploying to local hardware).
I don’t expect Codespaces to win over many longtime developers, who already have sophisticated development environments setup, since Codespaces’ biggest gains come from initially setting up those environments13. The real benefit from Codespaces comes from never having to setup those local development environments in the first place, ever, over the course of a career. So what will be more interesting to watch is when new developers join projects. Without Codespaces, their first task would be to setup their development environment. With Codespaces, they can just click a button and start coding. Will developers who start working this way ever get around to setting up local development environments?14
The continued relevance of the Mac Pro is an example of how relevant powerful, on premises, hardware still is. ↩︎
Since Codespaces is still in beta, we’re not going to spend any time reviewing bugs or incomplete features, which might be fixed before release. This piece is about the full promise of Codespaces and remote development when it’s finished. ↩︎
Compute usage is billed per hour, at a rate that depends on your codespace’s instance type. During the beta, Codespaces offers a single, Linux instance type. At general availability, we’ll support three Linux instance types.
It remains to be seen whether these features can be added without compromising the one-click experience. ↩︎
At least one important feature was lost in the transition from Visual Studio Codespaces to GitHub Codespaces: self-hosted codespaces (which appears to be the most requested feature on the Codespaces Beta forum). In a way, it’s not surprising that it was removed, self-hosted codespaces fit more naturally into the Visual Studio Codespaces world (why not just let users swap the underlying Azure instance with their own hardware?), than they do into the GitHub Codespaces world (if a codespace is an extension of a repository on GitHub, how does using your own server make sense?). ↩︎
Earlier in the beta, Codespaces was in the main GitHub navigation along the top (i.e., alongside “Pull Requests”, “Issues”, “Marketplace”, and “Explore”), I wonder why it was removed from there? ↩︎
On macOS, the difference that jumps out between running Codespaces in the browser vs. the desktop app, is that some shortcuts that normally go straight to VS Code are instead interpreted by the browser. For example ⌘W, which closes the current split or tab, instead closes the entire browser tab. ↩︎
In addition to installing a projects development dependencies, codespaces can also be personalized by installing dotfiles. ↩︎
Emacs’ Tramp Mode is also known for creating the illusion of working locally when editing remote files. ↩︎
VS Code’s port forwarding also works well with launch configurations. A launch configuration can be setup where hitting F5 (for Debug: Start Debugging) launches the server and navigates to it in your browser, and this launch configuration will work regardless of whether your project is running locally or on a remote server. ↩︎
VNC works by sending a video feed from the server to the client (and forwarding keyboard and mouse events to the server), whereas with VS Code the client is actually running the front-end code. VS Code’s approach seems better to me, and it fixes the most glaring problem with VNC today: Video compression artifacts. ↩︎
I’ve stopped using Codespaces for my own projects. My development environment is quite elaborate (e.g., I install many shell utilities), and I also like having all of my projects organized together on the same file system, so I can do searches or make edits across related projects. Neither of these are a good fit for Codespaces.
But I have found I like some of the benefits of remote development. In particular, it’s nice to not have to use local hard drive space for things like npm modules, especially for smaller projects. So instead of Codespaces, I’ve been using Microsoft’s Remote SSH extension, with a VPS. This provides some of the benefits of Codespaces, while working more seamlessly with my workflow. This approach also forgoes some of Codespaces’ major selling points, like automatically setting up new development environments, and, perhaps most notably, web access via browser (it should be possible to add web access using code-server, if I ever decide I need it). ↩︎
Software automation is the alignment of intention and action.
You should be able to take one action to perform your intention.
And ideally, that action is configurable, e.g., you can either select a menu item, press a button, or perform a keyboard shortcut.
Codespaces takes what’s normally multi-step process, e.g., checking out the source code and then setting up a development environment, and turns it into a single action: Creating an environment for running and editing a project. Codespaces similarly optimizes finishing with a project. Normally, when you finish with a project, you might just delete the source, but this would still leave around any dependencies that were installed globally. When you remove a codespace, all of its dependencies are automatically removed with it.
With Codespaces, intention and action are aligned. The single action of creating or removing a codespace accomplishes the intent of creating a working development environment or completely removing it. ↩︎
Codespaces also presents a future for development that’s compatible with locked-down devices (e.g., iPads). I once thought creative professionals, like programmers, would eventually end up working on locked-down devices (defined here as a system that can only run sandboxed apps, but I no longer think that’s the case. ↩︎
The comparison of Replit to Codespaces is that Codespaces takes existing development workflows, and works backwards to figuring out how to make it as easy as possible for new developers to join projects. Whereas Replit asks what if development prioritized making it as easy as possible for new developers to start coding from the beginning? Both of these seem like valid approaches, and will likely end up serving different segments of the market. ↩︎
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.
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:
Popularity: It’s crossed a popularity threshold that no earlier text editor in recent history has crossed.
The Text Editor as Platform: It’s the endgame of a revolution that saw text editors be remade around extensions.
Paradigm Transcendence: It’s transcended its paradigm as a desktop app by becoming a hosted web app, and even a reference implementation.
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
(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 (keyboard shortcuts that were popularized by the original Macintosh and Windows 1.0, released in 1984 and 1985 respectively). 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 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, someextensions 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:
Here’s a graph of the number of years between stable major releases (contrasted with the release dates for BBEdit 10–13 for comparison):
A couple things jump out from this graph immediately:
TextMate 2 took a long time.
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 was released in 2012, and hasn’t been updated since, 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
Atom 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:
It’s crossed a popularity threshold that’s eluded other text editors by being used by over 50% of developers.
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.
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.) ↩︎
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 severalpopularports. 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. ↩︎
For some reason Stack Overflow removed the questions about developer tools like text editors for the 2020 survey unfortunately. ↩︎
The progression of text editors becoming a platform is adapted from a previous post, which is in turn adapted from a Twitter thread. ↩︎
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.) ↩︎
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. ↩︎
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. ↩︎
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? ↩︎
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. ↩︎
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.
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.
These features have all since been built-in to every subsequent popular text editor. In addition, the scope selectors and theming implementation that TextMate pioneered form the basis of themes, syntax highlighting, and scoping language-specific functionality in every subsequent popular text editor.
That’s already an impressive list of features to all stem from a single app, especially one that entered an already mature category, and we haven’t even gotten to TextMate’s greatest influence: TextMate was the first popular text editor to be built around extensions. It’s this change that would entirely re-shaped text editor market forever, solidify the niche status of every text editor that came before it, and pave the way for the eventual dominance of Visual Studio Code, more than a decade later. Based on how subsequent text editors have all been built around TextMate’s use of extensions, it’s fair to call Sublime Text, Atom, and VS Code, “TextMate-likes”.
Gus Mueller has my favorite take on the news that Apple plans to announce the transition to their own ARM chips at WWDC. Of the various predictions people are throwing around, the only one Mueller gives any credence to is the prospect that ARM Macs will only running sandboxed apps1:
Assertion: ARM Macs will only allow sandboxed app.
This could happen. I give it a 50/50 shot at happening. Personally, I hope it doesn’t happen as there are still many problems with the sandbox on MacOS that have yet to be resolved, even though developers have been complaining about it for years.
Personally, I do not think that this is going to happen. In my overview of creative apps, I was stunned at how ineffectual sandboxed software has been. I keep a mental list of applications that aren’t sandboxed that the Mac absolutely cannot afford to lose, here’s the list2:
If the Mac were to lose everything on that list, then they lose the following groups:
3D Artists
Designers
Music Producers
Motion Graphics Artists
Photographers
Video Editors
For creative professionals, essentially the only remaining users would be the tiny subset of developers, music producers, and video editors that work exclusively in Xcode, Logic Pro, and Final Cut Pro respectively. A Mac cut down to just those users is a dead platform.
This is a short list. There are many more applications I suspect should be on this list, but these are all applications that I’m familiar enough with both the application itself, and more importantly, the community around it, to know that people would rather move to another platform, then lose the application. ↩︎
We are in danger of losing one application from this list either way: Blender. As Mueller states:
Assertion: OpenGL is going away on ARM for MacOS.
Yea, this is totally happening. OpenGL and OpenCL have been deprecated for a while now in favor of Metal. Apple will use this opportunity to drop them.
My understanding is that this means Blender would have to support Metal in order to run on new ARM Macs. I think there’s enough intertia in the Blender community to support Metal, if the alternative is to lose the Mac as a platform, but I’ll be worried about this until that actually happens. ↩︎
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.
The new Productions feature set for Premiere Pro was designed from the ground up with input from top filmmakers and Hollywood editorial teams. Early versions of the underlying technology were battle-tested on recent films such as “Terminator: Dark Fate” and “Dolemite is My Name.” Special builds of Premiere Pro with Productions are being used now in editorial on films like David Fincher’s “MANK.”
When Apple pushed FCP to the industry pros five or six years ago, they did some hardcore outreach. They brought out Walter Murch, for God’s sake. The man cut Cold Mountain on it for God’s sake.
Versus Adobe Team Projects
Adobe already has an existing feature for video collaboration called Adobe Team Projects, that’s designed around a cloud workflow, Bedient describes the difference:
Productions is designed for collaborators working on shared local storage. Team Projects is built for remote collaboration: assets can be stored locally with individual users; project files are securely stored in Creative Cloud. The two toolsets are distinct and currently cannot be combined. Productions is part of Premiere Pro and is included with all licenses. Team Projects is part of Team and Enterprise licenses for Premiere Pro and After Effects. In order to support users working from home due to COVID-19, Adobe is making Team Projects available to all users from April 14 through August 17, 2020. See this post for more information.
Collaboration & the Future of Creative Apps
Collaboration is the word of the day, and it’s great to see Adobe taking it seriously, especially with a vision that isn’t web-based. The web is the platform that makes collaboration the most straight-forward, the easiest way to share something is through a URL, but a web app isn’t necessarily the best trade-off for all use cases.
The question at the heart of Figma’s success is whether it winning the user-interface design market means web apps are also destined to win other creative markets which have otherwise been the stalwarts of desktop native apps. But another way of looking at it is that the native app they are competing with, Sketch, was doubly harmed by Apple’s policies:
It’s built on AppKit, which Apple was aggressively enhancing in the 2000s for high-end desktop apps but since the 2010s they’ve switched to focusing on frameworks that benefit iOS. This essentially means the platform Sketch is built on has spent a decade stagnating.
As software for professional creative users, Sketch isn’t compatible with the Mac App Store, this means they’ve been denied access to the most important promotion channel for Apple platforms.
Figma may have only been able to succeed because Sketch was built on a platform that’s at best indifferent to their use case, and at worst actively hostile to it. That’s a big difference compared to the cross-platform native desktop apps that are still relevant: Microsoft will fight tooth and nail to make sure Microsoft Office stays relevant, and Adobe will do the same with Adobe Creative Cloud.
Pre-2004:BBEdit, Emacs, and Vim are all great text editors in their own right, but all have idiosyncrasies that, while beloved by people like me, prevent them from ever being the most popular text editor.
2004:TextMate is released, with its focus on packages to extend the editor and add support for different programming languages, but its API is still too limited to truly be a platform.
2008:Sublime Text is released, with a more sophisticated API, facilitating more powerful packages, but package management is still an afterthought.
2014:Atom is released, bringing package management to the forefront, but Atom has performance problems.
2015: Visual Studio Code is released, keeping packages front and center while also solving Atom’s performance issues. As far as I can tell, this essentially represents the final form for (mainstream) text editors.
I don’t see how VSCode can ever being contested again, unless its team makes a grave strategic error. We’ve seen over and over again, that once a platform takes off, its momentum creates a moat that’s almost impossible for challengers to overcome.
Zapier releases a new tool for annotating screenshots called Zappy, in the tradition of Skitch, and, my favorite, the unfortunately discontinued Napkin.
I’m fascinated by this problem, it seems so simple on the surface: Just share what I’m looking at on the screen and be able to mark it up. But this problem is wonderfully devious in ways that emphasize our expectations when using computers. For example, once something is digital, we expect it be perfect. A poorly-drawn digital line is somehow worse than the same line drawn on a whiteboard.
Consider editing text, one of the first things a new computer user learns, and almost immediately they can produce pixel-perfect text every time. The comparative skill for just editing a line, is a Bezier curve tool like the one found in Adobe Illustrator, which is extraordinarily difficult to master by comparison.
Sharing an annotated screenshot brings out two truths about computers:
We expect digital artifacts to be perfect.
Editing anything graphical with a computer is very hard to master.
Eclipse Theia is an extensible platform to develop multi-language Cloud & Desktop IDEs with state-of-the-art web technologies.
The screenshots look just like Visual Studio Code, and it supports VS Code extensions:
We believe VS Code is an excellent product. That is why Theia embraces many of the design decisions and even directly supports VS Code extensions.
As to distinctions from VS Code, as previously mentioned it’s designed as both a desktop and cloud IDE, there’s some details about what exactly that means in the Architecture Overview:
The frontend process represents the client and renders the UI. In the browser, it simply runs in the rendering loop, while in Electron it runs in an Electron Window, which basically is a browser with additional Electron and Node.js APIs. Therefore, any frontend code may assume browser as a platform but not Node.js.
I’m curious what benefits this entails in practice over using VS Code with the open-source code-server.
Another major component is the Open VSX Registry, which is described in a The DEV Community post as “an open-source implementation of a VS Code extension registry that we have developed under the umbrella of the Eclipse Foundation” with the rational being:
Unfortunately, Microsoft prohibits non-Visual Studio products from installing any binaries downloaded from their marketplace (see terms).
Acorn grew out of upgrades to another app of mine, FlySketch, designed for screen capture and sketching. Customers asked for new features, I started adding brushes and layers and multiple windows, and all of a sudden I had a full-blown image editor. But Acorn still serves different needs than professional-level editors. Acorn is powerful, but nimble and approachable. It also has excellent documentation that we’ve worked hard on for years.
Unlike most browser-based email, which is server-based, Superhuman can store and index gigabytes of email in the web browser itself. This is possible by leveraging today’s more powerful APIs in the browser, along with the faster CPUs and hard drives on our computers.
The Omni Group’s 2020 roadmap has a great section on automation that’s worth reading in its entirety. It covers both their future plans for their own apps, and a declaration of why automation is important in general:
By providing automation technology in our apps, we make it possible for customers to extend our apps’ capabilities. People can build customized solutions to meet their own needs—and then share those solutions with others. We had thousands of customers using Kinkless GTD in OmniOutliner, even though most of those customers didn’t know AppleScript. I’ve been told that one of JTech Communications’ most popular blog posts was for a script for OmniGraffle which counts items on a canvas. With automation, people are able to create their own keyboard shortcuts to quickly perform actions like creating a task calendar from OmniFocus, or exporting Markdown from OmniOutliner—and those solutions can often be shared with others, making everyone’s lives easier.
The Omni Group is apparently going through some hard times, bless them for taking automation so seriously in their apps.
There are a couple of interesting products to look at for the future of creative apps: The first is Figma, the first-ever web app to gain traction with creative professionals, another is Lightroom CC, Adobe’s newer alternative to Lightroom Classic. Lightroom Classic is the same application Adobe has been shipping since 2007, it has more powerful features1, in particular fine-grained control over how your image files are managed on disk. Lightroom CC is a newer alternative, and it’s the only version available on mobile. Lightroom CC has no control at all over your image files (“the era of the file is over”—Scott Belsky, Chief Product Officer at Adobe). Instead, all of your image files are synced to Adobe Creative Cloud. While it’s still behind Sketch, Figma has clearly been a resounding success with professionals. It’s harder to gauge how successful Lightroom CC has been, on one hand, it’s not marketed to professionals to begin with, but on the other, it’s hard to interpret Adobe’s choice of the word “Classic” in the name as anything other than an attempt to drive users to the newer app.
So how’s that going? Jenn Mishra recently wrote an article about sticking with Lightroom Classic for PetaPixel. Looking at the comments, this article received a hundred of them before the comment limit kicked in, and there’s only one comment that’s positive about Lightroom CC: It’s easy to find, it’s at the bottom, with the most downvotes.
The reason why I use it is that I’m used to it. I used Final Cut Pro from the very beginning of my career. For now — regarding sound mix and the workflow — it’s really simple to use. However, I haven’t been able to update my OS for four years.
BushelScript is an open-source AppleScript alternative:
BushelScript is open-source and community-driven, meaning it can undergo necessary changes and gain useful features rather than remain stagnant as a side project on life support.
The real tragedy of AppleScript is not its becoming obsolete or irrelevant; tons of Apple-supported macOS apps still have healthy scripting interfaces. No, the tragedy is that the language through which such functionality is presented, with all its quirks and weak points and even utter failures, is extremely unlikely to receive any badly needed improvements in the future, if any changes at all. It is stuck in maintenance (read: bugfix and security hole-filling) mode and will be for years to come if we, the users, don’t replace it with something better whose fate we can control.
