All this makes me realise that even if React Native isn't the best way to do what it's doing, the sheer amount of support it has will make up for it. Within a month I swear it'll have more custom plugins than every other "compile to native" framework out there...
Having used React Native for two months, I can confidently say it's the best way to do what it's doing. Native is garbage (overly complicated), web is garbage (for now, maybe?) and as for solutions using a JS bridge like React Native, I think RN does it best. Easy to use and extend, and has default support for one of (if not the best) JavaScript framework available right now.
What's interesting about this example to me is that Apple is moving away from programmatically laying out your views. I wonder what the tradeoffs in building a complex view are vs just using Interface Builder, constraints, and size classes.
Also outside of Facebook Groups, which other apps are using React?
Oh I didn't expect many, I just wanted to know what's been published that uses React. I want to test the apps and see if they live up to the hype. For the past six years, I've tried so many non-Apple frameworks for building iOS apps that I gave up about 6 months ago after Famo.us.
Not out of a box. There's not a huge difference in environments but automatic porting was never a design goal. React Native follows the mantra "learn once, write anywhere" instead of "write once run anywhere". The main differences are:
* React Native has its own primitive components (Text or View) instead of primitives that map to standard HTML elements (span, div).
* React Native's runtime environment won't have all the browser APIs (DOM, navigation, web storage).
* React Native uses a subset of CSS and exposes it through the JS API instead of relying on the browser's styling (and separate CSS files).
That said, porting components is trivial. If you have a library of core components (Buttons, Menus, TabBars, etc.) then porting just those to the native implementation gets you most of the way there.
It's also possible to alias Text => span, View => div, etc. and use React Native's css-layout library on the web. But that won't help for legacy applications.
While I've had no problems with React's coupling of components controller and view in one location, doesn't this suggest that it should be separated? One view for web, one for RN using the same state and controller?
That's how we've approached the apps I've been involved in. Your Flux or Relay stores and non component modules can be shared.
This isn't a hard and fast rule, just an acknowledgment that different platforms have different constraints and conventions. If you try and share all your code then you'll end up designing for the lowest common denominator, and your app will feel out of place.
Plug here but if you're looking for web React apps try Reapp[0]. You could fairly easily port between the two. We're using a lot of the same tech: flexbox layouts, CSS in JavaScript (using the same syntax, just simpler).
In our next releases we'll be moving towards replicating many of the features of Native and API as well.
