It baffles me when engineers are using VMs and clusters provisioned on cloud providers for tasks where their powerhouse laptops (mostly the latest Apple Silicon ones with 64G+ memory) would be just as fine, but faster, and much cheaper. Instead of this they are using their laptops as thin clients to ssh into much less reliable/performant machines.
I don't know if I would do it for web dev, but it's great for ML stuff to work on a massive machine.
Pitfalls maybe are leaving the VM on racking up $, I just made a crontab to shut it down at midnight. Some storage options are way more expensive for 100gb of storage (the extreme ssds) that aren't worth it. And I think the other is basic linux admin. Also making sure it's firewalled properly
I think it depend on the fruit. I mean a cloud has an advantage if the dev env were too complicated to use on each locals. On a local machine has enough spec to dev present. I had some 'pitfalles' on a clound, then I prefer a local than it.
The latency annoys me. The editor zed.dev might make this better (fast editor can connect to cloud ssh). Pick a backend in your region and it might be OK.
Depends on other things. Using Windows for example might make cloud more attractive as most dev work is done on linux. WSL is a bit sucky to use. And uses a lot of disk space and you need a decent amount of RAM for two operating systems.
On a fast mac you might prefer local unless the dependencies dont support M chips.
But the main pitfall will be latency and maybe cost and possibly not being able to work without internet.
I would say that you should replicate the environment your product will run as closely as possible.
So for a lot of us that means a web app of some kind running on a Linux server. The simplest way to reliably reproduce that regardless of the native OS on the workstation is with a Virtual Machine. A container based solution is a distinct possibility (if the host is already Linux) for a lot of workloads but that still introduces more potential for unexpected differences, because now it's sharing kernel that isn't necessarily what's on prod. I think if you're using system containers like LX{C,D} to simulate a regular server environment it's probably fine.
For those doing desktop app development, I assume VMs are more about testing procedures, but that regular daily development would just be "local" on the native OS.
Pitfalls maybe are leaving the VM on racking up $, I just made a crontab to shut it down at midnight. Some storage options are way more expensive for 100gb of storage (the extreme ssds) that aren't worth it. And I think the other is basic linux admin. Also making sure it's firewalled properly
I have used github.dev before, and they seemed decent.
(Tip if you didn't know, pressing '.' when in any github repository will spin up an in-browser VSCode editor for the repo)
Depends on other things. Using Windows for example might make cloud more attractive as most dev work is done on linux. WSL is a bit sucky to use. And uses a lot of disk space and you need a decent amount of RAM for two operating systems.
On a fast mac you might prefer local unless the dependencies dont support M chips.
But the main pitfall will be latency and maybe cost and possibly not being able to work without internet.
So for a lot of us that means a web app of some kind running on a Linux server. The simplest way to reliably reproduce that regardless of the native OS on the workstation is with a Virtual Machine. A container based solution is a distinct possibility (if the host is already Linux) for a lot of workloads but that still introduces more potential for unexpected differences, because now it's sharing kernel that isn't necessarily what's on prod. I think if you're using system containers like LX{C,D} to simulate a regular server environment it's probably fine.
For those doing desktop app development, I assume VMs are more about testing procedures, but that regular daily development would just be "local" on the native OS.