Aaron Greenwald is an energetic speaker: smart, informed and more than willing to share his insights as Software Developer at Wix. He was guest speaker at our React Native event in Sofia last month, and had lots to say in front of an appreciative audience about how this JavaScript framework is changing the face of app development.
In between Aaron’s technical sessions with our developer Rossen and the team, we sat down in the Despark kitchen and I asked him in layman’s terms more about why React Native is important, what its time-saving benefit is, and what we should watch out for in the future.
If you’re not au fait with the terminology or technology (it moves fast), let’s just briefly talk about what React Native is.
React Native is a framework for building native apps. It was developed and released (in 2015) by Facebook so the wider community could use it. It leverages the JavaScript libraries and modular approach of React to enable native development of apps while reusing a large amount of core code across platforms. There are many benefits (and a few downsides) to this, as you’ll see. For a more comprehensive overview, watch Aaron’s introductory talk.
The theme of Aaron’s talk in Sofia was code reuse in React Native. When Facebook released React Native to the public, they publicised the inherent reusability of its code, suggesting that 85% reuse was an achievable prospect. So, does it deliver?
Aaron Greenwald: When you write code in React Native, by default you get tons of code reuse, which is great, because the time to market is much smaller. Where it struggles to deliver is performance — which is the whole reason you went with writing native apps in the first place, so it’s a big deal — but don’t get me wrong. It’s not nearly as bad as using PhoneGap, or a lot of its predecessors, or us writing a mobile web app. I think that React Native today covers the 80% case very well. Probably the 90% case.
Now most people are delusional and think that they’re the ten percent. Everybody thinks that they’re the next Mark Zuckerberg. The reality is that most likely nobody will use your app, and for most startups or early ideas the biggest threat, the biggest risk, is time.
The clock. And what’s going to screw you over is not if your app has super smooth performance, it’s that you didn’t get to market fast enough, or your product didn’t fit the market, and you should have pivoted or adapted early, but you didn’t know that because you spent a year building a really cool animation.
So for most people React Native is a good fit, and it’s certainly better than the other options, and for most of your [Despark’s] potential clients, React Native’s a really good fit. And I don’t mean just for the proof of concept phase — for the first six months — no, for the first three years.
You’re delusional if you think you’re not going to rewrite your app anyway; if you’re successful, you’re going to be rewriting multiple times.
Jo Bradshaw: You should be rewriting and optimising…
AG: In five years, the whole thing is going to be different. WhatsApp today is not WhatsApp five years ago. If I was in charge of WhatsApp I’m not going to say ‘let’s write it in React Native,’ that would be stupid. But that’s because you already have a billion-odd users.
JB: But if you’re a person who wants to test the market, wants to get to a minimum viable product or test an assumption…?
AG: I think it’s a good option. Not only is it a good option, I think that it’s the right option in most cases. And by the way, I don’t just mean for testing. If you’re a bank, it’s the option. I have multiple banking apps on my phone, and some of them are much better than others. They’re not games. They don’t need the kind of UI animations that gaming needs. What they need is functionality, and to be relatively smooth, and not have me sitting staring at a loader while I’m trying to transfer money. That’s a very good fit for React Native. In the long term, not in the short term.
If you’re a bank, you probably have in-house developers, but you want to have a team that can work on product features and things like that, and implement design. You don’t need to have somebody spending a year on some cool animation, it’s not important, so React Native’s a very good fit for you.
If you’re a startup working on the next social network, it’s probably a good fit for you as well, but for a different reason. It’s a good fit for you because you’re going to fail, probably, so you may as well fail fast. And if you succeed, you’ll rewrite.
JB: It’s going to cost you less money…
AG: Exactly. I say this cynically but yes, it’s a faster way to get to the market and find out whether or not you’re going to succeed. For different reasons with the bank and the next social network, you should start with React Native.
The big news is that Airbnb is leaving React Native, right? But if you’re Airbnb, is leaving React Native a good choice? Probably.
JB: Is that to do with the maturity of the company, the app?
AG: Airbnb doesn’t have to decide whether or not people are going to use their app. There’s no testing for market fit, they know people want the app. There’s no budget concern of ‘how can we get to market quickly? We only have a team of five people,’ they have a team of a hundred people regardless.
If you’re a team of three people, then three React Native developers are better than having one and a half of each [iOS and Android]. But if you’re a team of forty, then twenty Android and twenty iOS might not be such a big difference versus forty. At that point you start dealing with other concerns like the last ten percent, the performance, the different impacts. Airbnb really cares about those animations.
They’re the case I said about the social network that’s most likely going fail, might succeed: in that case start with React Native, move later if you succeed.
JB: So, going back to the smaller startups that are wanting to do something new: presumably if React Native is going in the direction where more and more people are contributing to open source then it’s easier to find and reuse code and thus move faster?
AG: Yes. One of the other benefits I mentioned in the Intro to React Native talk — one of the big draws of React Native — is that you have access to the largest open ecosystem there is — NPM. NPM is, among some parts of the developer community, maligned, but at the end of the day, for almost anything you want to do, there’s already something available for it.
Lots of the building blocks are prepared by the community for you, so that also helps with the bulk of the velocity; you’re getting things done faster. React Native is young, so there are some things that might not be available, but every day there is new stuff.
JB: I like what you said [at the talk] about a) don’t be scared to contribute to open source: even if you think the thing you’ve written is a little bit dodgy, it’s better to put it out there so that other people can build on it and use it…
AG: Yeah.
JB: and b) being open source from day one forces you to separate your code out: you’ve got the logic that’s separate, and all of your business stuff is kept in a separate layer and it’s not in that core logic. Can you speak a little bit more about that as a philosophy?
AG: In general, among software developers, modularisation and code reuse is the holy grail. You always want to be able to reuse your code and architecture; a lot of what architecture focuses on is how to organise your code. There are different types of architecture, but when we talk about application architecture, not at the system level but inside the codebase, often a lot of it’s about ‘how can I organise my code into modules, pieces, components, in a way that things will be maximally reusable?’
One of the often-quoted principles is the single responsibility principle: every function or piece of functionality should do one thing and do that one thing well. If a function does two things, then later when I only need one of those things, I won’t be able to reuse it, but if it does one thing and I compose my app of many little pieces, then I can.
This applies when it comes to realising I’m building an app and this thing I’m spending a lot of time on I might be able to use in another part of the app, or another one of my apps. So if it’s another part of the app you separate it out into some component to be reused within the app. If it’s something you realise is generic, not specific to this app, then you take it out of your app and you put it in some kind of library: that’s just part of your toolbag now and you can use it in any app.
Making it open source forces you to do that because nobody else wants your business logic.
They don’t want the use case that you have, it isn’t relevant to them. So when you open source it from day one, you are forced — naturally — to think every time you want to write some code, ‘wait, is this part of the generic implementation of the calendar [for example] or is this really something that relates to my calendar?’ By separating your code out, you automatically have this kind of signpost helping you decide what goes where.
JB: Have you guys at Wix done a lot of that? You must have contributed quite a lot to open source by now?
AG: As a team, yes. Particularly in the mobile side of Wix, but also at Wix generally we’ve been supporting open source. It’s a practical thing that makes sense to do. When it’s not your core product but you open source it, what you end up with is more people using your code, which helps you find bugs faster.
JB: So the quality goes up.
AG: The quality goes up. Potentially it forces you to think about what goes where. You will be able to reuse your code in other places because if other people can use it, then you can surely reuse it. It forces you to make your code logical to be reusable, and then it ends up being usable to other parts of your group company.
If it ends up being popular enough, then other people contribute back. For example our navigation solution for React Native has become fairly popular and we built it because we needed it: the out-of-the-box solutions weren’t powerful enough performance-wise, so we built our own. We open sourced it because we realised that ‘nothing is particularly Wix-y about this, anybody can use this’ and in doing so we’ve had other people help us with it. If there are bugs, people report them.
JB: Certainly for developers who are wanting to get into React Native: that gives them quite good fodder for playing around, testing ideas, if they’ve already got things they can start experimenting with?
AG: Sure, yes. If you’re a solo developer or small team and maybe right now you don’t have the bandwidth to build everything from scratch, you can go and download a couple of things and start building your idea on top of it, and at some point you will either graduate from it or not.
JB: Have you got anything else to say about where React Native is going in the future?
AG: Yes. React Native won’t be here in ten years. Don’t get too married to it. I mean, it might be here but it won’t look the same and most of us probably won’t be doing React Native. People become very invested in these kinds of frameworks. And then there’s all sorts of drama around things like Airbnb’s announcement because they’re one of the big companies using these libraries. Well, who else is using it? Wix is still using it…but that shouldn’t be the question. You know, ten years is a long time in our business — five years is a long time — things change.
Don’t get too attached to one framework or another. You’re going to have to change. You’re going to have to adapt and rewrite. The business we’re in is fast moving. You place your bets and you hope you win, and if you don’t, then that’s life. Anybody who tells you that they know what the future is is lying.
JB: Is it not useful in any case — and all of these technologies over the last twenty years — have they not been useful in teaching us how to better think, how to better think about design and how to engineer things better?
AG: Certainly. If you learn a framework, and then that framework goes away like a dodo and you have to learn a new framework, it wasn’t a waste. When I was in college I learned WinForms and the fact that I learned WinForms broadened my mind. I noticed something when I was learning Angular for the first time. The Angular documentation was written for people who knew JQuery. Maybe not intentionally, but it was written by people who came from JQuery for people who came from JQuery.
If you were starting to learn to code for the first time and you were trying to learn Angular, it took you longer than if you were coming from JQuery. So new frameworks aren’t born in a vacuum, they’re building on previous ones, or evolving from previous ones, even when we say ‘this is a totally revolutionary idea’ it’s not, it’s taking the old ideas, deconstructing them, saying ‘all these things weren’t good: here’s some new things.’
The more frameworks you learn, and as you go through your career as a developer, the more different approaches you digest, you become faster at digesting new ones, learning new ones, and having a perspective on what the new ones do well and badly, so it’s definitely not a waste.
. . .
We had a great few days with Aaron in our Sofia office, where he spent quality time meeting our team of developers (who are busy building apps in React Native as we speak). If you want to connect with Aaron, check out his website or Twitter.
If you’re curious about career opportunites at Despark, have a look at our developer vacancies.
Thanks to Stoyan Ilchev and Rossen.
