5 ms·

Many comments here are comparing this transition to the one Airbnb did a few years back. These two transitions could not be more different. Coinbase decided t

Many comments here are comparing this transition to the one Airbnb did a few years back. These two transitions could not be more different. Coinbase decided to greenfield their new apps, Airbnb (attempted) to brownfield it. I've worked with a number of clients that have gone down the same path that Airbnb did, from a business perspective it makes perfect sense, keep what you have and slowly move over, but the technical reality is this will be a complete dumpster fire and you will probably fail. When you try to convert a native app to React Native everything that makes React Native wonderful to work with just seems to break. Hot reloading either barely works or not at all, load up times increase exponentially, the app just becomes a pain in the ass to work with because nothing seems to work like it should. Whenever companies propose this I always shoot down the idea and recommended a rebuild in React Native from the ground up. Doing so will take just as much time as browfielding because when you try to do a native -> react-native conversion it always seems to go south somewhere, either slowness, having to write 3x the code, or other problems.

raspasov 5y ago
Right on point. I have done a lot of React Native but never tried to mix native + React Native (with the exception of the occasional native feature in a mostly RN project). Mixing an old native project with RN, doing a so called "slow transition" sounds like a really bad idea. Data communication between the native part and React Native will become an issue, you're effectively going to be running a mini distributed system within your device. There's probably 100 other problems that I can't even start to imagine. Perhaps a super experienced, world class expert in both JS and mobile development + runtimes can pull it off but I wouldn't be comfortable trying to do it (been doing mobile development directly since 2016 and have been close to mobile dev since ~2011). Re-write is a better option.
ryndshn 5y ago
if i remember correctly, Airbnb had many issues with RN that were not related to their incremental migration, such as the issues they had with things like debugging, where it was almost impossible to fix certain bugs due to RN using different JS engines depending on platform and context (for ex running with a debugger causes RN to use V8 whereas running locally on iOS / Android it uses JavaScriptCore or Hermes, respectively). RN is awesome but imo has some pretty serious pain points.
- raspasov 5y ago
  RN used to have a lot of issues years ago (~2015-2016 or so) with different layout rendering between iOS and Android. Since they re-wrote their layout engine to be the same codebase across Android and iOS this has been 99% fixed in my experience. You might very occasionally run into a difference of some sort but it will most likely be minor. Of course, I would say if you've never done a RN project before and you plan to release both iOS and Android, please DO test your app frequently on both as you code along. If you complete 90% of the code on, say, iOS only and then try to run it on Android, chances are you'll run into more WTH problems than if you were checking along the way.
  - ryndshn 5y ago
    none of the issues i described are different now. RN on iOS still uses JavaScriptCore by default, Android uses Hermes, and it still uses V8 if debugging, meaning it's possible you'll have some super weird edge case bugs. in Airbnb's situation i believe they said it was almost impossible to pinpoint the issue due to the differences in these engines. it's unlikely, but still an unavoidable thing that could be a serious roadblock
    - raspasov 5y ago
      I've done and ran 2 medium sized apps on both iOS and Android and have never ran into such problems. While not impossible, that's akin to saying that if you run the JVM on MacOS vs Linux, there's a chance of different behavior. Possible, but unlikely. It shouldn't be a show-stopper for most situation.
      - ryndshn 5y ago
        ehh, not really. JVMs are all developed under the same roof but JS engines are a little more distributed and the spec has a little more room for interpretation. i agree it's unlikely, but still not ideal
        5y ago
macando 5y ago
What a trope that AirBnB story has become. They mixed their gigantic native codebase with React Native code. Mixing native and React Native = bad. Doing pure React Native (for everything but ultra high-performance and apps that interact tightly with hardware) = good.
- _fat_santa 5y ago
  I remember there were a ton of articles and hot takes around that time that dunked on RN with zero context, essentially saying that RN was dead because Airbnb couldn’t crack it. I feel like all those takes completely misunderstood or ignored Airbnb’s technical constraints and the underlying reasons. Anyone blamed it on the library. Not the dumpster fire implementation that ultimately killed the venture
  - jamil7 5y ago
    Yeah a lot of it is context. I got the feeling from those articles that airbnb has some really strong platform specialists and if you already have two teams of people like that you can likely get more out of letting them focus on their respective platform.
danielrhodes 5y ago
There’s a huge incentive for the company to invest in this. Being multi-platform has a huge cost to small and big companies alike, as the blog post was alluding to. The way I see it: in the early days of the web, JavaScript was very slow and browsers were operating on weak CPUs. But there was a turning point and suddenly JavaScript was now fast enough and Web 2.0 was born. A similar thing is happening with React Native. It is kind of slow on older phones, and it felt very kludgy when it was first released. But things have gotten better and most important of all: phones have gotten substantially faster. You still have to learn how to make high performance React Native apps, compared to React in the browser where it’s more forgiving. But this is no different than native. So I think there is reason to believe it has gotten to a point where this could be a long term decision.
EvilEy3 5y ago
> Hot reloading either barely works or not at all, load up times increase exponentially, It works like this even on hello world apps. The only platform where Hot Reload works reliably on mobile is Flutter.
- itsjzt 5y ago
  You should check out next.js's live reload
  - EvilEy3 5y ago
    On mobile?
    - itsjzt 5y ago
      Its a web framework you can test it on your mobile
