Pages

Tuesday, September 15, 2015

React Native is Facebook's open-source framework for building native mobile apps using JavaScript. Unlike PhoneGap/Cordova, React Native provides bindings for native UI controls which totally outclass HTML-based hybrid solutions. After playing with the sample app for a while, I decided to jettison my Cordova codebase and rewrite the Circadi app using this new framework. It took me about 96 working hours to finish an MVP, now published on the App Store. My overall experience with React Native is positive. I'm going to give an account of my key findings below for people who're considering to adopt the framework.

Advantages

Developer productivity

React Native enables developers to write native apps in JavaScript with ECMAScript 5/6 features and optional type checking using Flow. This alone is a huge boon to my productivity even if cross-platform code reuse were never promised. Having written Objective-C and Java at my former employer, I much prefer writing apps in a more terse language like JavaScript despite its many foibles.

The interpretive nature of JavaScript also significantly shortens the RN app dev cycle, making it as easy as developing web pages. Reloading a RN app in a second by pressing ⌘+R turns out to be a truly refreshing experience. (You do need to recompile the XCode project when you switch between build targets, link in a new native module, add a resource file, patch an Objective-C implementation, or resolve the occasional red-screen-of-death.)

App performance

React Native app's UI components feel native because they are native controls exposed to JavaScript via a JS/Obj-C bridge. Achieving the same level of look-and-feel in HTML is a sisyphean task — eventually you'll have to either compromise on fidelity or resort to a non-standard UI theme.

React Native borrows the virtual DOM diff idea from React and makes it conceptually simple to write high-performance UI. If you try to repaint a full-screen background 60 times per second, RN will stutter; but for most non-game apps with few moving parts, it's not hard to create a smooth experience.

Caveats

Cross-platform support

Facebook finally unveiled React Native for Android yesterday, almost six months after the iOS release. However, porting my RN app to Android is non-trivial. First of all, some of the UI controls such as SwitchIOS need to be replaced with Android counterparts; some (e.g. ActionSheetIOS) must be scratched and redesigned for the targeting platform. A more pressing issue is porting all of the native libraries my app depends on. I'll end up writing Java extensions or waiting for others to do it.

There's also no obvious way to write Apple Watch apps in RN yet.

Library support

React Native has fewer than 30 built-in components so far, iOS and Android combined. Chances are good that you'll need to find (or write your own) extensions to implement some basic features, for example, accessing SQLite databases or supporting in-app-purchase items. You'll be hurled back to the Dark Ages of app development, so be prepared with some knowledge of Objective-C and Java. Fluency in native code will be useful anyway even if you don't write RN extensions because: (1) React Native's documentation isn't on par with Apple's yet. You'll sometimes need to dive into the .m files to ferret out implementation details. (2) React Native is still a young framework, fraught with bugs on the other side across the JS bridge.

ES6 language support

Although you can use ECMAScript 6 features in your RN app, be aware that when you run react-native bundle --minify for release build, RN transpiles JavaScript into ES5 using Babel before calling UglifyJS2 for minification. However, not all ES6/7 syntax get transformed, and UglifyJS will choke on statements like for (... of ...), yield, etc. This is not technically a RN issue, but it will bite you during the release phase if you go too fancy with ES6 goodies.

Conclusion

I find React Native a good fit for JavaScript programmers to develop decent native apps with mostly standard UI. This fledgling framework has shown great promise to reduce app development cost, posing a real threat to Cordova and Appcelerator's Titanium.

Wednesday, September 2, 2015

Shortly after announcing a company restructuring plan, Google unveiled a new logo yesterday. Do people like the sans-serif design or still prefer the classic logo? I set out to ask the question on three popular crowdsourcing platforms: Amazon Mechanical Turk (MT), CrowdFlower (CF), and Google Consumer Survey (GCS). My survey displays the new and the classic logo and asks participants to pick the one they like more. They may optionally write down a line to explain their choice.

Over the past few hours, 874 valid responses have been collected. Across all three platforms, there's a predominance of preference for the classic Google logo.

All GCS participants come from the US while 99% of the CF crowd are from other countries. The demographics of participants on MT are unknown, but 80% of the overall workforce there are US-based according to mturk-tracker.

Although it's optional to provide a reason, many people did opt to write one. Their descriptions of the classic logo are universally positive while reception of the new logo seems mixed.

It's probably too early to call Google's new logo a branding failure. The general public's initial negative reaction might be attributed to change aversion. I recognize that, for example, my personal bias against the new logo is not just an aesthetic judgment but also a result of an emotional attachment to the classic Catull font. Many of my Googler friends share the same sentiment, but some of them reported that after a week-long preview period, they hated it less. Maybe the sans-serif new logo will eventually grow on us as the company evolves.