I have seen the future of mobile development, and its name is React Native.
Well, cue the applause.
Cue the applause because that statement has tremendous implications for the current state of mobile app development, especially concerning the elusive goal of hybrid write-once, run-anywhere cross-platform nirvana. Those developers in the audience applauded because they sensed they were witnessing the birth of something new that could be game-changing. (Okay, maybe the React conference won't have the same impact on coding that Springsteen's 1974 Harvard Square concert had on rock 'n' roll, but it could be big.)
"We're calling it React Native, and we're building it simultaneously for iOS and Android," Occhino announced after the applause died down.
It's different, and it shakes up a lot of "best practices" and traditional notions about coding. Things like separation of concerns, mixing markup and logic, imperative versus declarative, and much more.
For one thing, let's forget that write-once, run-anywhere chimera. It just doesn't work, Occhino said, though he used a little stronger language.
Take native widgets, for example.
"Native widgets are a black box," Occhino said. "We don't have access to the source code. We can't see what the parameters are." Developers just can't see the numbers, the specifications, the things that make widgets "feel like they feel."
"It's not even close!" Cue the laughter.
The coders at Facebook developed the Web project for internal use because their code base was becoming so big that apps became a "nightmare" to work with. Changes in data caused cascading updates that affected all kinds of other things, causing a lot of rerendering of views and unforeseen consequences because engineers couldn't keep all those potential side-effects in their heads while coding. Their code became unpredictable and they became less confident coders.
That gave rise to a simple conceptual breakthrough. They already wrote code that determined what the app looked like with an initial set of data, so why not just re-execute that same exact code when data changes? Occhino said that while that was a simple concept, it carried some obvious problems. But the approach they developed was so exciting -- and just plain fun to work with -- that work proceeded to address UX and performance problems.
The Facebook coders found, to some surprise, that early React efforts didn't degrade performance and in fact sometimes improved the metrics. Better still, the engineers could code with more confidence and became more productive. Newcomers who knew React could join teams and immediately become productive. "This is insane," Occhino said. "I've never seen this before."
Eventually, the lure of native app development beckoned. Native apps offer many advantages over Web apps, such as the aforementioned look and feel, and performance, enabled by threading capability, gesture support and other factors, but the development experience for coders was worse. The Facebook engineers started to address those problems and build upon the original React coding effort, which was primarily led by Jordan Walke. (See this Hacker News thread where Walke chimed in to answer questions.)
A lot of technical details make React Native powerful, like the Virtual DOM that has now become a standalone construct and is used in many other frameworks. Also coming into play are server rendering, descriptive warning messages and custom event features, among many more.
"But the thing that makes all these features and more possible, is the fact that React replaces an imperative, mutative API with a declarative API that favors immutability," Occhino said. This declarative-versus-imperative approach -- though not new by any means -- is the basis for everything else, such as heavy use of components.
Well, not too much more, because this stuff is so new. I don't even have a Web site to point you to, just a bunch of YouTube videos. Three weeks prior, Chedeau said, the team didn't even know they would be presenting React Native at the conference, so there was a "crunch" to get the project suitable for its public debut.
Facebook did give conference attendees access to a private GitHub repo of the sample Xcode project for the iOS movie app so the developers could start playing around with it, and promised eager questioners more to come soon.
The dev tools are being worked on internally, Chedeau said, and will be coming out for general use.
This is amazing! I've scratched my head with PhoneGap, CrossWalk Project, and still -- it doesn't get what I want. I looked at Xamarin, which seems awesome, but expensive and you don't want to invest in the .NET stack. Marmalade seems like only for C++ devs and it is also commercial. Dropbox and Wave (acquisition of Salesforce) used neat C++ cross-platform framework for Android and iOS, but it's not for startups; it's not easy to find good devs with C++ background. With this -- it's gonna be game-changing.
It's almost like it was just Born To Run or something.
(AUTHOR'S NOTE: This article originally attributed the creation of React Native to development work led by Jordan Walke, who kindly informed me that he headed the original React effort, not the native project. I regret the error.)
"This is not groundbreaking at all!" said one commenter on the keynote video page. "It's already available for years. Just take a look at Appcelerator Titanium." Do you agree? Is it a game changer or another overhyped fad that will pass? Let us know here or drop me a line.
Posted by David Ramel on February 4, 2015 at 10:59 AM