We can have the main README.md be an organized summary of end goals and tasks/dependencies between them. I'll use Issues as a way to brainstorm / discuss.
I had one idea about a way to decouple cross compilation tooling from actually building all the necessary abstractions and utilities. A long time ago, I had insisted that the React Native bridge be serializable. That doesn't mean that we had to serialize in practice, but just that the bridge API could be implemented in a serializable manner. The reason I originally insisted on that is that it made tooling so much easier (given infinite resources, making it easier to build tooling wouldn't matter).
For example, you could run your React JavaScript App running in a Chrome instance, making use of its debugger, but send messages across the network to your actual device, or simulator. This could also easily be done over the air so you didn't even need to plug a device in. So that's just one example of how a serializable bridge was immediately useful.
A serializable RN bridge is also beneficial for moving Really Native React forward because it can help us decouple longer term projects like cross compiling packages, from smaller and isolated ones like: "building out a message queue to communicate with iOS/Android".
For example, you could build everything you need without solving cross compilation, by building out everything but cross compilation support, and running the code on your laptop's OS/architecture, while serializing the commands over to the device - and you'd see your code rendering real native views on device, with your code running natively - on your laptop, remotely.
We can have the main README.md be an organized summary of end goals and tasks/dependencies between them. I'll use Issues as a way to brainstorm / discuss.
I had one idea about a way to decouple cross compilation tooling from actually building all the necessary abstractions and utilities. A long time ago, I had insisted that the React Native bridge be serializable. That doesn't mean that we had to serialize in practice, but just that the bridge API could be implemented in a serializable manner. The reason I originally insisted on that is that it made tooling so much easier (given infinite resources, making it easier to build tooling wouldn't matter).
For example, you could run your React JavaScript App running in a Chrome instance, making use of its debugger, but send messages across the network to your actual device, or simulator. This could also easily be done over the air so you didn't even need to plug a device in. So that's just one example of how a serializable bridge was immediately useful.
A serializable RN bridge is also beneficial for moving Really Native React forward because it can help us decouple longer term projects like cross compiling packages, from smaller and isolated ones like: "building out a message queue to communicate with iOS/Android".
For example, you could build everything you need without solving cross compilation, by building out everything but cross compilation support, and running the code on your laptop's OS/architecture, while serializing the commands over to the device - and you'd see your code rendering real native views on device, with your code running natively - on your laptop, remotely.