Back in January, a few Red Badgers were lucky enough to be sent to React.js Conf at Facebook HQ. We’re huge fans of React and have been using it to great effect on every project since we discovered it in early 2014.
There were many excellent talks at the conference, and it was staggering to see just how much adoption React has gained in such a short space of time, especially by some huge players in web technology (anyone heard of Netflix, AirBnB or Yahoo?).
There was one very significant announcement that overshadowed the other talks, though. Tom Occhino took to the stage in the first keynote and delivered a Steve Jobs-esque announcement of React Native. As a bonus, all conference attendees were given early access to the project, now open source.
After experimenting with, and contributing to React Native during its private beta phase, I’ve formed an opinion on what it might mean for Web developers like us, and our clients. And it’s exciting.
Red Badger are rather good at building responsive websites. Our clients love them because they deliver a fantastic experience for their customers on all kinds of devices. These sites feel better, convert better, and look great. They also don’t cost significantly more to build than traditional websites, when developed with responsive in mind from the beginning.
They are the 80% solution, though. They don’t solve everything. The last 20% has proven to be a problem. This elusive 20% sometimes means we have to say no to projects where the mobile web is not yet a good fit, and we hate it.
So what is the missing 20%? Or rather, what’s wrong with the current state of the mobile web?
What’s wrong with the Mobile Web?
- Real performance problems – The DOM is just slow. The weight of the DOM feels much worse on mobile, where resources are constrained. Attaining the 60fps necessary for a smooth experience can be very difficult when images are being decoded whilst scrolling, for example.
- Poor gesture support – This is a huge part of why native apps feel more intuitive and higher quality. I frankly had no idea just how much control was given to native developers in dealing with gestures correctly until researching it, and it shows. Simple things like not accidentally clicking a link whilst scrolling, responding to sliding events with velocity etc. are much harder to deal with on the web.
- Many Native API’s are still not exposed for web – So we simply can’t take advantage of them (Push Notifications, iBeacons, Vibration, TouchID to name a few). This is a major cause of us saying “no” to a requirement. This can be somewhat addressed by a framework like PhoneGap, which comes with its own set of negatives.
- Half baked features that don’t really work as intended eg. offline support with AppCache.
- Years of legacy browser support – A huge productivity killer.
Perhaps the biggest problem of all, though, is the glacial rate at which these problems are being addressed. We’re die-hard advocates of the web, but we can’t wait forever. Exciting new web standards such as ServiceWorker (bringing Push Notifications, much better offline support etc.) are still a way off, and Apple have no publicly announced plans to adopt this standard at all for Safari.
Web apps still don’t feel as good as native apps, and it’s a shame. We’ve been saying they’ll catch up for a while now (Facebook famously went native in 2012) and they aren’t.
So how do you avoid the unreasonable cost of native development, of running separate teams with separate tech stacks, with no code reuse, limited shared knowledge, and their minds on technology instead of the product?
After using React Native for a few weeks, I’m convinced. I’ve distilled my feelings into a list of benefits:
- It’s Real, Native UI – With great performance, animations and gesture control, that blend effortlessly into the platform. This means you’ll still have different Web, iOS and Android implementations, but they’ll provide a great experience that’s tailored to each platform. It’s nothing like a WebView.
- It’s React, a technology we already love – it’s fast, it’s familiar and we write far less bugs in it thanks to its functional properties.
This means the same team can develop the Web, iOS and Android versions of an app, using technologies they’re already comfortable with. The developers best placed to build a product are the ones that understand it the best, not those segregated into different teams based entirely on technology.
- Speed of Iteration – Changes in the UI are reflected immediately via Live Reload. There is no lengthy recompilation step, and most changes appear within a few seconds. This is what we’re used to on the web, but something very new to Native development. It leads to happier, more productive development sessions, and a willingness to experiment without frustration.
- A simple JS->Native Bridge – So you can use libraries written in Obj-C/Java when you need to. It’s possible to build both native libraries (eg. bridging the TouchID service on iPhone) and native UI components, such as a switch, or slider. You can create nice, declarative API’s for these libraries and distribute them on NPM.
- It works on iOS and Android (coming soon) – There’s no reason it can’t work on other platforms too.
— Sebastian Markbåge (@sebmarkbage) March 9, 2015
These benefits boil down to enormous workflow and productivity gains over traditional native development, making that last 20% much more bearable and potentially a lot less expensive, too.
The most promising part of React Native is not the code itself, but the ideas. Facebook core contributors have regularly stated that they see it as a testbed for new ideas. These ideas can lead us to better abstractions and solve real problems before being implemented within browsers. More eloquently put:
react-native and react-canvas isn’t subverting the web they are early polyfills of the future web.
— Sebastian Markbåge (@sebmarkbage) February 15, 2015
We need better primitives for building performant and native feeling UI within mobile browsers, and this shouldn’t start as a draft from a standards body, perhaps React Native can help lead us there.