4
Mar
2015

React Native – The Killer Feature that Nobody Talks About

by Robbie McCorkell

React Native logo
 
At the end of January I was lucky enough to go to React conf at Facebook HQ in Menlo Park. This was my first tech conference, and it was a great and inspiring experience for me. The talks were excellent and I recommend everybody check out the videos, but the talks that really stole the show were the ones on React Native.
 
React Native allows developers to build real native applications using javascript and react, but not web wrapper applications as we too commonly see. React simply takes charge of the view controllers and programatically generates native views using javascript. This means you can have all the speed and power of a native application, with the ease of development that comes with React. 

Playing with React Native

This is a really exciting development for the native app world, and gives a new perspective on what native app development could be. I’d previously tried to learn iOS development a couple of times, first with Objective-C, and later with the introduction of Swift. Whilst I think Swift is a massive improvement in iOS development, I still ended up getting bored and life got in the way of learning this new system. So initially, the idea of using my current skill set in React web development to build truly native apps was extremely enticing (and still is).
 
I generally believe that as a developer you should pull your finger out and learn the language that suits the job, but in this instance React Native seemed to offer more than just an easy way into iOS development. It offered a simple and fast way to build interfaces and to manage application logic, and the live reloading of an application in the simulator without recompiling blew my mind.

Luckily for me, conference attendees were given access to a private repo with React Native source code inside, so I began playing as soon as I got back to my hotel room. Within 5 minutes I was modifying one the provided examples with ease without any extra iOS development knowledge, and I was hooked.

An addendum

Since then I’ve been leveraging my early access to talk publicly about React Native to some great reception. It’s been fascinating discussing this with people in the community because I hear very little scepticism and a lot of excitement from web developers and native developers alike (at least those that come to a React meetup).

However the more I talked about it the more I realised the message I was conveying in my presentations was not quite right. One of the major themes I focused on was the fact javascript developers like myself can now easily get into the native world, and that companies only need to hire for one skill set to build and maintain their entire suite of applications. 

This is still a hugely important advantage, but it isn’t the major benefit and doesn’t highlight what React Native offers over competing frameworks. It also doesn’t perfectly align with my view that looking for a tool or framework just to reduce the need for learning another language is lazy thinking. There’s more to React Native than this.

React Native’s advantage

React Native’s biggest feature is React.

This may seem a bit obvious (the clue is in the title) but let me explain. When I first looked at React I thought it was insane like most people. It takes such a different approach to web development that it gives many people an immediate repulsive reaction. But of course the more I used it the more I realised I could never go back to building web applications (or any front-end app for that matter) any other way. The patterns react provides are an extremely powerful way of building applications.

If you haven’t used React much it might help to know that React lets you declaratively define what your view should look like given some input data. A react component is passed some properties that it requires to render a view, and as a programmer you simply define the structure of the view and where that data should sit. In doing this you’ve already done half of the work in building your application, because if a component or any of its parents changes their data (in the form of state), React will simply re-render the affected components given the new data.

No specific data binding. No event management. No micro managing the view. Just change the data and watch React recalculate what your view should look like. React will then use its diffing algorithm to calculate the minimum possible DOM manipulations it can do to achieve the desired result.

The second half of your application structure is of course user interaction. Patterns and tools like Facebook’s Flux and Relay help with this, but essentially these are just ways in which you can modify the data in your application in a neat and scalable manner. The application still simply recalculates the structure of the view once the data has changed.

React really shines when you start to scale an application, because the complexity of your application doesn't have to increase too much. This is of course quite hard to demonstrate in a blog post, but I can give you an example of a simple little app written in angular and react that I adapted from Pete Hunt, one of React's creators.

Angular:

See the Pen RNBVZz by Robbie (@robbiemccorkell) on CodePen.

React:

See the Pen VYBbyN by Robbie (@robbiemccorkell) on CodePen.

You can see in the code above that the React implementation is pretty short, even with the markup defined in javascript. This is mostly because of the lack of linking functions connecting the code to the markup. React will just figure this out by itself. With all of this re-rendering of the markup every time something changes, you would think React would be quite slow, but it's not. For a demonstration of how React performs in comparison to other frameworks check out Ryan Florence's presentation from React conf.

This is an extremely simple and powerful way to build front-end applications. It combines the best of both worlds in a simple and easy interface for the programmer, and a performant experience for the user. It’s for this reason more than any other that React Native is an exciting new tool in native app development. It changes the way a programmer thinks in building the front-end of their app.

A sample React Native app

Tappy Button screenshotIn the talk I mentioned above I demonstrated some of my ground breaking research in video game technology with a game I created that I call Tappy Button. The objective of this game is to tap the button in the middle to increase your score.

