6 ms·

Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently: https:/

by onedev 8y ago

Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently: https://twitter.com/sandofsky/status/1002634185566236679 https://twitter.com/sandofsky/status/1002634185566236679 https://twitter.com/VivekxK/status/1002694526467653632 https://twitter.com/VivekxK/status/1002694526467653632

faitswulff 8y ago
Don't forget Udacity removing it from their codebase: https://twitter.com/n8ebel/status/1006244834351312897 https://twitter.com/n8ebel/status/1006244834351312897
- ex3ndr 8y ago
  Udacity is a bit strange example. This means that they have what? triple size of react native in their main app? That's weird because on android react native blows APK to much larger percentage.
nickspag 8y ago
Coursera also removed it completely.
- rimliu 8y ago
  Source?
  - faitswulff 8y ago
    https://twitter.com/mustafasf/status/1002787351188332544?s=09 https://twitter.com/mustafasf/status/1002787351188332544?s=0...
eysquared 8y ago
The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can. For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript. I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.
- danabramov 8y ago
  >The common thread I see is that mixing native and react-native is hard. We've experienced some of the difficulties in this area at Facebook as well. If you're curious, making native <-> JS integration more seamless is a big motivation for the ongoing architectural revamp that we've recently posted about: http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state... It's a shame we weren't fast enough to help Airbnb in these areas, but the native interop will get better when the revamp is finished.
  - eysquared 8y ago
    I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target. You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.
    - philipwhiuk 8y ago
      Couldn't agree more - AirBnB were already saying upgrading is a pain and this sounds like it'll be substantial. I hope RN is going to stop relying on beta code for releases too.
    - danabramov 8y ago
      To provide some extra context on this: at FB, we can't ship any RN update (or really, any RN commit) without updating our own apps for it. No product teams at FB are going to agree to rewrite their code just because an infrastructure team came up with a new way to do something. The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code lives in the same monorepo), codemods can be applied to products together with the corresponding infrastructure changes. Since the upgrades have a commit granularity instead of the monthly stable releases we cut in open source, there are no big delays between a regression being introduced and fixed for FB products. This discrepancy is unfortunate, but I don’t really see a way around it for an actively developed library--which might be your point. Undoubtedly RN is in active development, and being a moving target, it's easier for FB teams to “follow” it. Still, large backwards-incompatible changes are just as infeasible for us as for everybody else without either an automated codemod or an opt-in strategy.
woolvalley 8y ago
Yup it's the classic double layer issue. I think the only way to do it right is to go full 'game engine' style, like flutter or unity. With these you have a very small GL library surface area and one platform stack to actually understand for most of your engineers. Maybe something like WebAssembly will be similar. You often don't hear about these kinds of issues out of game engine makers. I could be totally wrong although since I haven't worked on games.

by onedev 8y ago

faitswulff 8y ago

Don't forget Udacity removing it from their codebase: https://twitter.com/n8ebel/status/1006244834351312897 https://twitter.com/n8ebel/status/1006244834351312897

ex3ndr 8y ago
Udacity is a bit strange example. This means that they have what? triple size of react native in their main app? That's weird because on android react native blows APK to much larger percentage.

nickspag 8y ago

Coursera also removed it completely.

rimliu 8y ago
Source?
- faitswulff 8y ago
  https://twitter.com/mustafasf/status/1002787351188332544?s=09 https://twitter.com/mustafasf/status/1002787351188332544?s=0...

eysquared 8y ago

The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can. For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript. I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.

danabramov 8y ago
>The common thread I see is that mixing native and react-native is hard. We've experienced some of the difficulties in this area at Facebook as well. If you're curious, making native <-> JS integration more seamless is a big motivation for the ongoing architectural revamp that we've recently posted about: http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state... It's a shame we weren't fast enough to help Airbnb in these areas, but the native interop will get better when the revamp is finished.
- eysquared 8y ago
  I'm excited about the proposed changes and think they are a step in the right direction, but I also worry that they will add more fuel to the fire that react-native as a platform is a constant moving target. You obviously have much more insight into what the re-architecture will entail than I do but I've heard a lot of worry around that post with regards to backwards compatibility of third party libraries and in-house native components.
  - philipwhiuk 8y ago
    Couldn't agree more - AirBnB were already saying upgrading is a pain and this sounds like it'll be substantial. I hope RN is going to stop relying on beta code for releases too.
  - danabramov 8y ago
    To provide some extra context on this: at FB, we can't ship any RN update (or really, any RN commit) without updating our own apps for it. No product teams at FB are going to agree to rewrite their code just because an infrastructure team came up with a new way to do something. The reason updates are easier at FB mostly has to do with atomicity of commits. Because FB uses RN from master (and in practice all code lives in the same monorepo), codemods can be applied to products together with the corresponding infrastructure changes. Since the upgrades have a commit granularity instead of the monthly stable releases we cut in open source, there are no big delays between a regression being introduced and fixed for FB products. This discrepancy is unfortunate, but I don’t really see a way around it for an actively developed library--which might be your point. Undoubtedly RN is in active development, and being a moving target, it's easier for FB teams to “follow” it. Still, large backwards-incompatible changes are just as infeasible for us as for everybody else without either an automated codemod or an opt-in strategy.

woolvalley 8y ago

Yup it's the classic double layer issue. I think the only way to do it right is to go full 'game engine' style, like flutter or unity. With these you have a very small GL library surface area and one platform stack to actually understand for most of your engineers. Maybe something like WebAssembly will be similar. You often don't hear about these kinds of issues out of game engine makers. I could be totally wrong although since I haven't worked on games.