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.
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? :)
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.
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.
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.
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.
No offense to the Discord iOS developers, but their apps is neither “high performance” nor impressive. It’s outright janky at times.
The Android version suffers the same but moreso.
It’s kind of like saying your frontend framework is awesome because it scales to millions of users. Well yeah, they’re all running it on their own machines, so assuming you can deliver the code to them and the backend can handle it, you could scale to quadrillions of users.
I do think that scaling an app to millions of users says basically nothing on its own about the app framework / code quality itself. You’re scaling across as many devices as you have users. There’s no challenge at all there on the mobile dev side.
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.
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.
> 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.
Not at all, I focused on the one thing that was mentioned as the most significant reason for team frustration with react native.
> I don't want to come in too hot
No worries
> it's increasingly clear you are pretty fresh in your career
I was thinking the same thing about you, no offense.
> but taking this kind of negative view
Not sure what you found negative about my view. Teams and individuals make mistakes and misjudgments. That is part of life. If you read my comments I said that removing RN was probably the right thing to do by the time it happened. This is often the case with bad technological decisions in startups and is rational because of sunk cost.
> many_ cases and orgs where it is not a good fit
This is why I cite architecture. With react or react-native you really need to know where the data is coming from and how the data will flow through the application. I'm arguing that the architect should have had a plan for how this would work before introducing react native into the app.
Airbnb has done a lot of great react-native work, so I know the issue isn't technical competency, but the linting rules Airbnb popularized suggest a very trees-oriented (not forest oriented) perspective on tech, which is the kind of perspective that makes the above kind of mistake.
Cool reading your other comments too I realise I’m getting trolled at this point so I’ll finish up here.
In other words you have no rational or thoughtful response and have for the second time decided to use ad hominem attacks, this time the highly sophisticated one known as name calling.
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.
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.