The End of Localhost
All the Cloud's A Staging Env, and All the Laptops Merely Clients

Search for a command to run...
All the Cloud's A Staging Env, and All the Laptops Merely Clients

Do all remote IDEs come with crap keybindings that are barely flexible? Can any be tuned to behave like emacs, with lisp helper functions, or is it all just bare minimum lowest common denominator MVP? And then when you change orgs, you have to get used to another barely thought out IDE that behaves completely differently?
I left my last job because you couldn't git push to the new security zone anymore, and instead had to operate through a VDI->VNC connection that had 1 second latencies (try paging through a logfile in less in an xterm in that!), and had bad jpeg artifacting (red text on a dark background? Good luck with that!) and horrendous rendering errors (move a block of text and have it duplicated all over the screen).
This is an extremely well researched, thought-out, and written article kudos swyx.
If take Shopify's cloud dev journey article as a guide: This is a rather abstract discussion on vs code remote container dev env via kubernetes pods managed by an org on a cloud with standardized images which can be customized with yml. Instead of customizing the remote container Dockerfile manually, the dev user adds the dependency to the configuration file and it is written automatically into the script to create the environment.
Once inside the container (the user's virtual machine environment), user can leverage docker-compose.yml to orchestrate his microservices.
But at the end of the day, the kubernetes part of it is irrelevant to the developer. It is mere infrastructure for hosting a workspace which is configurable by people familiar with the matter. Orchestrating microservices and scaling them is obviously 2 different things. We don't need kubectl to network containers. We can open a port with environmental variables in a docker-compose.yml file. For development of course.
as a footnote i think okteto dev environment encapsulates all of that pretty well.
ps. i would like to characterize customizable, but standardized remote container dev as 'environment as a service' (EAAS)
This is brilliant. Insightful, entertaining and strange. But most of all brilliant. I'm an instant fan.
This is my biggest fear. On the surface, moving development entirely to the cloud makes life easier.
But in reality this also makes it harder for newer generations to understand how computers work.
Let's not pretend that, when all dev tools are moved to a machine on the cloud, these company laptops, as "mere clients", will give their "owners"/users root access, or even file system access to the laptop itself. To protect the security of such a centralized cloud, every terminal would probably be as secure as iOS.
How do you train the next gen DevOps and OSDev using such lobotomized computers?
Consider for a moment, you are a young aspiring computer science student, and all the classes only teach you how to use these jailed devices to write only code you are allowed to write. Would you still have been inspired to become a developer? I wouldn't. Without my love in Linux and kernel customization, I wouldn't have ever picked this major.
What's most likely going to happen, is that OSDev and DevOps become arcane arts that can only be learnt by offsprings of the professionals who had access to such internals of the cloud.
Let's hope this doesn't lead to Tech Monarchy.
EDIT: On a side note, this is proof that purely technical decisions can have serious political consequences. And I weep for our future as our politicians struggle to understand what our developers are forbidden to explain, under NDAs.
If you are playing with hardware or hardware specific optimizations and need precise control of your environment for testing, you need your own box and often a cable to connect you if you are playing with hardware directly.
About the "coding on a plane": We can also look into the future from this aspect. We have started to see more and more planes having wifi available on it with a price range from $10 - $30. Almost all international flights have wifi based on my experience. I can see within 5 years, it will be standard for all airlines and the price will only go down.
To share my experience: I was coding on planes from New York to Paris last week and I was coding on the plane while using our cloud-based environment. Since my devserver was in the US, I can definitely feel the latency while flying across the Atlantic ocean while running commands on my terminal. Still, I feel no latency while coding on VSCode thanks to the caching/buffering. So the majority of the time, the experience was acceptable. Plus, there was no distraction, and I was very productive.
On the other hand, I can see the hybrid solutions in the near future. You can code in a cloud-based environment but when you need it, you should be able to replicate a module or the entire environment to your local for your own reason as long as your hardware can support it.
I'm also using remote environments on some of my projects because they need a lot of power (browser automation) and bandwidth.
I'm a bit curious: what's your configuration for remote development ?
I personally use the VSCode Remote - SSH (and remote containers with a remote docker host).
I feel you! My laptop has been very cool and the battery life has never been better haha.
I am using my own product, Nimbus. You should be able to find it by google usenimbus. Feel free to take a look :) Happy to take some feedback. Camille Louédoc-Eyriès
Interesting one 👌🏻
swyx here: I recently hosted the inaugural AI Engineer Europe and Matt Pocock was a standout speaker, crossing 1m views across talks and workshops in <2 weeks. I asked him to write a post on how he sp
Thariq Shihipar's (Anthropic, Claude Code) Devrel/Writing Process — building implicit knowledge and then making it explicit.
It was a pleasure to rejoin Jack Bridger for a third time on Scaling Devtools, where I usually try to cram as much devrel metathoughts per minute as I can. Nominally the pod was about how DevRel is So Back, but informally I’ve been sharing a bunch of...
How to create extraordinary dev videos by going against the grain

