My friend Daniel has been a web developer throughout his career. In the last four years, Daniel like many of his peers was primarily a mobile web developer.
Daniel made sure that everything he developed worked perfectly fine on the desktop as well. But organically, Daniel found himself spending 70% of his time dealing with the mobile web.
Daniel was a big proponent of “Write once, run everywhere.” He was bright eyed and enthusiastic about the premise of it. Daniel wanted to get his creations in the hands of as many people as possible.
But little by little as the years went by, Daniel’s enthusiasm died down. He started experiencing the many problems with the mobile web. Daniel assured himself that as the years went by, surely these problems would be resolved.
If the web runs so well on the desktop, surely mobile will catch up eventually. Any day now.
Daniel was wrong.
With every passing year, it seemed like the chasm between mobile web apps and native apps just kept growing.
To make matters worse, big proponents of hybrid web apps were pulling out. Both Facebook and LinkedIn decided to go native several years ago.
When Mark Zuckerberg said betting on HTML5 was his biggest mistake, A little part of Daniel died.
But that was a long time ago. Daniel has since come to grips with the fact that achieving a “native-like” experience with the mobile web was settings himself up for failure.
The Cordova Conundrum
Daniel was a big believer in the Cordova framework and what it represented. “Give me a browser and I’ll do the rest” he used to say.
Daniel eventually came to the realization it’s much harder to develop hybrid mobile apps than native ones, and the results are often “not quite native” in quality.
But still Daniel refused to give up. He didn’t want to give up on JavaScript. He was raised on the premise you should always bet on JS and trust in Atwood’s Law.
And besides, Daniel found weird and inefficient that most companies nowadays have two completely separate mobile development teams, one for Android and one for iOS. They each write apps which are 90% similar and yet their codebase is 90% different. Although Daniel now admitted this is a necessary evil, he didn’t want to take any part of it.
How weird is it to be on one of those teams? Always playing catch with another team who’s developing the exact same thing you are, but using a completely different set of technologies.
Will Daniel ever be able to create native app experiences in JavaScript? Is there anyone who can save JavaScript from App Store annihilation? #Drama
The Dawn of React Native
On January 29th, 2015, Christopher “Vjeux” Chedeau gave a 30 minute that’ll forever be ingrained in Daniel’s mind. “Deep Dive into React Native” was one of those talks where when you first watch it, you have no idea what you’re actually seeing.
At some point you’ll finally comprehend that what you’re seeing is a JavaScript runtime that allows you to render React views, which then actually render native views. On top of that, you also get to use Flexbox as your layout engine.
The excitement in the room was palpable.
”THIS IS AWESOME!!! THIS IS WHAT I’VE BEEN WAITING FOR THIS WHOLE TIME.” – Mobile web developers everywhere, seeing React Native for the very first time.
The React Native Advantage
There are several reasons that explain why React Native exploded the way it did. And they’re worth noting.
It’s React
Hopefully at this point I don’t have to sell you on why React is awesome. What I can say is that React did live to its “Learn once, run everywhere” promise.
I was able to figure things out relatively quicker than I thought I would. Instead of writing “React for Web” code I was writing “React for Native” code. Instead of <div> and <span> I used the <View> component. Instead of <input type="text" /> I used <TextInput />.
You get the picture.
I admit, this is an oversimplification of my experience. If you’ve never run a simulator or seen a native iOS/Android project before you’re probably going to find yourself fiddling around here and there. Although React Native does a great job of abstracting away all of those parts for the most part.
At the end of the day once you’re up and running you’ll find yourself creating React components to represent your view layer. And that part is identical in nature to its React DOM counterpart.
It’s Flexbox
Flexbox’s layout awesomeness too is unparalleled. Anyone who has ever tried to center things in CSS before its existence will agree.
React Native implements a subset of CSS rules. Think of it as “CSS The Useful Parts.” Some CSS rules didn’t make sense in the native app context, while others are just relics from CSS’s 19 years of existence.
React Native forces you to style your components using JavaScript. This is an acquired taste, but it does pack a powerful punch.
Every React Native component has a style property which can take a JavaScript style object or an array of style objects which can override each other’s properties. This gives you all of the goodness and flexibility that comes from using preprocessors such SASS but without the syntax, compilation and source map headaches.
It’s JavaScript
Well that was the whole point wasn’t it? 😃
React Native runs on the JavaScriptCore JavaScript engine. This allows business logic to be written in JavaScript. You can use all of your favorite none-DOM related JavaScript libraries without a hitch. Lodash and friends run as expected.
React native shims both WebSocket and XHR, so libraries that rely on those web APIs will also run fine.
One thing to note is that while React + Babel JavaScript combo allows to run any ES6+ code easily, it doesn’t shim other web APIs. The “navigator.geolocation” and “localStorage” objects don’t exist for example. But They do have React Native equivalents.
It’s Native
The rendered UI components are native. Not native-like or anything like that, React Native views are the real deal.
You can also use native OS specific components of course. Finally you can use ViewPager on Android and TabBar on iOS if you wish.
Another popular option is to reimplement certain native components in pure JavaScript. This allows for easier cross-platform support and consistency.
The best part is even when you create pure JavaScript components, they render to native views. The end result is a much more “natural” feeling result than when running on a mobile browser.
The Dark Side of Mobile JavaScript Apps
This might come as a surprise to you, but you and I are not the only ones who are experiencing mobile web woes.
There are other libraries who are also trying to “Bring the web into native.” The most notable one is NativeScript, which is geared more towards the Angular 2/Enterprise crowd. Alibaba recently released its own open source framework in this space as well.
These initiatives are a blessing for the most part. But as with anything good, there’s some bad that comes along with it.
Let’s take a closer look at React Native. The whole point is that React Native allows you to bypass the browser altogether. Yes, you’re still using web technologies and JavaScript in your development process.
But I’m not quite sure that React + JavaScriptCore + Flexbox + XHR + WebSockets qualify as “The Web.”
By choosing React Native and the like, Web developers are no longer developing for the web. Even though it certainly still feels like it for the most part.
React Native is our Dark Knight
React Native does something incredible.
After dipping my toes with React Native I can honestly say that it does “Bring the web into native.”
I know some complain that React Native is hurting the web platform. But why should I be on the frontline defending it? Giants, like Facebook, Google, LinkedIn and pretty much every other web app recommend that I “Download the native app for a better experience.”
I refuse to create a worse product and hurt end user experience just because of an open web ideology.
And I definitely won’t do it while “Google Inbox” doesn’t even have a mobile web version.
The truth is that React Native is saving us JavaScript developers from continuing to create 2nd class mobile app experiences.
From looking with envy at the amazing experiences native mobile developers are churning out, without even breaking a sweat.
Web Platform evangelists may say React Native is not the hero JavaScript deserves. But I say React Native the hero JavaScript needs right now.
React Native is the framework to which mobile JavaScript apps will be compared to from now on. Web or otherwise.