I manage the React team at Facebook. Only a couple of us have been on the team since before Dan, and I don’t think anyone resents his public persona. Quite to the contrary – Dan does a great job representing us. :)
At Facebook most of our thousands of web devs use Nuclide for remote editing on a repo with hundreds of thousands (or millions) of files and it works as advertised. We don’t use NFS though; all the repo checkouts are on disk on the remote machine.
I don’t understand what requires a web view here. You should be able to do anything another app can do (especially if you’re willing to write some custom native code, which I assume you are if you’re considering full native).
Yes, making the source easy to understand is definitely valuable (even if only for our own team's understanding).
I believe Django's "functionality/(API surface)" quotient is still much lower than React's, which means it's easier to make the source useful to a newcomer.
* Links to source: I use these frequently in other libraries, but I don't think this would be as useful for React, because we tend to have just a few functions each with a complicated implementation (vs programming stdlibs or other frameworks where many methods are on the order of 10-100 lines calling other public functions). Also our implementation isn't that easy to understand. I wonder if you had a particular use case in mind?
* Linked method names: Good idea.
* Version switcher: We've thought about this and will probably add it at some point.
Certainly there are downsides to any setup, but due to React Native's large ambitions I'm unsure if it could have ever been created by an independent community. There is a lot of work that goes into it and the abundant availability of complex real-world problems (to a greater extent than I've seen anywhere else) spurred by this setup pushes React Native to be a more capable project.
Most of the code is in the repo in React/Fabric/ and ReactCommon/fabric/ but unfortunately it's not runnable yet due to some missing dependencies that aren't currently in the open source repo.
This is a pretty unrealistic view of how big companies work. Engineers aren't fungible, and no one has been "pulled off" of React or React Native to anything like you suggest.
React is my full time job (I was also the #1 committer before joining FB) and no one is planning to abandon it. Even if Facebook company leadership decided for some reason to divest, React would live on with the support of its community similar to other projects without corporate backing.
Your plan of sharing business logic sounds good. We don't currently have any recommended way to share code between web and iOS/Android, although I'm hopeful we will at some point in the future.
It's not unheard of to have "sponsored" issues. In this case though, none of the commenters on that thread work at Facebook. It doesn't mean the issue won't be fixed if no one sponsors it but if you care about it getting fixed sooner, you can send in a fix yourself or sponsor someone else to do that work.