Working on remote server locally
Memoires of a developer.
This could sound weird, but should be strong as "think global, act local": `work on remote server, locally`.
Many programmers are using Mac, while some other developers are taking advantages of Linux latest technologies (such as Docker). Other people are just so old school, they still using the micro whatever and we have to respect that, if that works.
After trying a lots of interesting tools and ideas, starting with Virtualbox, Vagrant, Docker, in all available platforms and finishing with x2go client (from multiple platforms) to a linux server machine, then it was time to take a deep breath and take things slowly. First of all remember what we were looking for from the very beginning, working on remote server locally, which proved to be the answer key to all of the problems (or at least the important ones).
X2go works actually well for those minutes before completely freezing (with xrender set to true) and that makes it a hard thing to leave or forget (see this BUG report for details about PHPStorm/Java applications), while on the other hand giving up on xrender makes it stable but unpleasantly very laggy.
If you work on a dedicated tasks/feature, the answer is related to number of files you need touch/edit/create, which is significantly very small in general.
For example docker-compose on Mac makes it extremely slow while using volumes to share entire project between Host and Guest. Magento 2.x projects without cache takes ages to load a page in a MacBook Pro 13-inch, Early 2015, even with the Flash SSD storage, while it acts naturally in a linux machine and were there is no difference between the system and the containers.
To have the natural look and feel we decided to separate the application server and the working environment and share only the piece of code (folders) we work on it (for example a single module directory). It means there is a server somewhere up and running with ssh access and xDebug configured for remote connection (acting as working environment server) and a machine where the editor is installed. In the editor we clone the project repository and we mount for example the module folder where we want to develop the new feature via sshfs.
This feels naturally in host machine and also feels naturally in guest system. Once the feature is developed, the changes can be committed, deployed (from any machine host/guest), the folder shared is unmounted and then, the project can be checkout to the latest committed version. The step could be repeated for any new future/bugfix.
You basically have the power of the linux server (which you can close when is not used) at the comfort of your operating system and tools.
This could not be more convenient than that!