7 ms·
React-Native is great, the only problem is that Facebook does not do enough to nurture the open source use of it, and this creates lots of extra work for teams
by resters 8y ago
React-Native is great, the only problem is that Facebook does not do enough to nurture the open source use of it, and this creates lots of extra work for teams using it.
Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb, which has little to do with RN itself.
But if you look at all of the github issues for RN you will see that many of them are open/unresolved for weeks with hundreds or thousands of +1s only to have someone at Facebook mysteriously close them, leaving a lot of people in the lurch.
We're also seeing a lot of API and internal refactoring fromi FB rather than focusing on the ecosystem, which indicates that inside FB it is more beneficial to say "I sped up x by 10% in react-native" than it is to improve usability for the many using it as an open source library trying to get something simple to work as expected.
- ryanwaggoner 8y agoSee, and I think that React Native is terrible, and Airbnb abandoning it clearly shows that their engineering culture is solid and not driven by cargo cult engineers chasing the latest fad.
- coldtea 8y ago>and Airbnb abandoning it clearly shows that their engineering culture is solid and not driven by cargo cult engineers chasing the latest fad. Depends on what they pick next (and why they picked RN before in the first place?), but as a standalone decision it's not enough to "clearly show" anything of the sort.
- eksemplar 8y agoI’m not sure about that. The ability to identify and accept a hard problem, and then do something about it, speaks of good management in their engineering department.
- ryanwaggoner 8y agoAgreed, it was a (probably too subtle) retort to the idea that them abandoning it clearly meant they’re a dysfunctional mess.
- resters 8y agoI use the Airbnb app a lot and have done so for years and there is nothing terribly advanced or unusual going on. It may have been a cargo cult decision to layer RN into whatever they had beforehand, but if so that increases the chance that evicting it was also a cargo cult decision. Read the blog posts, they had no approach to app-side state and it was essentially a battle between sub teams to see who could make their own ad hoc approach to state “win” organizationally and force other teams to deal with it when data sharing. Sounds like a nightmare both from a cultural and engineering perspective. It made it so the only way to get a unified engineering perspective was a political “purge” of RN adherents.
- cheriot 8y agoThey also started making enough money that the cost of two native development teams isn't a problem.
- Apocryphon 8y agoIt's certainly possible for both RN and AirBnB's internal organization to not be great.
- chrisco255 8y agoDiscord uses React Native, and they only have two developers on their iOS app. Millions of users, impressive app with high performance...two devs.
- ryanwaggoner 8y agoI haven’t used their app, but scaling an app isn’t actually that difficult if the backend can handle it. I don’t think that their use of RN is relevant here unless you think there’s no way that a native iOS app of similar complexity couldn’t be built by two devs? But then you’d have to explain all the counterexamples, or even where a solo dev builds an app that goes viral and gets millions of users...
- k__ 8y ago"airbnb abandoning it shows it's bad, but other companies using it successfully doesn't sbow it's good!"
- nv-vn 8y agoAbandoning something takes more work than using it, since it adds the cost of a rewrite. If Airbnb adopted framework X that wouldn't make me confident in framework X -- they haven't even used it yet! If they used it for a long time that would increase my confidence in X (in the absence of evidence to the contrary). But if everyone else started abandoning X I'd take Airbnb's experience with a grain of salt. I get that Discord is able to do well with it, but that doesn't mean everyone is able to do well with it depending on their needs. And who knows, maybe Discord is having just enough trouble that it hurts but too little to switch.
- chrisco255 8y agoThey give it rave reviews: https://blog.discordapp.com/why-discord-is-sticking-with-react-native-ccc34be0d427 https://blog.discordapp.com/why-discord-is-sticking-with-rea...
- 8y ago
- aplummer 8y ago> React-Native is great, the only problem is that Facebook does not do enough to nurture the open source use of it, and this creates lots of extra work for teams using it. Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb, which has little to do with RN itself. This is a very generalised opinion for a very specific technology with _many_ significant trade offs. React native can be excellent for one team, and terrible for a different team at the same time. It may be great in your specific circumstances, but I’d give Airbnbs mature engineering team the benefit of the doubt that it isn’t the right fit for them.
- resters 8y agoWell, if you read all the blog posts and read in between the lines a bit, they had a group of native developers who preferred to use their existing native skill set to build things, and since there was no unified approach to state, it became cumbersome to manage state between a hodgepodge of rn and native components. So already the deck is severely stacked against rn because of the lack of guiding architecture decisions. Then one can imagine how experienced native developers would end up with political leverage to evict rn, and by the time it happened it may have been the right choice. But if architecture is done correctly the main problems Airbnb had would simply not happen and many of those native devs would not have had to be hired in the first place.
- aplummer 8y agoThe fact that you have jumped to "speculate airbnb developers are unprofessional and their architects are bad" is definitely something you could think about. > Well, if you read all the blog posts > they had a group of native developers who preferred to use their existing native skill set to build things, and since there was no unified approach to state, it became cumbersome to manage state between a hodgepodge of rn and native components This is an immature straw man reducing their issues to one thing - it's a long blog series I have read (and presented back to clients in a series of case studies). I don't want to come in too hot because it's increasingly clear you are pretty fresh in your career, but taking this kind of negative view based on pure speculation is really going to be limiting for you. As I said, RN is great in some circumstances, but like any framework / tech there _is many_ cases and orgs where it is not a good fit.
- dep_b 8y agoI just had my first encounter with React Native and it wasn't a good one. It's the typical JavaScript dependency hell where things blow up at run-time with cryptical errors and tons of people on SO / GitHub just saying "use a lower version", to get another error and reading "this is fixed in the latest version" which was the one I was just coming from. This built on top of the iOS build system and everything is intertwined in both directions at least a few times. I've seen builds working starting the iOS app from command line, only to break _everything_ just starting the application from within Xcode. And Android? I didn't even look into it anymore. I think they're at 0.57 or something and that version number just wants to tell you one thing: We're going to break your shit some more in the near future before the dust finally settles.
- resters 8y agoWhat library/libraries gave you issues?
- zebraflask 8y agoI had a similar experience. The idea of React Native is pretty great, but the difficulty developing with it is a significant drawback.
- sudhirj 8y agoFlutter also has a bit of dependency hell at this point (might be better after it goes stable) - tried installing built_value (immutable data structures) and had a do a lot of dependency version tweaking and overrides.
- SomeCallMeTim 8y agoI'm hearing this complaint a lot about React Native in particular: That Facebook's "Move Fast And Break Things" philosophy is alive and well in the management of the project. Most recently the stories were about specific controls that worked on Android but on on iOS, and then the new version arrives, breaks the Android behavior but fixes the iOS behavior...or vice versa, sometimes for the same control, in a later release. I've heard better things about NativeScript; it's actually a more mature project than React Native, and has a lot of features that React Native lacks. And it's apparently a lot more stable. But fewer people use NativeScript, so it's possible that I'm just not hearing as many of the horror stories. Also curious about Weex. But I'm not making apps right now, so I haven't tried any of the above. People keep wanting to pay me lots of money to work on easy backend projects. Who am I to say no? :)
- deleted 8y ago[deleted]
- aphexairlines 8y ago> indicates that inside FB it is more beneficial to say "I sped up x by 10% in react-native" Are FB's internal goals related to improving their open source projects or related to improving FB products that might happen to use their open source projects? In most companies that would be the latter.
- d0m 8y ago>> Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb I could be wrong here, but from what I understood the cost of maintaining a hybrid RN + fully-native apps > full-native apps. I.e. What airbnb would gain by not having to code both android/iOS was lost by having to deal with all the RN non-sense (third-party libraries being deprecated, very fast non-backward compatible changes, etc.) but also having to always bridge the gap between what was RN and what was truly-native. At the end of the day, you look at your time and you realize that you spend more time trying to make it work with RN to "save time" rather than just coding it on both platform. But then, most people using RN don't have to deal with this issue because they don't have an existing non-RN code base to bridge with RN.
- vibrato 8y agoThis mirrors my experience working with Xamarin. You had to know both everything going on at the native level and the c# .net and Xamarin levels as well.
- pjmlp 8y agoThis is why I always advocate for platform languages on production code. Too many hours spent in the past writing FFI code, tracking down bugs not knowing if they were on the platform or 3rd party language runtime, missing integration with platform tooling. Naturally I don't always succeed at that.