The sample code below defines the full application seen in the screenshot including view structure, styling and application logic. What you should notice here is that the code is extremely unremarkable. It’s the same kind of React we know and love simply applied to a native app context, and that is what’s so remarkable about it. The only differences to traditional React web development are the element names1 and the inline styling2.

Building the same application in Xcode using Swift requires a similarly small amount of code, but it does require the developer to perform a process of clicking and dragging to create elements, constraints and method stubs in the code which quickly becomes tedious. As the application becomes more complex, the developer must manage collections of view controllers that manually update the view when required. But in React the view is declared once and all the developer must do is make sure the data inside each component changes when necessary. 

Other frameworks have crossed the JS-native divide in a similar way to React. NativeScript neatly gives developers direct access to native APIs in javascript3, and the creators of Titanium have been very vocal about the fact that they have provided similar javascript bridging and CSS styling for native apps for years. But all of the articles I’ve read that compare these frameworks are missing the biggest differentiator between React Native and the others, and that is React itself.

When discussing React Native, the ability to write native apps in javascript only really deserves a cursory mention in the discussion. What's really important here is that we can build native applications using the power of React.

React as the view engine

The important things in the future of React won't be more features, add-ons or utility libraries. Yes some improvements, optimisations and structural changes will be built in down the road, but I don't think Facebook want to overcomplicate something that works so brilliantly and simply already. 

We already have React being applied to different areas with React Native, and at React conf Netflix announced they were taking a similar approach, even applying React to embedded devices like TVs using their own custom built rendering engine. We've also heard that Flipboard have swapped out the DOM in favour of canvas elements in their latest web app to impressive results.

In the future we are going to see React applied to many different areas of front-end development by simply swapping the DOM and browser out for another view structure and rendering engine, whether that be mobile and desktop native elements, canvas, embedded devices, or who knows what. This will allow developers to use the power of React and its development patterns in any environment.  

Writing native applications for our phones is just the beginning, and it’s a direction I can stand behind. The biggest benefit of react native isn’t javascript. It’s React.

 

  1. The two base elements we can work with are 'View' and 'Text' and which act as block and inline elements respectively. Coming from the world of the DOM, we can simply translate 'div' to 'View' and 'span' to 'Text' and we’re basically good to go. Any other elements like 'TouchableHighlight' are utility components provided to us by React Native’s component library.

  2. Facebook have provided their own CSS based styling interpretation including their own clever implementation of Flexbox. We now write our styles as javascript objects and apply them inline to our view elements. Currently styles don’t seem to cascade, which is both an advantage and disadvantage depending on your use case. But the interesting thing about applying styles in this way is you have the full power of javascript at your fingertips. With a bit of forethought you could conceivably come up with clever systems to share global styles, and apply them to elements automatically in your application.

  3. I think NativeScript could be an interesting way to build react native bridges to native APIs, and we'll be experimenting with this in the future. However I’m still sceptical as to whether the overhead is worth it, and maybe if we want to build native bridges we should just learn the bloody language!

