Since I started working here at Shockoe, I have been writing cross platform mobile apps using Appcelerator Titanium. For the most part, Titanium has served my needs and given me the power to write a single JavaScript codebase that can be run natively on iOS and Android devices. But here at Shockoe, we are never content to sit still and let the world pass us by. We are always looking for the next breakthrough in the mobile development world. With the recent update to Facebook’s React Native platform, which added support for creating Android apps as well as iOS apps, I decided to give it a try.
At first glance, Titanium and React Native seem to be very similar. And that’s because they are! Both frameworks use a single, shared JavaScript code base. Even though you write the code with JavaScript, Titanium and React Native both use platform specific native elements. This helps give your apps the native look, feel, and user experience that just can’t be done with something like a mobile website. I have not yet used React Native to work on a large project with many screens, but from what I have seen so far in my test applications and examples provided by Facebook, React Native seems to perform just as fast, if not slightly faster, than Titanium. Titanium has been around for much longer than React Native, so it has access to a large percentage of the native iOS and Android APIs. React Native covers a good number of native APIs, and, like Titanium, it gives developers the option of creating their own native modules that can expose native APIs to our JavaScript code.
So why would we consider changing our entire workflow here at Shockoe if Titanium and React Native are so similar? That’s a good question. I just mentioned some of the big similarities between the two frameworks, but there are actually quite a few differences. Each framework has its strength’s and weaknesses that make it unique.
Why should you use React Native?
If you already know React for the web
React for the web was open sourced earlier this year, and if you are already familiar with it, you will have a good understanding of the basics of React Native. React Native and its web counterpart both use Flexbox to lay out the components on screen. It is extremely easy to use the Flexbox grid system to lay out your UI components on screen.
React Native uses ES6
And all the goodies that come along with it. React Native uses Classes, template strings, and Promises – a Shockoe favorite.
It’s delclarative
If you have spent any time with Titanium, I’m sure you have written code that looks like this:
if ($.myLabel.text === 'ON') {
$.myLabel.text === ‘OFF’;
changeViewToOff();
} else {
$.myLabel.text === ‘ON’;
changeViewToOn();
}
In this example, you first need to poll the view on screen to see what state it is in. Then, depending on the state, you need to update that view and any other models to their new state before proceeding. And what if you want to add more states? Then you need to keep adding more functions that can transition between these states, and the code becomes less maintainable.
In React Native, that code might look like this:
if (this.state.on) {
return (<OnState/>);
} else {
return (<OffState/>);
}
The brackets denote a React element that is declared somewhere in the code. As you can see, it is extremely easy to get an idea of what the app will look like, and how it will behave just from looking at the code. Writing reusable React components is highly encouraged, and leads to more code reuse which means you can develop your apps faster.
You like animations
React Native allows your apps to have some really slick animations. This can help give apps a more native user experience. Animations are just as easy to declare and execute as on Titanium, but in React Native, you can chain together animations much more easily by creating a sequence.Animated.sequence([ // spring to start and twirl after decay finishes Animated.decay(position, { // coast to a stop velocity: {x: gestureState.vx, y: gestureState.vy}, // velocity from gesture release deceleration: 0.997, }), Animated.parallel([ // after decay, in parallel: Animated.spring(position, { toValue: {x: 0, y: 0} // return to start }), Animated.timing(twirl, { // and twirl toValue: 360, }), ]), ]).start(); // start the sequence group
This is an example of a series of animations. They can be staggered, delayed, or played in parallel. This is a much better solution than the callback system used by Titanium.
It has great debugging tools
React Native takes an interesting approach to its debugging tools. It uses Chrome or Safari’s console/debugger. If you are familiar with either of these browser’s developer tools, you should feel right at home. Also, React Native allows you to inspect UI elements in your app, which is probably one of my favorite features. You can see an example in the screenshot below.
Getting to see the actual boundaries and margins for an element on the screen is a huge time saver.
So everything sounds great. Let’s start using React Native for everything. Not so fast. React Native is still very much in its infancy. It is growing rapidly, but right now it is not as feature rich as Appcelerator Titanium. Titanium covers much more of the native APIs for Android and iOS, and there is a large catalog of native modules in the public domain. There are also some glaring gaps in React Native’s tool set such as Android push notifications being notably absent. The documentation for Titanium is also much more in depth.
With that being said, I do think that React Native can have a place here at Shockoe along side Appcelerator Titanium. I think React Native will grow very quickly, and will be much more powerful in the near future. React Native’s UI components allowed me to create complex views in less time than with Titanium. I intend to work with React Native more on future projects, but I won’t be leaving Titanium any time soon.
Sign up for the Shockoe newsletter and we’ll keep you updated with the latest blogs, podcasts, and events focused on emerging mobile trends.