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.
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.
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.
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.
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
<span> I used the
<View> component. Instead of
<input type="text" /> I used
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.
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.
Well that was the whole point wasn’t it? 🙂
React native shims both WebSocket and XHR, so libraries that rely on those web APIs will also run fine.
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.
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.
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.
From looking with envy at the amazing experiences native mobile developers are churning out, without even breaking a sweat.