The End of Localhost

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.

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.

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)

pps. coding in the browser is garbage

This is brilliant. Insightful, entertaining and strange. But most of all brilliant. I'm an instant fan.

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.

Interesting one 👌🏻

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).