Another would be developing ARM code using native ARM toolchains on a SoC board.
My understanding is that much, if not all development at Google works like this. I don’t know their specific policy but a friend works on a similar project internally.
(The other ways of writing code aren't publicly mentioned yet in any talks or papers that I know of, so I'll leave that one alone)
From the 2016 ACM paper.
> Most developers access Piper through a system called Clients in the Cloud, or CitC, which consists of a cloud-based storage backend and a Linux-only FUSE file system. Developers see their workspaces as directories in the file system, including their changes overlaid on top of the full Piper repository
https://m-cacm.acm.org/magazines/2016/7/204032-why-google-st...
Why setup your codebase and all the dependencies to run locally on a laptop when you can just spin up an instance on a server that matches your production environment and remote into it to work?
1) I may not need to see the data itself during most (or all) of my dev loop, but just see any errors that are thrown.
2) Taken as risk mitigation, data temporarily cached in your browser is less risk than data permanently stored on your laptop, esp. when the threat you are mitigating is lost / stolen laptop.