Remember this day, because React Native is going to be a game changer (patent clause stuff aside). Others like Phone Gap tried to make it so you could build native apps using HTML/Javascript but they failed because they focused on running said HTML/Javascript within a performance limited WebView and not the other way around.
This weekend I am going to try and get a working application built using React Native. Facebook are absolutely killing it in regards to their open source contributions. The learn once, write anywhere paradigm is smart as opposed to what others have done via their write once, deploy anywhere approach which just doesn't work for web and native applications.
I think there's a lot of proof that it does work, given there's 300,000 Ionic apps, tons in production.
I downvoted you not because I don't agree that Native will be compelling but because I hate to see all this hate that's come out against hybrid apps in general that's even been propagated by React Native devs.
Webviews will get there. WKWebView is already a huge step forward. I think Native is great, but it's not a clear winner in many cases. I even like "learn once apply everywhere" (though it doesn't really go against the web in any way), but I would say the mountain of hybrid apps out there actually disprove that it "just doesn't work".
Yeah I'm sorry, but web views are incredibly substandard to native apps. I've never found I hybrid app that I found comparable to its native counterpart. Simple things like scrolling can be very spotty most of the time.
>> Simple things like scrolling can be very spotty most of the time.
That's just FUD. Only hybrid apps that use non-native scrolling are jittery, and for years now you can use '-webkit-overflow-scrolling: touch` to get native scrolling with bouncing.
I'm a little concerned because, for example, a button is not implemented as a native UIButton, and a ListView doesn't use UITableView. Instead they are composed of native UIViews with a lot of JavaScript glue.
That being said, Facebook has more experience writing iOS apps than me, so it may be possible that those things don't really matter (and doesn't preclude 1:1 components from being added down the road).
I don't even see a button class in React Native... but if there was one and it was custom-made from UIViews, it's going to look and act differently than a native button. Turn on accessibility features -- does the button's title get read aloud? If you turn on button highlighting, does the button get an outline? If you turn on bold text or large text, does the text of the button change?
I've spent 15 minutes with React Native so far, and as best I can figure, the answer is no.
If they were building the GUI components from UIKit pieces, they'd get all of this for free. But I understand it would be pretty hard to get all this working with the flexible layout architecture they have... so I'm guessing they'll have to slow add all the accessibility features in over time.
Absolutely. My primary concern is with the controls feeling native. Reimplementing controls with UIViews doesn't seem much better than reimplementing them with HTML/CSS (save for performance). There's still surface area to break the illusion.
Some food for thought: what if you kept HTML and CSS but instead of using a WebView to render it, you rendered the DOM manually using UIViews? You could even make overflow: scroll; turn into UIScrollViews automatically.
If it's using UIViews, it isn't reimplementing native controls. It's using native controls, same as if it was implemented with (interface builder) .nib files. That's like saying "reimplementing html/css with html/css".
It may be a "native control" but if you reimplement UIBUtton and have to recreate what Apple did to create it in the first place, that's where things tend to fall apart.
If you write JSX. What would be the benefit of using html anymore? Your own components can be the same on web or native. The base components might be a bit different but that isn't difficult to learn.
One of the big pieces in React Native was reimplementing flexbox positioning (they did it using randomly generated test cases in a TDD-based process; described in the "diving deeper" video iirc). So as long as you use flexbox to position your html, it should be pretty portable to react native.
With React Native, instead of writing HTML/CSS and running it on a crappy browser embedded in an app, you write code that looks like HTML/CSS (it's actually JSX)[1][2] and it is translated to native code.
It's not translated. The JS runs to create a declarative description of what the ui should look like, which is reduced to a diff representing the changes that needs to be made to the native ui. These change commands are then marshalled to native code which simply implements the changes (add this thing, move this thing, remove this thing).
This weekend I am going to try and get a working application built using React Native. Facebook are absolutely killing it in regards to their open source contributions. The learn once, write anywhere paradigm is smart as opposed to what others have done via their write once, deploy anywhere approach which just doesn't work for web and native applications.