NFS is still, for bigger projects, extremely slow in reads. I did several benchmarks and tested several projects like listed here https://github.com/EugenMayer/docker-sync/wiki/Alternatives-to-docker-sync#nfs and for projects like rails / symfony / drupal and other bigger stacks like spring (java) it becomes just as unusable as OSXFS.
NFS performing that bad was the reason i created the alternative https://docker-sync.io and to achieve the same 2-way transparent sync, we are working on unison+unox https://github.com/EugenMayer/docker-sync/pull/64
As you see, we have different strategies there, from rsync to unison one way, unison two way based on OSXFS (being blocked by Inotify events are not / stop working from host to container btw) and finally the current unison+unox standing out as the best solution. You can try and benchmark yourself to see the differences.
So bottom line, please do not suggest NFS as a “build in solution” i basically beg you. Its just too bad in read performance to consider it. For smaller projects the performance of NFS to OSXFS right now is even similar so OSXFS might be enough already. Since NFS is not suitable for bigger projects, choose something else like unison+unox, IMHO.