> With each framework or platform we develop with we need to adapt to the conventions. From back end work using frameworks like Rails and Elixir to native mobile projects each has it’s own way to hang together a project.
Some have their own way to hang together a project. Much of the React ecosystem is not so opinionated. A lot of JavaScript out there exists in codebases in a variety of languages and frameworks—Rails, PHP, Node... you name it. Modern JavaScript build tools reflect the need for script sources and build targets to reside anywhere based on what the site JavaScript is being used in. I'd say this historical influence is showing in React Native.
However, I also think this makes sense for React Native. It's possible it's getting introduced into apps which already have conventions based on the platform the app is for and the team writing it. It might not make sense for React Native to come up with a new set of conventions when you're working with multiple platforms and existing codebases.
> But the real value is in sharing code, maintaining projects and on boarding new members to a project team. [...] We’ve spent a long time viewing projects on GitHub and picking and choosing what we feel is the best way a project should be structured.
Conventions—whether they're forced on you by the framework authors or developed by the community—are still part of learning a framework and working with it for the first time. I'd say what author came away with here is even more important than just having some convention—they landed with something they really think is best for their projects! The real cost here is that onboarding developers will also include time for them to get familiar with this project structure, but is that really so much to ask?