and we're not sure why
Dev environments should be cattle, not pets. It looks likely that in future, most development will not be done on localhost, the most precious pet of all.
See reactions on Hacker News and Twitter.
Aug 2022 update: I did an extended interview on InfoQ with Daniel Bryant!
Sep 2022 update: I did an interview with Richard McManus of The New Stack!
Make the ultimate developer experience wishlist for the average rich-country developer in 2030:
You will notice that most of these items enable (even require) you to run things "live" on the cloud, not localhost.
Perhaps most importantly, the time wasted fixing bugs between dev and prod environments goes from 1-4 hours a week down to 0, if you can simply eliminate the discrepancy between dev and prod.
Aside: Realistically, you will always have some discrepancy between "staging" and production environments, but the distance between them should be much smaller than between dev and prod. For example, working on
httpsis always a pain inlocalhostbut is a requirement on prod.
To paraphrase Bob Metcalfe, if the browser reduced operating systems to "a poorly debugged set of device drivers", then the cloud is reducing the dev machine to a poorly maintained set of environment mocks.

That's it, that's the blogpost. The rest of this article is working out subpoints, examples, trends, and anecdata.
Maybe stop flying so much. Or get a good audiobook and rest your eyes. Maybe even talk to your neighbor! (if they seem social)
Many Bigcos who have invested in their developer productivity already work entirely in the cloud. This will be news to some of you, and old hat to others, so I didn't know how much emphasis to place on this.
But to my knowledge, this is the first time anyone has collected public info about Bigco dev environments in one place:
The standard response to bringing up a bunch of Bigcos is "sure, but does it work for my small team?"
The answer is invariably "maybe yes, but also probably not in this current form", because most of these moves were done after sizable internal investment and take advantage of lots of proprietary infrastructure. However, as this tech commoditizes, we'll see more and more of it spread out as we find commonalities among audience subsets.
The obvious first part of commoditizing preview environments has already been done - one of Netlify's early innovations was making deploy previews for frontend projects ubiquitous. Virtually every docs site now uses some form of deploy preview system, and Jamstack apps can also use them for their release process (example). With database branching becoming increasingly common, this workflow will make its way further and further up the stack. Let's look at this stack next...
In my original tweet calling out this trend I actually conflated different usages of local development (as Anil Dash observed):
Conveniently, they are all under attack (did i miss any? please let me know):
So no matter what you're doing in localhost, there's probably a well-funded startup or Amazon/Microsoft tool that does it better in the cloud.
One of the ironic tensions of humanity is that we say we want free will, privacy, self sufficiency and decentralization, but our actions tend toward the hive mind, convenience, interdependence and central infrastructure. My theory for this is that social psychology, economics and technology are very powerful centralizing forces.
To argue against localhost eventually going the way of the Dodo is to do the developer equivalent of asserting that most people want to run their own generators or grow their own food.
You might argue that developers take so much pride in their tools that they will go out of their way to be self sufficient in them. And yet:
I will grant that there's a difference between "We use CircleCI" and "Let's kill localhost". The term of art the industry has adopted to describe this difference in dev tooling is the Dev "Outer Loop" vs "Inner Loop" - the Outer Loop taking the git commit as the atomic unit of developer productivity, and the Inner Loop being all the developer activity that happens between commits.

