One of Warp’s investors asked for my thoughts on the cloud development environment space. It was a fun question to think about (and is relevant to Warp as well), so I wrote up my thoughts. I could be totally off, but thought it would be fun to share them for feedback.
The high-level summary is that I think that development environments will eventually move to the cloud, but the incentives aren’t as strong as they are in other domains. I think top-down adoption is more likely than bottom-up in this case, but it will depend on the stack and developer segment, and take a longish time.
I remember the first time I used a Google Sheet in 2006 where there were multiple collaborators moving around its cells in real-time. The experience was magical, and it was pretty obvious that it represented the future of how document collaboration would work. Everything would be shared via link, with one cloud-based source of truth that multiple people could work on together.
Fast-forward 16 years (eight of which I happened to spend helping build the current version of Google Sheets), and numerous other products have made the same transition from local, single-user desktop software to cloud-based collaboration. The transition of design software from Sketch to Figma is a good example.
However, there has been one very notable exception to the general trend – the primary tools that developers use to write and run code. The code editor and the terminal, two tools that literally every developer uses every day – have both been very slow to make the transition off of said developers’ laptops and into the cloud. Why is that?
This post explores why what seems at first to be such an obvious evolution is actually much harder than it seems. I believe we will eventually write most of our code in the cloud, but I think it will be a slow, uneven transition. Certain segments of developers and stacks will move to the cloud before others and it will take a long time for everyone to get there.
First though - what does it even mean for developer tools to move to the cloud? It could mean a couple different things:
Of the two ways of doing remote dev (IDE in the browser or DevBox), there are tradeoffs amongst the two.
The IDE in the browser has the advantage of not requiring any setup, installation, etc. It’s great for getting going quickly on new projects.
But to the extent that it requires an entire team to use the same code editor, it’s problematic. Even though VSCode has a big market share, a lot of devs still prefer other editors like jetbrains or terminal editors like vim. Sometimes you need to use a different editor because of the type of work you are doing (e.g. xcode / android studio).
Whatever the specifics end up being, the advantages of a cloud setup are pretty clear:
Conversely, remote development comes with some inherent challenges to overcome:
Notably, the biggest single advantage that an app like Google Sheets brings to the knowledge worker – solving version skew and creating a system of record – isn’t really an incentive for development environments to make the cloud transition.
Before apps like GDocs and GSheets, knowledge workers were constantly in the situation of sending around document attachments via email that were actually multiple versions of what conceptually was one document (think back to when you would “Save As…” and give your file a new name like important_doc_zach_1.xlx and your colleague would send you important_doc_lucy_2.xlx and so on). This caused a ton of wasted time and headache merging changes.
Avoiding version skew by having only one canonical version of the document is the killer collaborative feature of all of the online document editors, more so than even any of the flashier realtime features like multiple cursors.
Developers, however, solved the version skew problem years ago using a very different approach – distributed source control systems like git (and cvs, perforce, svn, mercurial etc). These systems obviate a lot of the benefit of multi-player cloud editing because they allow for asynchronous local change management in a way that never existed for an excel spreadsheet.
Plus, because developers typically work on text files (rather than binary document formats), merging changes is doable manually, even if it’s sometimes annoying.
Finally, this type of control is actually needed for source code – you need to be able to track every single change, merge, rebase, etc, whereas for spreadsheets the “always at head” model is generally good enough.
The existence of distributed version control makes the pull of remote dev environments much less strong than it otherwise would be. Without the “system of record” advantage, I’d contend that the pull of remote development to an individual developer simply isn’t that strong.
As an individual dev, here are some of the other reasons I might want to work in the cloud:
On the flip side, as a developer, I’m worried that the move to remote
As an aside, at Warp, there are a lot of things we talk about with respect to improving engineering productivity, but moving our env from local to the cloud never comes up (in fairness though, we are building a native Rust app).
The other way the migration to remote dev could conceivably happen is from a top-down company mandate, rather than from developers choosing individually that remote dev improves their experience. I believe this is how GitHub rolled out Codespaces internally.
However, this comes with its own set of challenges.
That said, I think the top-down approach is actually most likely because the benefit is potentially stronger for a company than an individual:
So I could imagine a CTO saying, “we are all switching to dev in the cloud – it may be a pain to start, but the long-term benefits to the company are worth it.”
My best-guess at how the transition will happen:
At some point Warp may have the feature of “make my local terminal setup run on a cloud box” – I think it’s an interesting onramp to cloud dev.
But it’s not our current focus – right now we are just trying to create the best possible single-user terminal and prove that the terminal can also be a Teams product – which ironically doesn’t require any particular stance on remote dev at all.