The future of cloud development is editor neutral

Kyle Carberry

 on June 4th, 2021

Updated on June 23rd, 2021

7 min read

At Coder, we believe that the future of cloud development is editor neutral.

But before we talk about the future, let’s spend a few moments thinking about the past and how we got to where we are.

A quick timeline of editors

Here is a quick and highly selective timeline of editors used by developers and when they were first released.

These editors have a few things in common. First, I’ve used them all at one time or another. That’s not particularly relevant to our topic today, but there it is. Second, with the exception of VS Code they are all twenty years old or older. And third, and most interesting, they all still have at least a 10% market share to this day.

From the above, we can easily jump to two conclusions: 1. Building a good, new editor is really difficult and doesn’t happen often 2. Developers generally don’t like to switch editors

From my own experience, both of those are true.

A missing piece — the Coder IDE

I deliberately left one particular editor out of the timeline, and that is the Coder IDE. Now, this is not a product pitch, but indulge me for a moment.

We launched the Coder IDE in 2018. It was our first product as a new company. Users could visit coder.com and we would give them a cloud development environment that launched in under a second, had real-time collaboration, supported for VS Code extensions, and could burst to 96 cores.

Sounds great, right? So why did I not include it in the timeline?

It no longer exists. It failed to gain the kind of traction that was needed to keep it going, so we shut it down. Lots of people tried it out and thought that it was cool and even tweeted about how awesome it was. But when it came time for them to get to work on a real project, they didn’t use it. They went back to what they were doing before.

What we realized in hindsight was that while we thought it was a great product, it didn’t fit into the workflow that developers already used. Put another way, we tried to impose on developers our own ideas for the best workflow rather than trusting developers to make the choices about what worked best for them.

We also realized that we were simply trying to do too many things at once. We were trying to host people's computers for them. We were trying to build our custom editor. And we were also just trying to get people to work on remote servers, which in itself has proven to be a challenge.

In short, we were trying to boil the ocean.

Pivoting — learning the importance of choice

We knew that being able to code remotely was a need for a lot of developers, including ourselves. We also knew that the Coder IDE had tried to meet that need but failed. So that left us with two options:

• Wait for popular editors to support remote development
• Figure out how to enable developers to use popular editors remotely

We didn’t want to wait; we wanted to lead. Now fully realizing the importance of trusting the choices developers make for themselves, we set out to figure out if we could make the editor most frequently chosen by developers accessible through a browser.

So we started working on code-server, which lets you run VS Code on any machine and access it in the browser. This was before VS Code supported remote SSH or JetBrains Projector.

The first version of code-server was hacked together. I shimmed a lot of Electron into the web and shimmed in a ton of node modules that had no business being on the web at all. It wasn’t until version 1.36 that we felt comfortable launching it.

Like earlier, we had a lot of people try code-server and think it was really cool. But unlike with Coder IDE, they kept using it. It took off mostly by word of mouth. Soon thousands of developers were using it as part of their daily workflow. For the first time, developers were really choosing something remote without us having to push it onto them.

What made code-server a success, I believe, is that it's really just a small iteration on the workflow that people already love. It’s just VS Code in the browser. They already use VS Code. They sometimes need (or want) to work remotely, and so code-server meets that need while respecting the choices they have already made about what editor works best for them.

Developer choice & the future of cloud development

So if choice is important to developers, what are they free to choose when working for a company?

There are some things that they typically can’t choose:

❌ Operating System

❌ Software Stack

They can't choose their operating system, at least not all the time. They also can't generally pick their software stack or easily adjust it. If you join a company and they’ve been using Java for ten years, it's gonna be a really difficult thing for them to come in and say, “let's switch everything to Go.”

What they can typically choose though are:

✅ Editor

✅ Keybinds

✅ Terminal

I think it is safe to say that any successful cloud development platform will have to continue to allow developers to make their own choices for all of these. They will not willingly give up these abilities. Developers will expect to be able to use their favorite editor in a remote environment. They should be able to use VS Code in a browser, or VS Code through remote SSH, or IntelliJ, or Eclipse, or whatever. The platform must be editor neutral. It must also allow developers to use their terminal of choice and to set their own keybindings. That’s a minimum.

The move to cloud development also presents opportunities to empower developers, to honor their choices about their workflows in areas where they currently have little or no choice.

I use Linux and i3. I should be able to go from any OS to any OS. I want, for example, to be able to continue to work on Linux and develop an IOS app for Mac. Currently, that is not possible without some kind of crazy VNC stuff. But with cloud development platforms that becomes very possible. Now I can choose my own operating system.

Workspaces are getting much easier to template. I don't think this is a solved world by any means. There's a lot of iteration that still has be done, such as how will people actually be developing these templated workspaces in the cloud. But I feel like we can definitely say that developers will be able to get faster changes to the software stack. If you want to move from Java 7 to Java 8 it could be as simple as opening a PR for that.

So here’s what the future could look like for developer choice:

✅ Operating System

⚠️ Faster changes to the software stack

✅ Editor

✅ Keybinds

✅ Terminal

So I began with the assertion that the future of cloud development had to be editor neutral and explained why I believe that. But hopefully, it's much more empowering than just the editor itself. Hopefully, we're able to hit a lot more neutrality on the operating system and the software stack that organizations are able to iterate on.

That’s the future of cloud development as I see it, and it’s something we are working towards at Coder.

This post is a version of a presentation given at Cloud IDE Day 2021, hosted by the Eclipse Cloud DevTools Working Group, part of the Eclipse Foundation. You can watch the full presentation below.