The document is a presentation by Lyubomir Bozhinov about exploring React Native. It discusses his background in native and hybrid mobile development, provides an introduction to React Native including its benefits of cross-platform development and native UI performance. It also covers a sample project called ReadTune that was created with React Native and discusses some of the challenges encountered. It concludes by thanking sponsors and sharing a final thought about continually pursuing new opportunities.
Beginners Guide to TikTok for Search - Rachel Pearson - We are Tilt __ Bright...
Exploring React Native
1. Aug 11, 2018
Exploring React Native
const info = {
name: “Lyubomir Bozhinov”,
title?: “Senior Software Developer”,
company: “Bulpros”
};
A Web Dev’s Journey in the Land of Mobile
2. Aug 11, 2018
agenda();
• Brief Intro
• The Road So Far…
• React Native
• ReadTune
Lyubomir Bozhinov Exploring React Native
3. Aug 11, 2018
The Road So Far…
• Native
o Android (Java || Kotlin)
o iOS (Objective-C || Swift)
• Hybrid
o Apache Cordova
o Xamarin
• Da future?
Lyubomir Bozhinov Exploring React Native
6. Aug 11, 2018
The Good
• Write What You Know
• Easy-to-Debug
• Great Documentation
• We get to use JS to build mobile apps!
Lyubomir Bozhinov Exploring React Native
7. Aug 11, 2018
The Bad
• Steep(ish) Learning Curve
• Change of Context
• Tech Limitations
Lyubomir Bozhinov Exploring React Native
8. Aug 11, 2018
The Ugly… Or Why Use It?
• return ‘webDev’ === ‘mobileDev’;
• Woes of the Async Bridge
• You Are Not Alone
• We get to use JS to build mobile apps!
Lyubomir Bozhinov Exploring React Native
14. Aug 11, 2018
A Final Word…
• ‘I think if you do something and it turns
out pretty good, then you should go do
something else wonderful, not dwell on it
for too long. Just figure out what's next.’
Lyubomir Bozhinov Exploring React Native
Editor's Notes
Hello, everyone! My name is Lyubo and I like to build cool stuff. We’ll come back to that later - it’s important. But more important is the fact that we’re all here because we like beer. Or code… I keep forgetting which one it was.
So, I’ve been working as a Software Developer at Bulpros for a while doing web stuff, experimenting with the next JavaScript craze, and trying to learn something new every day. Which is not very hard, considering that we have a new Framework of the Day every six months or so.
So, what are we going to talk about today? The intro. That’s done, thankfully. Now we can move on to the interesting part…
We’ll talk a bit about the different approaches to mobile development… the current landscape, so to say.
Then we’ll see what all the hype surrounding React Native is about. Spoiler alert: RN is awesome.
Finally, I’ll tell you a bit about a small project I did using RN and the lessons learned from that.
Native (Java, Kotlin, Objective-C, Swift)
Mobile has been quite the contented domain lately. What I mean by that is simply the fact that on top of Native (Java for Android and Swift or Objective-C for iOS), we have hybrid (think Apache Cordova). And now we have something else entirely. But is it better?
Hybrid
At a glance, Apache Cordova is a great fit for cross-platform mobile app development, if you’re coming from the web. It allows you to use HTML5, CSS3, and JavaScript and it runs on both platforms. Applications execute within wrappers targeted to each platform, and rely on standards-compliant API bindings to access each device's capabilities such as sensors, data, network status, etc. Cool, but it’s in a WebView… and there’s a performance hit – not a huge one, but it’s there. And there are other disadvantages (expand here during talk).
Xamarin is just there because I like C# as a language. It’s what Java could have been.
True Native
So what does RN have over hybrid. What does it do better? In my opinion… just about everything.
Let’s start with why it’s called native. You write JavaScript – React, to be more specific. The JS communicates with and creates native components. The communication occurs through the so-called "async bridge". And that’s it – a very brief and lousy explanation of the RN architecture. The only bottleneck is the async bridge (compare with hybrid). If at any time you feel that this communication slows things down too much, you can choose to implement the functionality in the respective native languages. You can then easily link those native modules to your RN project. But I’m getting ahead of myself.
The good news is, there is an upcoming re-architecture. RN is version 0.56 as of this talk. It’s still young and full of potential.
So we touched on the what quite a bit in the previous slide. But the gist of it is: you write the code once and it runs on both platforms. Of course, it’s never that simple, now, is it?
Main selling points are:
Cross-platform: one codebase, two platforms.
Code reuse: You can transfer code from a React app into a React Native app (helpers and other common files are one obvious choice for modules used across projects).
Know-how and Skill reuse: If you know React, then you (sort of) know React Native
Native UI and performance: You get a native app in all senses of the word
Link any native module you want (your mileage may vary).
o As a web dev, you can write what you know. So, you know, the best thing is the ease of use and familiarity of RN.
o Another advantage (from a certain point of view): All the debugging tools still (sort of) work
o React Native also continues React’s tradition of great documentation. The docs are really easy to use, and by use I mean copy-paste snippets until you have a working app. Warning: try to understand what the code snippets do first. Same goes for stackoverflow code.
o Get to use web technologies to build mobile apps
o There is a barrier of entry. And what I mean by that is, you need to know React. Or learn it. Or want to learn it. For people from the Angular or vanilla world, that might be a deterrent. But come on, go learn React – it’s really cool.
The next two disadvantages are a bit more disadvantageous:
o Still, RN is a change of context. Mobile is different. It’s as simple as that. Reasoning about mobile first web apps – or even PWAs – differs from thinking of mobile UX and UI. It takes some getting used to.
o Finally, we come to tech limitations. Remember that async bridge. Currently, that’s perhaps the biggest issue with React Native. JS is async by nature. And that bridge was designed to be asynchronous, serializable, and batched (back in 2013? when they started working on it).
An asynchronous bridge means you can't integrate JavaScript logic directly with many native APIs expecting synchronous answers.
A batched bridge that queues native calls means it's harder to have React Native apps call into functions that are implemented natively.
And a serializable bridge means unnecessary copying instead of directly sharing memory between the two worlds.
For apps with complex integration between React Native and existing app code, these restrictions are quite frustrating.
o Web dev === mobile dev. While RN doesn’t make us as web people true mobile developers, it opens wide a door into that realm, and it’s up to us how far we can venture.
o Woes of the async bridge. The truth of the matter is, for apps that are entirely built in React Native, the restrictions I talked about earlier are usually bearable. It’s huge, complex projects that are likely to come up against those barriers - although the Facebook team somehow manages to use RN in their mobile apps (I read that in the RN blog, I think). Anyway, moving on…
o You are not alone. RN has a great community that you can rely on for code advice and cool solutions. For example, adding Native modules to your project doesn’t mean you have to write them yourselves. The RN community is great at wrapping up Native functionality in well-documented npm packages. It’s just a matter of finding the right one… but you know the drill.
o Finally, I can’t stress this enough… We get to use web technologies to build mobile apps. I know I’ve said this a few times already, but it bears repeating. And on that note, let me tell you about a small experiment I did with RN (if we have time left for that).
I’d like to tell you about a small side project of mine. It’s called ReadTune, and as far as I know, it's the first app that lets you generate a playlist based on the book you are currently reading.
What happens when we mix music and reading? I mean, I do it all the time… I listen to music when I read. Why not?
What happens is… this – the result of my humble efforts to unite the two.
I was tinkering with RN when I came up with the idea – trying out different stuff and musing on how I might use them in a real-life situation. Thinking how this might be applied to a large project like the one face every day (extend with thoughts about MVPs, POCs, etc.).
Then the idea for ReadTune hit me, and it sounded cool in my head, and I decided to build it for myself. By which I mean, I decided to create an app that just barely fit the definition. But then I thought, why not make it (relatively) usable and share it with the world?
The app is available for download from the Google Play Store, and it’s completely free - there is no upfront cost, and no ads, subscriptions, etc. However…
o There is no iOS version… I only released it in the Google Play Store. But we can all probably guess at the reason: I have not invested in Apple hardware (which you need to actually build your code for that platform) or in their developer license… for the time being, at least.
o Complexity. I will admit that I completely underestimated how fast the code would grow. There is no such thing as a small project, after all – this one ended up with 111 commits in about two months… Around commit number 30, I ended up with a 2000-line component… which pushed me to the other extreme:
o Over-engineering. I toyed with the idea of pulling in about ten dependencies at that point. I thought I just needed Redux, that it would solve all my problems. Who knows, perhaps at some point in the future, I might even rewrite the code to include it. But I decided against it – and made several such decisions… because it still is a small side project… And there is always another way: functional setState came to the rescue in my case (show a bit of code).
Before I finish, I’d like to say a quick thank you to these four companies for bring us all together for this nice event…
Building ReadTune was a difficult process, but in the end, I’m happy that I went on this journey of discovery. And it most likely would not have happened without React Native…
I hope this was as interesting for you as it was for me. Now all that remains is to wrap up this talk with the quote you see on the screen:
(Pause)
We have the ability to create wonderful things, to do great things. Or at the very least, to build cool stuff.
Let’s go do it. Thank you!
