Why remote development is the future
Recently, Shawn, better known as “swyx” by internet communities, posted an article called "The end of localhost". The article was shared on hackernews but seemed to fail to convince users to move from localhost to remote development environments.
The move off localhost comes with benefits, where many of which are only apparent once you cross a certain scale. That is why big companies like Google, Meta, Tesla, Palantir, Shopify, and GitHub have remote development, as swyx documents.
As a result, my opinion is that development on localhost would still be around for open source and small teams. Companies, on the other hand, are already doing remote development in some form or another. That investment into remote development will only increase.
Your stack is already partially remote
If you use AWS S3, or other proprietary cloud software, your working environment no longer operates within the confines of your computer. If one loses internet connection, work is most likely halted, even if everything else is on localhost. There are ways to work around such limitations, but they are not good investments for the following reasons:
- Replacements of cloud equivalent aren’t perfect clones, so your localhost and production environments will diverge even more
- It is cheaper to get access to the internet (e.g. inflight wifi / Starlink), than to maintain two similar stacks
- Scenarios, where an employee is offline, are rare, so you are unlikely to discover issues until it is too late
Remote development is a forcing function
To achieve remote development, your stack must be easy to replicate, and quick to spin up/down regularly. This forces teams to make sure that development and production environments are as similar as possible. Devops get more opportunities to deploy and discover issues.
Remote development unlocks new possibilities
When your development environment is easy to replicate and similar to production, here are a few examples of things you could do:
- Sharing of development environment for collaboration
- Run tests in parallel
- Share cached build artifacts
- Deploy previews for applications
- Keep the previous n deploys to find bugs
- Load testing
Onboarding on localhost doesn’t scale
If an employee can onboard and push to production in the first week, that sets an expectation and positive impression for the employee.
When your company is small, onboarding is simple. A new employee needs to clone the private repository, run some commands, and off to the races they go.
As you grow, more parts get added on, and everything gets more complicated. You can add scripts to automate the process, spin up containers to make sure services don’t conflict or diverge, and run k3s or minikube to mimic kubernetes on production, etc. But eventually, you will find yourself limited by the compute resource of a single computer.
At Meta, bringing the development environment up already takes time on a 128-core machine so one can imagine how long it would take on a typical laptop. Their software engineers onboard by submitting their first diff (Pull Request equivalent) on the first day. This would not be possible without remote development environments and hot dev instances.
Even if you are just a small team, moving development remote would reduce the friction needed to contribute. This is extremely beneficial for open source projects. Contributors can easily spin up an environment without mucking around build steps and risk polluting their environment.
But latency?
Humans are quite sensitive to latency, and the speed of light is an impossible barrier to overcome. However, as a user of VSCode Remote SSH for over a year, I have had no issues since the keystrokes are stored locally and then synced to remote.
With the advancement of more edge compute and faster internet, I believe this will be less of an issue as time passes.
Conclusion
At the current juncture, remote development is only starting to pick up steam. I believe it is inevitable as the benefits of a close-to-instant development environment are attractive enough to justify the cost and tradeoffs of a full localhost environment.