Hacker News Reader

Comment by billllll | Hacker News Reader

I don't have personal experience with this, but React Native Web claims to solve this issue: 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).

View on HN

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.

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.

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.

I think where Flutter can be of interest is in truly innovative user interfaces, rather than a screen of imitated native components.

> Google has an attention span comparable to a puppy.

Google what? Chrome org? Flutter org? Android org? Myriad of other orgs?

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

>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.

The "Expo compatible ecosystem" has been all is the react native ecosystem for quite some time now, from what I can tell

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.

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.

It isn't even necessary anymore I believe, as Expo has a way to do so.

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).

ok thanks!

whats the type of functionality not available?

Anything not in the expo sdk ;) https://docs.expo.dev/versions/v47.0.0

You then use 3rd party modules (or build your own) to add/extend native functionality that is exposed to react native. For example, webtrc: https://github.com/react-native-webrtc/react-native-webrtc

This is (effectively) false. You don't need to eject to use third party modules (including, but not limited to, react-native-webrtc). You can use expo-dev-client to build your own "Expo Go"-esque development app, and EAS Build provides a fully transparent build environment.

To be precise, EAS Build does actually eject IIRC, but you never notice this during development. I haven't ejected or seen an android/ or ios/ directory in the past year of developing an Expo app, using many third party libs.

I agree with Expo being pretty painless. Anytime people are really set on using RN I tell them, just use Expo. Now a day, you can integrate external libs and such quite easy.

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.

How are you liking it so far? Perf issues or no?

Any concise/clear resource or guide you used?

>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.

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.

Reply on news.ycombinator.com