So, to use those terms - we're fine with the cloud taking the slow Outer Loop, but people are concerned about network latency affecting the much faster Inner Loop.
The degree to which the cloud can eat the Inner Loop is probably a question of reliability and latency - we are more than happy to hand over slow activities that take minutes, but nobody will tolerate 300ms latencies to see the result of a keystroke.
Aside: It's probably worth a future essay breaking down the various components of the Inner Loop, as there are orders of magnitude differences in the latency of various activities we undertake and so different ideal solutions for each.
Ultralow latency is the domain of edge compute, and likely the final frontier of how the cloud can eat that "last mile" of the developer Inner Loop.
Anil Dash, CEO of Glitch, put it best:
I think it’s more likely the rise of tech like CRDTs & edge compute will blur the lines of what we actually think of as “local”.
Cloudflare folks working on Cloudflare workers also agree:
"wrangler dev" actually runs the worker on the edge, and we use localhost as a proxy. it means you have access to resources/secrets from your real environment, and we implement copy-on-write on stuff like durable objects that gets discarded once your shut down your session
While not as low-latency, serverless folks like Tim Wagner (creator of AWS Lambda), Emrah Samdan (PM @ Serverless.com), and Tudor Golubenco (CTO Xata) also have a lot of sympathy with this because of how easy it is to provision/scale serverless resources.
Don't get overexcited here. My caution on judging this movement with today's technology is that for this to succeed, provisioning must feel so cheap as to be "throwaway" - even a latency of 10 seconds to spin up a preview environment is too long for me, though your mileage may vary.
It takes a second to deploy a frontend preview with Netlify Drop and ~10 seconds with the Netlify CLI, but I still habitually use localhost for development because my iteration cycle is in milliseconds. I can and have moved part of that workflow to remote tools like Codesandbox, Gitpod and Stackblitz, but none of them are fully capable of replicating the full set of dependencies that I need for fullstack development. In fact, after one particularly bad livestream, I resolved to always use Netlify Dev (the Netlify local dev solution I used to work on) because the iteration loop of git-push-and-wait-for-deploy was so agonizingly slow (I had the same pain with AWS Amplify).
Other similar sentiments:
Localhost has been attempted to be killed for eons, until the network is as fast as my disk, and can the “remoteness” of it can disappear entirely, localhost is here to stay. (tweet)
Currently we have local development with impossible physics: assets that load immediately, APIs that respond in under a millisecond. So if dev goes to the cloud because the latency is acceptable, then we are finding a middle point that is acceptable for both devs and real users. (tweet)
But surely you can see that the latency question is a question of letting the Moore's law equivalent of cloud commoditizing infrastructure take its course. If it's not good enough today, then wait 5 years and check back again.
People have very extreme:
Kelsey Hightower tries to explain it:
Dan Abramov predicted this happens in 5 years, not 10.
Simon Willison points out another benefit:
The killer feature of remote dev environments is when you mess something up in your environment and you can click a button and wait a few seconds and get a brand new environment that works
Paul Biggar sees a few drivers:
- production is harder and harder to replicate locally
- it's cheaper to pay for cloud dev machines than expensive laptops each year
services with high scale (eg Spanner) don't behave the same on localhost anyway - you just have an emulator
Pretty sure we're going to do fewer things locally and a lot more developing directly against the cloud in the future
Patrick Mckenzie says:
It seems to me like all the bits needed to do this are already abundantly available and it’s waiting for a) one solid product team and, crucially, b) becoming The Right Way To Do It for one language/platform that rockets to mainstream success.
You’d want the “curl dockerinthecloudlets.go” to be the first line in all the tutorials and for that to be the last time users ever think about compute substrate or networking.