4 ms·

I don't have personal experience with this, but React Native Web claims to solve this issue: https://necolas.github.io/react-native-web/ https://necolas.github.

I don't have personal experience with this, but React Native Web claims to solve this issue: https://necolas.github.io/react-native-web/ https://necolas.github.io/react-native-web/, not sure if anyone has had experience with this. Of course, you will have issues with dependency hell/package maintenance. Another great option seems to be Flutter web. I was really impressed by the "batteries included" approach to Flutter, and Dart has a pretty comprehensive standard library. This is in contrast to React's "just find a random package on npm and pray it doesn't bite you in the future." Obviously rewrites are expensive, but I personally think both approaches are worth considering versus abandoning native components completely. WebView isn't without problems (and also, you don't need React Native to use WebView).

ericlewis 4y ago
combining RN and RNW is a pain in practice. It can be done, but not easily.
- phist_mcgee 4y ago
  I've done it. Once you're setup, it really does work quite out of the box. What you do have to be mindful of is clear separation of concerns when designing platform specific components - you have to think in terms of Button.native.ts and Button.web.ts when you're doing things like haptic feedback or animations. The only thing that's really a pain is that react dev tools has a harder time dealing with RNW components, and debugging in general can be a bit of a pain.
  - no_butterscotch 4y ago
    How are you liking it so far? Perf issues or no? Any concise/clear resource or guide you used?
    - phist_mcgee 4y ago
      >How are you liking it so far? Perf issues or no? Perf seems totally within reasonable bounds for a react app, no issues so far. In terms of resources or guides, it's pretty spotty out there. The project has definitely slowed down in terms of dev and i'm not sure where things like react 18 fit into the picture across platform, but we've setup our own config that works just fine for now. We may need to reappraise in 2-3 years if react does change architecturally too much.
- ramesh31 4y ago
  >combining RN and RNW is a pain in practice. It can be done, but not easily. It's completely painless with Expo. With the tradeoff being you are locked into the Expo compatible ecosystem. Incredible devX if you go all in on it though.
  - no_butterscotch 4y ago
    What's great about it? I was considering using RN for a cross platform app and for some reason got the impression (earned or not) that Expo was for beginners, and people who have "non trivial" apps will have to "eject" (as it's called in Expo) sooner or later. So I was going to avoid it.
    - supermatt 4y ago
      not so. you can build complex apps with the expo libs. The reason people "eject" is primarily to add 3rd party native modules for functionality not available in expokit, or to optimize build size by removing unused expokit functionality. This isnt neccessary in the vast majority of cases as you can use Expo App Services to do this (locally, or remotely if you dont have mobile sdks installed) And you still get the other benefits of expo - e.g. "batteries included" api, OTA app updates, not having to install the mobile SDKs, etc.
      - ericlewis 4y ago
        It isn't even necessary anymore I believe, as Expo has a way to do so.
        supermatt 4y ago
        There are still some cases where you will need to eject (if you want to embed as a view in an unmanaged app for example).
      - no_butterscotch 4y ago
        ok thanks! whats the type of functionality not available?
- kbcool 4y ago
  It's easy for a new app, plug and play! It gets harder if you want to retrofit it to an older app using older third party libraries that have no or limited support. You have to pick through everything to work out what's playing up.
deergomoo 4y ago
While the engineering is impressive, I just can’t get on board with how Flutter works. Imitating native components seems both incredibly wasteful and also very fragile considering Google has an attention span comparable to a puppy.
- princevegeta89 4y ago
  I would prefer imitated components any day compared to dealing with the actual SDK native components. Especially when there is "one code" that compiles into corresponding these components on different platforms. These things always change with each SDK version on each platform, and there needs to be a lot of messy hand-stitching in the library (React Native) to keep things working as expected.
- aryehof 4y ago
  I think where Flutter can be of interest is in truly innovative user interfaces, rather than a screen of imitated native components.
- krzat 4y ago
  Imitating native components is actually the only realistic approach. Those components are guaranteed to work on newer OS versions, they work on any platform and they give you easy access to the low level guts.
- wiseowise 4y ago
  > Google has an attention span comparable to a puppy. Google what? Chrome org? Flutter org? Android org? Myriad of other orgs?

ericlewis 4y ago

combining RN and RNW is a pain in practice. It can be done, but not easily.

phist_mcgee 4y ago
I've done it. Once you're setup, it really does work quite out of the box. What you do have to be mindful of is clear separation of concerns when designing platform specific components - you have to think in terms of Button.native.ts and Button.web.ts when you're doing things like haptic feedback or animations. The only thing that's really a pain is that react dev tools has a harder time dealing with RNW components, and debugging in general can be a bit of a pain.
- no_butterscotch 4y ago
  How are you liking it so far? Perf issues or no? Any concise/clear resource or guide you used?
  - phist_mcgee 4y ago
    >How are you liking it so far? Perf issues or no? Perf seems totally within reasonable bounds for a react app, no issues so far. In terms of resources or guides, it's pretty spotty out there. The project has definitely slowed down in terms of dev and i'm not sure where things like react 18 fit into the picture across platform, but we've setup our own config that works just fine for now. We may need to reappraise in 2-3 years if react does change architecturally too much.
ramesh31 4y ago
>combining RN and RNW is a pain in practice. It can be done, but not easily. It's completely painless with Expo. With the tradeoff being you are locked into the Expo compatible ecosystem. Incredible devX if you go all in on it though.
- no_butterscotch 4y ago
  What's great about it? I was considering using RN for a cross platform app and for some reason got the impression (earned or not) that Expo was for beginners, and people who have "non trivial" apps will have to "eject" (as it's called in Expo) sooner or later. So I was going to avoid it.
  - supermatt 4y ago
    not so. you can build complex apps with the expo libs. The reason people "eject" is primarily to add 3rd party native modules for functionality not available in expokit, or to optimize build size by removing unused expokit functionality. This isnt neccessary in the vast majority of cases as you can use Expo App Services to do this (locally, or remotely if you dont have mobile sdks installed) And you still get the other benefits of expo - e.g. "batteries included" api, OTA app updates, not having to install the mobile SDKs, etc.
    - ericlewis 4y ago
      It isn't even necessary anymore I believe, as Expo has a way to do so.
      - supermatt 4y ago
        There are still some cases where you will need to eject (if you want to embed as a view in an unmanaged app for example).
    - no_butterscotch 4y ago
      ok thanks! whats the type of functionality not available?
kbcool 4y ago
It's easy for a new app, plug and play! It gets harder if you want to retrofit it to an older app using older third party libraries that have no or limited support. You have to pick through everything to work out what's playing up.

deergomoo 4y ago

While the engineering is impressive, I just can’t get on board with how Flutter works. Imitating native components seems both incredibly wasteful and also very fragile considering Google has an attention span comparable to a puppy.

princevegeta89 4y ago
I would prefer imitated components any day compared to dealing with the actual SDK native components. Especially when there is "one code" that compiles into corresponding these components on different platforms. These things always change with each SDK version on each platform, and there needs to be a lot of messy hand-stitching in the library (React Native) to keep things working as expected.
aryehof 4y ago
I think where Flutter can be of interest is in truly innovative user interfaces, rather than a screen of imitated native components.
krzat 4y ago
Imitating native components is actually the only realistic approach. Those components are guaranteed to work on newer OS versions, they work on any platform and they give you easy access to the low level guts.
wiseowise 4y ago
> Google has an attention span comparable to a puppy. Google what? Chrome org? Flutter org? Android org? Myriad of other orgs?