[HN Gopher] React Native is not the future
___________________________________________________________________
React Native is not the future
Author : samwillis
Score : 29 points
Date : 2022-12-31 16:02 UTC (6 hours ago)
(HTM) web link (blog.standardnotes.com)
(TXT) w3m dump (blog.standardnotes.com)
| gigel82 wrote:
| *for you
|
| It's all about trade-offs; you decided to trade better
| performance and native look&feel for faster/easier development.
| Perfectly reasonable, but for others that are making different
| trade-offs React Native totally is the future.
|
| I think RN is a great middle-ground where you get native
| looking&feeling UX, but still get to share 95%+ of the code
| across platforms.
| robertoandred wrote:
| Sounds like he's just inventing a slower, less native version of
| React Native.
| marstall wrote:
| this is a cool model and I do something similar (I use native
| code to render the webview).
|
| though I wouldn't describe it as abandoning RN, because I use
| react-native-web inside that webview.
|
| rn-web provides certain features that are crucial for a native
| feel on mobile, like better coordination of touches within
| scrollviews.
| sureglymop wrote:
| Do you have/know any example app to try out?
| mrbombastic wrote:
| One codebase sounds great but I always feel devs try to ignore
| that there just are significant differences between platforms
| that you must address if you want a well integrated app. Writing
| separate codebases in native iOS, Android, and web has a huge
| amount of waste but you can achieve higher quality and os
| integration, writing react native and react on web means you get
| just 2 codebases and higher dev productivity but at the cost of
| pain in libraries which typically also means less native
| integration, the solution proposed here means 1 codebase and even
| less native integration. If it is right for you great but like
| everything it is tradeoffs, pick your poison.
| danielvaughn wrote:
| Agreed. Although the economic reality is that it's borderline
| impossible for a company to develop a cross-platform native
| product unless they have significant amounts of money. Cross-
| platform is a terrible necessity to that end.
| ericlewis wrote:
| Eh. Not sure I agree, unless you mean taking a non-native
| already made react bit and try to turn it into RN.. that is
| far harder and does require lots of money.
|
| too many people don't realize just how non-portable react
| code can be.
| danielvaughn wrote:
| No I mean building a product that works on web, android,
| and iOS, and has a native experience on all platforms. It's
| hard enough to find a good web dev, but it's far harder to
| find good iOS and Android devs. It's a very large and
| expensive endeavor.
| CharlesW wrote:
| > _Our new mobile app still uses React Native..._
|
| The big reveal is that React Native is still their future.
|
| TLDR: Their app continues to use React Native, but they've given
| up on using it to provide a native user experience, and instead
| just use it to access OS APIs.
| ericlewis wrote:
| NativeScript would prob suit them better.
| teg4n_ wrote:
| What they decided to do is really quite strange. Something like
| Capacitor makes much more sense but they said they wanted
| access to React Native libraries... I hope
| https://github.com/OpenNative/open-native can address their
| requirements in the future. It's goal is to make things like
| React Native native modules work across frameworks (e.g., react
| native libraries working in capacitor and native script)
| billllll wrote:
| 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).
| ericlewis wrote:
| combining RN and RNW is a pain in practice. It can be done, but
| not easily.
| sureglymop wrote:
| Tried it out on Android and it feels janky. It just feels like a
| web app and it's not working well. To just give one example, if I
| click on the header of a note, a menu with "options" shows up.
| But Android also selects the text in the header and pops up a
| menu with "Cut, Copy, Paste, etc." which is exactly on top of
| that menu I was actually trying to get to...
| matchbok wrote:
| With the right libraries and clean code, going native for
| iOS/Android is usually the solution. Building UI/networking/etc
| quickly in Swift/Kotlin just isn't an issue anymore. RN/Flutter
| won't be used in 5 years.
| agsnu wrote:
| I'm just holding out for a Jetpack Compose for iOS :)
| Ian_Macharia wrote:
| Strongly disagree. Both frameworks save on dev time to a very
| significant degree. I actually foresee better cross platform
| solutions being introduced in 5 years
| ericlewis wrote:
| I don't agree, and I have worked with this significantly as a
| consultant and core contributor to react-native. What
| typically happens is people convince themselves what you are
| saying is true then there ends up being huge delays to spin
| up all the infra app side... THEN eventually, they kinda are
| okay. until the next react-native release.
|
| edit: would like to clarify that of course I would recommend
| better ways... but... clients do as clients do.
___________________________________________________________________
(page generated 2022-12-31 23:00 UTC)