Appropriately enough for 2015, there’s a bit of a “Back to the Future” vibe about the latest excitement in the app development world:
… and there’s always something to learn from other frameworks. But if there’s one thing Appcelerator and we as community should learn is that it looks like we have to do a better job at getting the word out. The word that Appcelerator has been doing this for years!
Yes, that was it. And while we’re delighting in curmudgeonry:
While we’re on the subject of terminological disasters, Facebook’s react.native seems to be doing a good job of muddling the waters.
While some parts make use of native infrastructure, a lot do not:
- uses views as drawing results, rather than as drawing sources, has a
- parallel component hierarchy,
- ListView isn’t UITableView (and from what I read, can’t be),
- even buttons aren’t UIButton instances,
- doesn’t use responder chain, but implements something “similar”, and finally,
None of this is necessarily bad, but whatever it is, it sure ain’t “native”.
Perhaps despite all this, there is indeed some reason that React Native will displace SDK Native for development in the same fashion that Titanium has not; but we’d bet against it, personally. However, there is significant contrary opinion; here’s some of the more interesting ones, along with some resource links:
ReactNative.com has a good spread of news and resource links
React.parts: “A catalog of React components”
Now, one assertion in the above that is worthy of consideration is that the more functional model of React has its design advantages. But as it happens, there’s a way to experiment with React design that is actually native:
Building user interfaces for iOS requires lots of imperative code. As a developer, you create views, configure them, and add them to the hierarchy. You then have to implement callbacks to controllers, which in turn must change the state of your views. Implementing this two-way data flow, even for a simple UI, can be tedious and error prone … To tackle this challenge, we wanted a better abstraction. We drew inspiration from React and its functional reactive programming model for building UI and made a native, Objective-C++ library called ComponentKit which is now used to render News Feed in the Facebook iOS app…
And how did that work out?
ComponentKit gave us performance and reliability gains in News Feed UI Rendering and made the system easier to reason about. It allowed us to:
- Reduce the size of our rendering code by 70%. Manual and intricate layout code was completely removed as it was no longer needed.
- Significantly improve scroll performance. ComponentKit eliminated many superfluous container views and significantly flattened our view hierarchy. A flatter hierarchy means less time spent on the main thread to render UI.
- Improve test coverage. ComponentKit made it easy to build modular UI for which each piece can then be tested in isolation. We now have almost all of News Feed UI under test coverage using snapshot tests.
OK, now this, this intrigues us.