I have been working for the past four years exclusively on react-native apps and their backend API, from bootstrap to publishing, adding new features every few months and maintaining the apps.
It was a mixed experience. When I migrated to expo two years ago, many problems were solved but not all.
But I still encounters bugs and problems with many common dependencies. It is not uncommon to have bugs on certain Android brands, with the community on github reporting the bug but waiting months for it to be fixed.
iOS is by far better and more stable than Android.
Performance is great on iOS, but less great on Android.
Our apps are animation heavy using react-native-reanimated and react-native-skia. Everything went perfect on iOS but we had to remove some animations or simplify them on Android.
Upgrading your dependencies every four months will probably break something somewhere : deep links stop working, some animations stop working, or maybe it's another dependency from the JS world.
Sometime the fix is easy, other time an issue with the regression can be found on Github, other time we have no data.
Overall I'd say react-native is perfectly servicable and is easy to learn for anyone, which is a big plus.
I'd recommend react-native because it is easy, have a big JS ecosystem, but I am now on the Flutter side.
Congratulations! You've described the universal experience of using cross-platform frameworks.
They can be great as long as you and your customers stay on their most well-trodden path. But as these frameworks grow and become more byzantine, and as your project requirements start reaching for more rarified features and your customers start using new and differing runtime platforms, maintenance overhead starts to dominate and you find yourself running into invisible walls that make it hard for you to deliver on your project roadmap or satisfy the support standards you want for your customers.
This has always been the case for these frameworks, going back many decades, but especially since the explosion of efforts to build them around web stacks, which are easier for developers to use but harder for framework designers to keep sufficiently robust and capable as they age.
There's no free lunch when it comes to targeting multiple platforms. It sucks to have to maintain separate iOS, android, and web apps, and it also sucks to use a cross platform framework.
But I still feel in the end that for many CRUD style apps it's worth it to deal with react native's problems, especially if you can also have significant code sharing with your web app.
If you're trying to build the next snapchat or tiktok you'd better go full native though.
Flutter on the web is an absolute JOKE though. React native web & react-strict-dom seem far superior. The moment you want to support web as well, react-native blows flutter away.
Also how's the accessibility on Flutter? I'm pretty skeptical that it's going to have decent accessibility given the game-engine style rendering.
Such comments should really be directed at dang who keeps maintaining that there’s no data point to think that the state of discussions are declining.
One way to address this might be to compute some relevance metrics using embeddings (they’re the new hotness after all) and downrank low relevance discussions. I assume it’d be especially effective for the “ads and JavaScript” discussions.
>> keeps maintaining that there’s no data point to think that the state of discussions are declining.
I would simply say a lot of contrarian viewpoints, regardless of merit, are downvoted into oblivion. Once you get hammered on something you simply had a different viewpoint on? Users tend to stop commenting for fear of reprisals. Your "karma" on here is not easy to obtain so when people downvote you simply for a differing opinion, it makes it less likely they will wade into a discussion again and find themselves on the wrong side of some Hacker News diva having a bad day.
This means you have a lot of people (like myself) simply opting out of a lot of discussions because if you're not on the right side, your comment will get downvoted immediately. There is no data point on people like myself, so there's no way to tell people that the quality on HN is declining, everything is just fine and normal when in reality, you have a lot of users who aren't engaging for fear of getting downvoted into oblivion.
>but the discussions are becoming increasingly pointless
And hostile.
Point out that someone is wrong (even with hard evidence at hand) and people will still try to push their deluded conclusions nonetheless.
Same thing for expressing an opinion outside what the hivemind deems acceptable.
Btw, I think this phenomenon is a widespread cultural thing, not HN specific. Happens irl so much that it is now almost impossible to have an actual conversation with anybody.
Meanwhile, solitude and suicides are skyrocketing and people do not see the correlation ...
It's funny too, because what New Architecture allows (direct access to native interfaces) could solve a lot of the problems with having to fight external dependency hell - you can now write your own, so there's no excuses.
But, somehow devs _still_ expect a 100% perfect DX while maintaining the ability to publish to mind-boggling different targets such as iOS, Android, and Web
It really depends. I guess on more specific subs, sure. Like if this was posted on the react or react native sub.
If this was on programming or even web dev you'd just see "react bad" or "embedding a browser for an app is blablabla" (when react native doesn't even do that)
Reddit has a lower barrier to entry, which will invite lower quality comments. Sadly product officers are starting to flow into HN and other people with no programming experience, so the quality of comments are as such. If there was a fizzbuzz challenge to sign up, i'd bet the comments would not consist of such nonsense.
I'm a Flutter dev since 2018 and I am honestly not sure if Flutter or React Native still make sense in 2024 and onwards.
When they emerged, the mobile development scene was completely different than today.
Today, we have Swift UI and Compose, both are pretty solid. I'm not sure if it's the consensus amongst mobile developers, but I believe that on the mid/long run you will be better off - even if you write things twice. In terms of end user experience, developer experience, and in the business sense, everywhere.
Sure if you have an Flutter / RN app that has years of engineering efforts invested into it, go ahead and continue (duh), but I wouldn't start new apps with them.
Swift and Kotlin are now the de-facto languages for these two platforms for new development, and Swift UI and Compose got released and gained traction since 2018.
I got my Flutter app running on iOS, Windows, Linux, and Android. The web version is quite serviceable a well. Totally responsive and with good desktop integration on Windows & Linux. For me, talking about the "mobile development scene" is outdated. I want my app to run on every screen. That's either web or Flutter, Swift UI and Compose just don't fit the bill for me. I like both Web & Flutter, depending on the use-case. I tried React Native for Linux and Windows, but found it too complicated to set up, Flutter just worked. Curious if that has gotten better.
Native dev here throughout my career, I always start projects in both native. Now, it’s SwiftUI and Jetpack Compose. I don’t do cross platforms ever, it doesn’t appeal to me. I don’t know why though.
I don't want to say you should never, under any circumstances, use cross platform tools. Sure, if you have Android, iOS, web, macOS, Linux and Windows apps that are all roughly the same, go ahead and use cross platform technologies.
I don't think most apps are like that, though. If it is worth having a desktop app (instead of just, you know, having a web app), than that app is probably relying heavily on native integration. Also, mobile apps and desktop apps are usually quite different (as they should), those are two completely different interfaces.
About web, I'm not sure about RN, but Flutter IMO is so terrible on web, that it's so rare that it would make sense to use it, that my default advice would be that write the web in something different, even if you use Flutter already on mobile and desktop.
I've used React Native quite a bit in the past and I gotta say I wish it didn't have to exist at all.
It's often times fine on iOS and then incredibly slow on Android. Hermes is very exciting but still requires many polyfills to make simple NPM packages work. I hope one day, the web (and embedding web apps on mobile) makes React Native fully obsolete.
I've had the complete opposite experience. React Native has been amazing for the team I work on. It's fast, quick to develop in, and I've never felt blocked. Camera, TCP sockets, custom Bluetooth protocols, Protobuf, etc. React Native + libraries do it all.
That doesn't make sense to me at all. When you delegate heavy workloads to native view engines, both rendering and interfacing with native media/sdp will undoubtly be faster. The only issue i can see is if you install a lot of web only npm packages which has to go through the translation layer.
That's not what react native is for. Its for building native applications with a react-like syntax for the views. To me it seems like you used hammer to put in screws, no?
We use Expo/RN for Bluesky. The way I see it, if it's a separate codebase then it's a separate product. I honestly don't think we could've survived trying to build 3 different apps at once, so when I get hit with one of the warts (and believe me we hit them) it's not hard to shrug it off.
The team has been able to progressively target the different platforms where needed with native modules and TS files targeting the arch. Expo's build plugins have also saved our bacon.
We've been pretty excited for the new architecture. Our early tests show a lot of performance benefits on android, and so far the conversion process has been pretty good.
First off, thanks for all the work! I have a few questions if thats ok:
1. What is the next thing that the team wants to focus on improving?
2. What are the performance differences between the old architecture & new one?
3. What are your thoughts on the fragmented state of rn wrt react-native-web/react-native-windows/react-native-macos?
4. It is quite difficult to know what supports RN vs what relies on react-dom. Is there any thought to create some ecosystem focused around RN? Or if something like that is too cumbersone, perhaps even just adding some badge to github pages for "Supports RN"?
5. I forget what it was called, but the creator of react-native-web stated that they wanted to start winding down support in favor of an alternate approach which attempts to bring web apis to native instead of trying to make the native api work on web. I.e. instantiate div elements in native instead of view. What are your thoughts on this?
6. React (and IMO Meta as a whole) seems to generally have had the tech philosophy of take what you want, leave what you dont. With the dropping of create-react-app and endorsement of frameworks like Expo, it seems like its getting harder to just take the pieces we want. Is there any thought about this trend?
7. Related: as for the upgrade process: it would be cool if there were a way to "opt-in" to auto upgrades. E.g. what if there were a package which contained a base class controlled by the RN team so that a client side upgrade could be as simple as updating the version of the library the base class is in? (customization would be simple extending the class and doing w/e else needed there)
That's a lot of questions, thanks for asking! I'll stick to answering the ones related to the new arch.
The next thing is to continue building on this foundation and fix some long standing issues things like scroll perf and text input. A lot of our focus has been on the gradual migration strategy for the new arch, so now we'll have more capacity to work on other things.
But perf alone doesn't really tell the whole story. In raw perf terms, flashing empty content for just one frame is only a few milliseconds, but user is disproportionally impacted by that flicker. The new arch allows us to fix those types of issue in addition to the raw perf wins.
Thank you! Slightly off topic but every time new Xcode versions happen or as a result of time passing I always seem to get a messed up/corrupted Xcode project and so I end up copying the src folder and create a new project usually with an updated React Native version. This can be a real pain to be honest, taking sometimes a day or two of messing around with package version compatibility hell.
Is there a plan to fix this flakiness that I experience every 3 months or so?
Yeah this is a tricky problem, and it's one of the reasons we updated our recommendation to use a framework like Expo that can make upgrades be smoother by being more opinionated about the setup.
As the core library, we need to support all the different ways React Native can be added to an app (from fully react native to adding react native to an existing app) and all the different build tools an existing app may use. So it's hard for us to be opinionated about the setup in a way that would make upgrades seamless, but a framework can solve this for you.
I did a performance test last year, rendering thousands of views, and Flutter's rendering speed was 5 times faster than React Native. I wonder if this version will be improved after the update.
Interestingly, I used React on the web to render the same number of views, and its speed was much faster than React Native.
OK,just now I tested the new version and it is still slow.
Use "npx create-expo-app@latest --template default@beta" to install new version. Start with production mode, using android device, it takes about 300ms to render 2000 Views. The same test on React web is still much faster.
I'm speaking out of turn here since I'm not a React Native developer but, it seems to me that it suffers from the penalty of having to use the JS bridge that neither Flutter nor web use.
Seems to be a lot of negativity around RN, and I can understand that if you haven't used it in a while. But these days I have nothing but great things to say about React Native when used with Expo. It's great to want custom bespoke individual native apps for each platform but as a solo dev that just isn't really practical and RN has enabled me to ship things I wouldn't have been able to otherwise. Also that hot reloading react DX is just great in general. And I really want the RN model of using the platforms native controls to win out vs rendering everything to a canvas like Flutter.
Can't wait to try out the new arch when 0.76 lands in expo.
Readit News
It was a mixed experience. When I migrated to expo two years ago, many problems were solved but not all.
But I still encounters bugs and problems with many common dependencies. It is not uncommon to have bugs on certain Android brands, with the community on github reporting the bug but waiting months for it to be fixed.
iOS is by far better and more stable than Android.
Performance is great on iOS, but less great on Android.
Our apps are animation heavy using react-native-reanimated and react-native-skia. Everything went perfect on iOS but we had to remove some animations or simplify them on Android.
Upgrading your dependencies every four months will probably break something somewhere : deep links stop working, some animations stop working, or maybe it's another dependency from the JS world. Sometime the fix is easy, other time an issue with the regression can be found on Github, other time we have no data.
Overall I'd say react-native is perfectly servicable and is easy to learn for anyone, which is a big plus. I'd recommend react-native because it is easy, have a big JS ecosystem, but I am now on the Flutter side.
They can be great as long as you and your customers stay on their most well-trodden path. But as these frameworks grow and become more byzantine, and as your project requirements start reaching for more rarified features and your customers start using new and differing runtime platforms, maintenance overhead starts to dominate and you find yourself running into invisible walls that make it hard for you to deliver on your project roadmap or satisfy the support standards you want for your customers.
This has always been the case for these frameworks, going back many decades, but especially since the explosion of efforts to build them around web stacks, which are easier for developers to use but harder for framework designers to keep sufficiently robust and capable as they age.
But I still feel in the end that for many CRUD style apps it's worth it to deal with react native's problems, especially if you can also have significant code sharing with your web app.
If you're trying to build the next snapchat or tiktok you'd better go full native though.
Flutter just feels like a much more polished and stable platform built explicitly for purpose and I've never had any performance issues.
Also how's the accessibility on Flutter? I'm pretty skeptical that it's going to have decent accessibility given the game-engine style rendering.
Which similar frameworks' developers have subscribed to the Android ecosystem and do much better work there?
Welcome to Android. That's not just a React Native issue
https://github.com/M66B/FairEmail/blob/master/app/src/main/j...
1 person talking about how they wish react native didn't exist
1 person asking about Capacitor
1 person complaining about Expo
1 person saying that they wouldn't use react native and recommending Kotlin Multiplatform instead
1 person complaining about the quality of the discussion (Me)
0 people talking about the new architecture
I still love Hacker News but the discussions are becoming increasingly pointless.
All that's missing is:
1 person complaining about the style in which the article was written
1 person complaining about the amount of JavaScript loaded just to display this one article
One way to address this might be to compute some relevance metrics using embeddings (they’re the new hotness after all) and downrank low relevance discussions. I assume it’d be especially effective for the “ads and JavaScript” discussions.
I would simply say a lot of contrarian viewpoints, regardless of merit, are downvoted into oblivion. Once you get hammered on something you simply had a different viewpoint on? Users tend to stop commenting for fear of reprisals. Your "karma" on here is not easy to obtain so when people downvote you simply for a differing opinion, it makes it less likely they will wade into a discussion again and find themselves on the wrong side of some Hacker News diva having a bad day.
This means you have a lot of people (like myself) simply opting out of a lot of discussions because if you're not on the right side, your comment will get downvoted immediately. There is no data point on people like myself, so there's no way to tell people that the quality on HN is declining, everything is just fine and normal when in reality, you have a lot of users who aren't engaging for fear of getting downvoted into oblivion.
And hostile.
Point out that someone is wrong (even with hard evidence at hand) and people will still try to push their deluded conclusions nonetheless.
Same thing for expressing an opinion outside what the hivemind deems acceptable.
Btw, I think this phenomenon is a widespread cultural thing, not HN specific. Happens irl so much that it is now almost impossible to have an actual conversation with anybody.
Meanwhile, solitude and suicides are skyrocketing and people do not see the correlation ...
I think it's a combination of:
1. Ragebait being so useful at generating engagement that it's become a standard form of human interaction
2. The Internet making people feel safe from physical repercussions which makes people feel comfortable with treating others badly
3. Internet communities quickly becoming echo chambers where you're forced to pick a side if you want a sense of belonging
So we've been programmed and manipulated to be angry, to be tribal, and to act without fear of retaliation, and all for what? For ads and followers.
But, somehow devs _still_ expect a 100% perfect DX while maintaining the ability to publish to mind-boggling different targets such as iOS, Android, and Web
¯\_(ツ)_/¯
Congrats on being the person comparing HN to Reddit.
If this was on programming or even web dev you'd just see "react bad" or "embedding a browser for an app is blablabla" (when react native doesn't even do that)
EDIT: I’ve added to the problem which is ironic and just missed the delete button.
When they emerged, the mobile development scene was completely different than today.
Today, we have Swift UI and Compose, both are pretty solid. I'm not sure if it's the consensus amongst mobile developers, but I believe that on the mid/long run you will be better off - even if you write things twice. In terms of end user experience, developer experience, and in the business sense, everywhere.
Sure if you have an Flutter / RN app that has years of engineering efforts invested into it, go ahead and continue (duh), but I wouldn't start new apps with them.
People have believed this the whole time and also a ton of people didn't then and don't now. What has actually changed?
That said, it is absolutely up there with the best choices for mobile app dev these days.
I don't see any reason not to use it there, and the industry seems to be thinking in the same direction atm
I don't think most apps are like that, though. If it is worth having a desktop app (instead of just, you know, having a web app), than that app is probably relying heavily on native integration. Also, mobile apps and desktop apps are usually quite different (as they should), those are two completely different interfaces.
About web, I'm not sure about RN, but Flutter IMO is so terrible on web, that it's so rare that it would make sense to use it, that my default advice would be that write the web in something different, even if you use Flutter already on mobile and desktop.
It's often times fine on iOS and then incredibly slow on Android. Hermes is very exciting but still requires many polyfills to make simple NPM packages work. I hope one day, the web (and embedding web apps on mobile) makes React Native fully obsolete.
We don't use Expo, either. It's very painless.
That's not what react native is for. Its for building native applications with a react-like syntax for the views. To me it seems like you used hammer to put in screws, no?
That's interesting though, I would've expected iOS to be slower with android largely leveraging chrome because Google.
The team has been able to progressively target the different platforms where needed with native modules and TS files targeting the arch. Expo's build plugins have also saved our bacon.
We've been pretty excited for the new architecture. Our early tests show a lot of performance benefits on android, and so far the conversion process has been pretty good.
1. What is the next thing that the team wants to focus on improving?
2. What are the performance differences between the old architecture & new one?
3. What are your thoughts on the fragmented state of rn wrt react-native-web/react-native-windows/react-native-macos?
4. It is quite difficult to know what supports RN vs what relies on react-dom. Is there any thought to create some ecosystem focused around RN? Or if something like that is too cumbersone, perhaps even just adding some badge to github pages for "Supports RN"?
5. I forget what it was called, but the creator of react-native-web stated that they wanted to start winding down support in favor of an alternate approach which attempts to bring web apis to native instead of trying to make the native api work on web. I.e. instantiate div elements in native instead of view. What are your thoughts on this?
6. React (and IMO Meta as a whole) seems to generally have had the tech philosophy of take what you want, leave what you dont. With the dropping of create-react-app and endorsement of frameworks like Expo, it seems like its getting harder to just take the pieces we want. Is there any thought about this trend?
7. Related: as for the upgrade process: it would be cool if there were a way to "opt-in" to auto upgrades. E.g. what if there were a package which contained a base class controlled by the RN team so that a client side upgrade could be as simple as updating the version of the library the base class is in? (customization would be simple extending the class and doing w/e else needed there)
Again, thanks for all the work!
The next thing is to continue building on this foundation and fix some long standing issues things like scroll perf and text input. A lot of our focus has been on the gradual migration strategy for the new arch, so now we'll have more capacity to work on other things.
For perf differences, we shared some benchmarks here: https://github.com/reactwg/react-native-new-architecture/dis...
But perf alone doesn't really tell the whole story. In raw perf terms, flashing empty content for just one frame is only a few milliseconds, but user is disproportionally impacted by that flicker. The new arch allows us to fix those types of issue in addition to the raw perf wins.
Is there a plan to fix this flakiness that I experience every 3 months or so?
As the core library, we need to support all the different ways React Native can be added to an app (from fully react native to adding react native to an existing app) and all the different build tools an existing app may use. So it's hard for us to be opinionated about the setup in a way that would make upgrades seamless, but a framework can solve this for you.
Use "npx create-expo-app@latest --template default@beta" to install new version. Start with production mode, using android device, it takes about 300ms to render 2000 Views. The same test on React web is still much faster.
Can't wait to try out the new arch when 0.76 lands in expo.