Red Badger are hiring. Come join us


  • http://appletite.tumblr.com/ Alex

    I love how your React Codepen is blank (aka broken). Not a very convincing comparison, haha.

    • Robbie

      I can give you the obligatory ‘it works on my machine’ response :). But seriously, I’ve asked around and it seems to be working fine for people.

      • http://appletite.tumblr.com/ Alex

        Well, here is a screenshot of it NOT working on my PC in Google Chrome

        http://f.cl.ly/items/0x0n1E1I1H351a3x3L1h/Screenshot_030415_035518_PM.jpg

        • http://chrisamaral.me/ Christian Amaral

          This is a technical blog post covering some bleeding edge technology, one doesn’t simply jump in the comment section shouting “ha, bullshit! doesn’t work!”.

          As a fellow developer (I can only suppose you are, otherwise WTF) the least you could do was to post the console log, instead you choose to be that guy.

          • http://appletite.tumblr.com/ Alex

            It speaks volumes about how unprepared this new language is for prime time. Until it is developed further, I don’t have time to waste messing with it and finding work arounds. I will let other people do that. There are other much more stable languages on the market that are a better use of my time.

            Of course I am a programmer. I also don’t completely abandon stable languages every time something new gets announced.

            You act like React is the only solution on the market for creating native code from web languages.

          • relaxation

            Great contribution to the conversation

          • Robbie

            It’s more likely the JSX transpiler that is being used in CodePen. Facebook are slowly converting their site to use react. Does the left hand nav on Facebook work for you? Or the like/comment/share buttons underneath each post? Then react works just fine.

          • http://itmitica.github.io/ Dumitru “Mitică” Ungureanu

            My guess is you’re running in XP compatibility mode I may be wrong.

            I’m sure, as a programmer, you have more than one machine and you test on more than one OS. I’m also sure, as a programmer, you have debugged and identified by now the problem and we’re all waiting for a professional resolution from you. I can’t think of any other reason for you to bother the OP with your technical difficulties.

          • Daniel Abramov

            React is not a language, it’s a library.

            For it to work, your users’ browsers needs to support `console` and ES5. If you expect them to have old environments (IE9 and earlier I think), it’s up to you to provide those shims yourself (it’s not difficult ;-). I’m sure CodePen React integration doesn’t include those shims.

            Since you say you’re running Chrome, the issue is evidently different. Might be particular CDN scripts not loading? It would surely help if instead of bashing some technology you don’t use, you’d actually look what broke in your case and shared it.

      • Brian Hann

        Looks like it’s not working for me because the 301 redirects for the js files aren’t resolving correctly. Perhaps that’s Alex’s problem.

    • Chris Portscheller

      His demo won’t work on ie6

      • Robbie

        Interesting. On real projects we use server side rendering and don’t send the client side payload for old browsers anyway.

      • SocialChooozy

        It’s 2015, who cares?

    • Keith

      Works fine for me. What browser are you using?

      • http://appletite.tumblr.com/ Alex

        I am using Google Chrome Version 42.0.2311.15 dev-m and I am running Windows 7 64-bit.

    • http://itmitica.github.io/ Dumitru “Mitică” Ungureanu

      Works on Ch 41 and 43 (Canary) Win8Pro 64bit. Codepen and OP are not at fault, you and your machine are.

    • N1ghtmare

      This is such a lame comment, made by an absolute amateur, which brings nothing to the conversation. If you were a proper dev you would figure out the reason for it not to work in like 2 seconds (99% sure that it’s the CDN not loading), but no, you chose to be a complete douche and leave a shitty comment. Bravo!

    • http://mikko.tapionlinna.fi/ Mikko Tapionlinna

      Are you using https anywhere? I was and it broke the Codepen integration.

      It’s not only broken on this site, it’s broken in Codepen site too. So it definitely is not the fault of the authors here.

      Apparently the codepen tries to include stuff over http and chrome does not let it as it’s being run inside https because of the extension. This causes mixed content warnings to appear in console.

      If you’re using https anywhere, please first try running the page without it and only after that post such comments on blogs.

  • ModusJesus

    Great article.

  • Jonas Windey

    I’m thrilled to start using it. React is really gaining a lot of traction and we are moving from Angular to React as we speak.

  • Szymon Kosno

    Looking at React example I would say this implementation is a bit closer to it in Angular:

    http://codepen.io/anon/pen/KwBeZa

  • cnc

    Robbie, great article.
    Question for you.
    In the article by the Wired Tech Director, at: http://www.wired.com/2015/03/wired-dot-com-from-the-devs/, she says:

    “We’re starting to incorporate React.js for articles that require live updates”.

    Do you think they’re not implementing it across the board, because they’re trying not to add too much work, to converting *everything* in their existing Site, or is React maybe something that some people would only choose to use, in performance-sensitive areas of their web apps/sites?

    I’m thinking, it’s wise if you’re starting a brand new project, to just use it across the board, due to its entire paradigm-altering nature

    • Robbie

      Thanks, I hadn’t seen that article. I’ll have a proper read later.

      I agree I think if you’re starting a new project, then definitely go full react. All of our current projects here at Red Badger use it fully. I’ve seen many examples from the meetup that we run of people incorporating React into their existing site a small bit at a time, partly to test it out, and partly because they don’t have time to rewrite their whole site.

      This works well because you can simply mount a react component to a particular DOM node without effecting the rest of your application with a simple call of ‘React.render(, mountNode);’.

      So I imagine of a company already has a fully functioning app, it makes perfect sense to convert things a small bit at a time.

  • wootwoot1234

    Any news on when React Native will be released?

    • Robbie

      There’s no official line, but I would expect to see it in the next month or two.

  • Geoff Flarity

    Can the Javascript be remotely updated? I’m assuming yes though no one seems to talk about this. Because with 7+ day app store approval times in ios, native performance with quick updates is THE killer feature, and why facebook made it. Right now it’s move quicky, make mistakes, then wait 7 days to fix them… 🙂

  • Mikael Osterhed

    You ought to check the B4x products, especially B4i for iOS apps. Native code as well and so easy to use.

  • shoroMario

    Good article.
    note: the React example snippet in CODEPEN doesn’t works

  • Anthony Marwyn Abadicio

    “I think NativeScript could be an interesting way to build react native bridges to native APIs, and we’ll be experimenting with this in the future. However I’m still sceptical as to whether the overhead is worth it, and maybe if we want to build native bridges we should just learn the bloody language!”

    We are planning to do something related. Have you got into any progress with this?
    We have a nativescript app that we wanted to integrate Shoutem mobile app creator into. Shoutem is based on react-native. We can’t get our head around for the right approach specially the navigation or routing. Or maybe rendering react-native from within nativescript app.