Ask HN: React Native or Flutter when the back end is Node?

Really confused between React Native and Flutter. I’ve mostly worked with Flutter and a little bit with React Native, but that was quite a while back, so I’m not sure how things stand today.

I’m building a project with a Node.js + tRPC backend, so React Native is looking really tempting cause of that Typescript.

While researching I've seen mixed reviews about performance in React Native like people saying they've spend weeks finding and managing performance issue which does makes me worry.

The app I wanna build doesn't have complex canvas work or crazy animations. For a typical production app, what’s the performance situation with React Native vs Flutter now? Are there any major concerns which I should know before looking in React Native?

5 points | by rearview 4 hours ago

4 comments

gitgud 21 minutes ago
Well since nobody is suggesting it, then I will.
Go full native for each platform. React Native and Flutter are great (I’ve used them both), but there’s several reasons not to choose them anymore
1. Complexity - you’re adding another layer between your app and the device, debugging, compilation, device quirks all become much more annoying
2. AI coding makes it easier - This works both ways, flutter and react native become easier to develop, but so does native development
3. Support is always better on native - consider any issue you have building an iOS app, now add in React issues and then React native issues and then a bunch of other framework version issues… it’s generally better support if you use the tools the platform expect you to use
4. Code reuse is not as big of a deal as you think - trying to share UI code across android, iOS, web ends up making all platforms you build for worse, as bugs and performance issues go to all platforms… if you have a simply designed app, then a native experience is always preferable by users
sync 4 hours ago
I have a similar stack (using oRPC instead of tRPC, recommended!) and I'd say React Native, specifically Expo UI: https://docs.expo.dev/versions/latest/sdk/ui/
This will get you the most native feel across all platforms (e.g. Liquid Glass) and keeps you in one language (TypeScript).
No performance issues to note in particular because Expo UI is (basically) native - it just uses SwiftUI and Jetpack Compose under the hood.
[-]
- rearview 3 hours ago
  what about app size and ram usage like heard bad review about that. I just wanna be sure before I start like real sure :)
runningmike 3 hours ago
It depends do you want to maintain ii? Do you use AI? Performance issues can always be solved. Do you want to use browser’s capabilities or keep control in your own backend ? Less frameworks is better, use e.g the same for everything.
verdverm 4 hours ago
If you aren't doing native apps, my recommendation is to use the same language across full-stack apps. You can share things like zod types and validation logic (in the frontend for quicker user feedback, on the backend because you never trust user provided values)
[-]
- rearview 4 hours ago
  That's why it looks so tempting but the main reason having mixed feelings because of reviews everywhere about React Native that it's doesn't have that kind of performance! And yeah zod and tRPC is a lovely combo for building app loving it with Next.JS
  [-]
  - verdverm 3 hours ago
    There are a lot of React Native apps out there, the issues I see are more around platform glitchiness or workarounds than performance.
    The main thing to watch out for is blocking the rendering or event loop. I've definitely seen apps where a slow API call blocks everything else. So less about performance and more about knowing how to do concurrency well.
    [-]
    - rearview 3 hours ago
      absolutely! got any tips that I should be using while working on it :)
      [-]
      - verdverm 3 hours ago
        let the agents debug these things, without needing images, the feedback loop is key
        I haven't done any mobile stuff in a while, but there should be enough around to wire the agents up into a good environment, like remote chrome-devtools (with or without the MCP).
        pnpm workspaces, makes having multiple packages with internal dependencies (like core and components) easy to manage in the dev workspace