Ozzie_osman 5y ago
The airbnb transition also had (from what I heard) a lot of politics around it. Often the things that make or break large projects aren't necessarily technical but human. For instance, if you hire a ton of native developers and force them to move to React Native without getting buy in from them, you're probably bound to fail. There will always be technical challenges with any large project. But getting buy in from the right people can make those problems surmountable.
ds300 5y ago
Artsy.net has had quite a bit of success with a brown field RN app. We adopted RN in our iOS app in 2016 and gradually used it to render more and more screens in the app. In 2020 we decided it would be nice to have an android app, and we spent the last year incrementally refactoring the app infrastructure from Objective-C to TypeScript to support that. Crucially we did the entire thing with a tiny team of 1-3 people and without blocking any product engineers from shipping new features. We had occasional tooling issues like you describe but all fixable. I'd be happy to go through the same process again.

raspasov 5y ago

Right on point. I have done a lot of React Native but never tried to mix native + React Native (with the exception of the occasional native feature in a mostly RN project). Mixing an old native project with RN, doing a so called "slow transition" sounds like a really bad idea. Data communication between the native part and React Native will become an issue, you're effectively going to be running a mini distributed system within your device. There's probably 100 other problems that I can't even start to imagine. Perhaps a super experienced, world class expert in both JS and mobile development + runtimes can pull it off but I wouldn't be comfortable trying to do it (been doing mobile development directly since 2016 and have been close to mobile dev since ~2011). Re-write is a better option.

ryndshn 5y ago

if i remember correctly, Airbnb had many issues with RN that were not related to their incremental migration, such as the issues they had with things like debugging, where it was almost impossible to fix certain bugs due to RN using different JS engines depending on platform and context (for ex running with a debugger causes RN to use V8 whereas running locally on iOS / Android it uses JavaScriptCore or Hermes, respectively). RN is awesome but imo has some pretty serious pain points.

raspasov 5y ago
RN used to have a lot of issues years ago (~2015-2016 or so) with different layout rendering between iOS and Android. Since they re-wrote their layout engine to be the same codebase across Android and iOS this has been 99% fixed in my experience. You might very occasionally run into a difference of some sort but it will most likely be minor. Of course, I would say if you've never done a RN project before and you plan to release both iOS and Android, please DO test your app frequently on both as you code along. If you complete 90% of the code on, say, iOS only and then try to run it on Android, chances are you'll run into more WTH problems than if you were checking along the way.
- ryndshn 5y ago
  none of the issues i described are different now. RN on iOS still uses JavaScriptCore by default, Android uses Hermes, and it still uses V8 if debugging, meaning it's possible you'll have some super weird edge case bugs. in Airbnb's situation i believe they said it was almost impossible to pinpoint the issue due to the differences in these engines. it's unlikely, but still an unavoidable thing that could be a serious roadblock
  - raspasov 5y ago
    I've done and ran 2 medium sized apps on both iOS and Android and have never ran into such problems. While not impossible, that's akin to saying that if you run the JVM on MacOS vs Linux, there's a chance of different behavior. Possible, but unlikely. It shouldn't be a show-stopper for most situation.
    - ryndshn 5y ago
      ehh, not really. JVMs are all developed under the same roof but JS engines are a little more distributed and the spec has a little more room for interpretation. i agree it's unlikely, but still not ideal
      - 5y ago

macando 5y ago

What a trope that AirBnB story has become. They mixed their gigantic native codebase with React Native code. Mixing native and React Native = bad. Doing pure React Native (for everything but ultra high-performance and apps that interact tightly with hardware) = good.

_fat_santa 5y ago
I remember there were a ton of articles and hot takes around that time that dunked on RN with zero context, essentially saying that RN was dead because Airbnb couldn’t crack it. I feel like all those takes completely misunderstood or ignored Airbnb’s technical constraints and the underlying reasons. Anyone blamed it on the library. Not the dumpster fire implementation that ultimately killed the venture
- jamil7 5y ago
  Yeah a lot of it is context. I got the feeling from those articles that airbnb has some really strong platform specialists and if you already have two teams of people like that you can likely get more out of letting them focus on their respective platform.

danielrhodes 5y ago

There’s a huge incentive for the company to invest in this. Being multi-platform has a huge cost to small and big companies alike, as the blog post was alluding to. The way I see it: in the early days of the web, JavaScript was very slow and browsers were operating on weak CPUs. But there was a turning point and suddenly JavaScript was now fast enough and Web 2.0 was born. A similar thing is happening with React Native. It is kind of slow on older phones, and it felt very kludgy when it was first released. But things have gotten better and most important of all: phones have gotten substantially faster. You still have to learn how to make high performance React Native apps, compared to React in the browser where it’s more forgiving. But this is no different than native. So I think there is reason to believe it has gotten to a point where this could be a long term decision.

EvilEy3 5y ago

> Hot reloading either barely works or not at all, load up times increase exponentially, It works like this even on hello world apps. The only platform where Hot Reload works reliably on mobile is Flutter.

itsjzt 5y ago
You should check out next.js's live reload
- EvilEy3 5y ago
  On mobile?
  - itsjzt 5y ago
    Its a web framework you can test it on your mobile

Ozzie_osman 5y ago

The airbnb transition also had (from what I heard) a lot of politics around it. Often the things that make or break large projects aren't necessarily technical but human. For instance, if you hire a ton of native developers and force them to move to React Native without getting buy in from them, you're probably bound to fail. There will always be technical challenges with any large project. But getting buy in from the right people can make those problems surmountable.

ds300 5y ago

Artsy.net has had quite a bit of success with a brown field RN app. We adopted RN in our iOS app in 2016 and gradually used it to render more and more screens in the app. In 2020 we decided it would be nice to have an android app, and we spent the last year incrementally refactoring the app infrastructure from Objective-C to TypeScript to support that. Crucially we did the entire thing with a tiny team of 1-3 people and without blocking any product engineers from shipping new features. We had occasional tooling issues like you describe but all fixable. I'd be happy to go through the same process again.