Comment by mythz | Hacker News Reader

Comment by mythz | Hacker News Reader

Parent Full thread

This release follows Airbnb posts describing their deep experience in React Native and why they ended up abandoning it: https://medium.com/airbnb-engineering/sunsetting-react-nativ...

Based on the issues they've had with React Native [1] I believe they would've had a better experience with Dart and Flutter which also has a fast iterative dev experience with a productive language that lets you build both iOS and Android Apps from a single code-base. But in contrast to RN, Dart 2 is statically typed and AOT compiled into native ARM which enables better performance and doesn't have any of the JS VM issues Airbnb kept running into. I also prefer Flutter's x-plat approach of drawing all their widgets with Skia as it also mitigates the UI widget inconsistencies they would've had if they tried to wrap native widgets. Flutter widgets follow Material design by default but can also be themed to look like native iOS widgets (https://flutter.io/widgets/cupertino/).

React Native nails the development experience but is plagued with issues which isn't clear if it's because it's architecturally flawed or that it's just poorly resourced and Facebook only cares about resolving their own issues.

I've been burnt by the lack of support in React Native indiscriminately closing issues, which stopped me from wasting my time reporting any more issues and eventually stopped using React Native altogether.

I've been pleasantly surprised by Flutter, it does what it says on the tin, enables a productive dev environment for creating Native Apps from a single code-base and in contrast to my RN experience their support has been stellar, several team members responded to my queries immediately with solutions and workarounds.

The biggest issue I've run into coming from JS/RN is not being able to use reflection due to iOS's AOT restrictions for which you'll need to use code-gen to workaround. Also I prefer JSX for designing UIs, whilst Dart's object declarations enable a kind of code DSL it's not as composable as using a declarative XML markup where you can freely move widgets around to design UIs. Ultimately I hope they provide a similar language feature for using an XML-like markup as an alternative for (and just transpiles to) object declarations.

  [1] https://medium.com/airbnb-engineering/react-native-at-airbnb-the-technology-dafd0b43838#4b2b

> it's just poorly resourced and Facebook only cares about resolving their own issues.

I'm not sure this is _the_ cause for anything, but it's definitely something that happens. I've seen obvious bugs lingering forgotten on RN just because it's not something they're interested in resolving.

And before someone mentions "open source" some of those are deep structural problems that not anyone can just come and fix since they'd have side effects all over the code base. I've also seen actual fixes lingering for months until someone would decide to review or approve it.

> Facebook only cares about resolving their own issues

One could argue that Google suffers from this weakness as well.

Hasn't been my experience with Flutter, it looks like a well resourced project with a very talented team who are committed at building a high-quality and productive tool for developing Mobile Apps and are actively supporting their existing user base.

React Native feels like an in-house development project they've open sourced but don't have the resources to resolve external issues so they've instituted a policy of routinely indiscriminately closing and signalling their intentions to never fix them and by extension removing any visibility of which issues still exist and from anyone else being able to resolve them either. They've done this for 1000's of issues - not going to invest in a platform plagued with issues that stands no chance of being resolved.

I think proactivity and a knowing a good platform to ask questions in, helps. For some of us, the difficulty is often whether to ask on StackOverflow or to open a bug on Github.

An overflow of Github issues can lead to some issues going unnoticed (depending on whether issues are regularly triaged by a team).

For example, I have a Flutter Android app that has an infinite notification loop bug [1]. I've struggled for many hours (spread over a few weekends) trying to figure out what was wrong. I eventually opened an issue on GH after giving up.

After a few days, I decided to post a question on SO, and someone from the Flutter team saw it. The issue might have gone unnoticed for a bit if I hadn't done so (especially given its obscurity). I believe so because popular projects on GH get a lot of issues, and yours might get buried if someone doesn't pick it up immediately.

The other thing is that when we open issues, and project maintainers try to work with us, we often delay in responding to them. That over time, leads to issue clutter, and probably developer fatigue.

So perhaps we can be better citizens by being more proactive, given that someone who's often paid a lot is taking time to help us with issues.

---

I agree with your point on RN and in-house development.

[0] https://play.google.com/store/apps/details?id=za.co.movingga... [1] https://github.com/flutter/flutter/issues/18524

I'm not referring to technical support questions, I'm referring to actual issues with verifiable repros which works everywhere else (inc. their debugger). They dismiss issues with core functionality like their W3C fetch API not being able to maintain long-running HTTP connections which breaks solutions relying on them like SSE [1]. They originally closed it making it known they have no intentions on ever fixing it and have since locked it preventing anyone else from being able to comment on it either.

RN enables a fast development model but you'll continually skate into an open mine field of issues where you'll end up wasting time on putting out fires and diagnosing issues only to discover they're known issues they have no intentions of fixing so you'll be spending time on implementing workarounds mitigating broken UX experiences in your App instead of focusing on delivering end-user value. Given the 1000's of issues that have received similar treatment I suspect React Native is just an architecturally flawed experiment and why we'll continue to see more users abandoning it. Hopefully they wont have wasted as much effort and resources as Airbnb's multi-year investment who despite having a large enough dev team to maintain their own fork was still unable to make RN work for them.

[1] https://github.com/facebook/react-native/issues/12912

This has been my experience exactly. Flutter devs quickly answering stack overflow or gitter questions.

With React Native I found the little touch 'click' sound wasn't working on Android. Someone had raised a bug and provided a patch years ago but Facebook still hadn't included it.

Similarly, I'm interested in what blockers exist for using Flutter for production/complicated apps

Reply on news.ycombinator.com