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.
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.
> 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.
Why do fake internet points matter so much? Yes, karma is difficult to attain, but it also does (almost) nothing other than indicate how active a person is here.
> 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.
In short, so what? Does it really matter if one thing you said one time gets downvoted? We're all (supposed to be) adults here. All that happens is fewer people read your comment. Big whoop.
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.
This is extremely elitist and reductionist. Plenty of the best comments/discussions on HN come from non-programmers. Personally, I like that people from various backgrounds come together like this as it tends to provoke more interesting discussion and makes HN less of an echo chamber than Reddit.
>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 ...
Indeed, it is definitely the case that this kind of behavior/content gets amplified. When you log in, in some sense, any reality could be crafted just for you, for good or for bad. The overwhelming majority of people are vulnerable to this. What they see == what they think it's real, me included, btw.
I once read an article about how the vast majority of dating now begins through an online interaction (say , Tinder), and how also the vast majority of these apps are controlled by 2-3 companies. Think about the massive power they have over everyone else's lives. You want to encourage interracial relationships? Suppress matches within the same race and encourage matches outside of it. (And the opposite could be done, I'm not making a political statement here). These people have the power to completely change the demographic landscape of a country in a couple decades(!). They should be heavily regulated, but far from it, no one is even aware of this.
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.
No? Most modern apps these days _are_ just web apps. Why does it need the overhead architecture of running full standalone applications when a web clip works just as well? Plus there's no need for updating.
If that's the case, then why does nearly every company have a native app in addition to their website? Surely, they could save a lot of time and money by just not building and maintaining the app.
Web apps will always on paper be slower (not including badly made applications on both) than native apps, and also bring in additional security issues (since code is loaded remotely) than native applications.
apps built using the webview don't necessarily have to be loaded remotely. If you're building with capacitor, then nothing happens remotely until you choose.
Native apps make more money, because of phone data. A lot of effort is now put into facilitating cross-platform builds, a wrapper/container around a glorified web app is among the easiest ways
Most modern apps are just services. If you don’t mind you computer being a thin client to someone’s computer on the internet, go ahead. But the rest of us do use native software because the web is just a pale imitation.
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?
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 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.
Well, I need to make a media-player type of app, that will run on Linux/Wayland devices, which are like small desktops. Mainstream mobile devices would be a nice-to-have too, but there are so many bureaucratic issues, like getting into stores I might just avoid them for now. Web stuff can stay web.
Was thinking of learning Flutter or even RN, but now not so sure. On the other hand, it could mean writing it three times.
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.
Maybe I can un-eject given the plugins system from Expo. I do not like the way they throw all your code around though and I think this ability to steal peoples work given the prevalence of LLMs to unobsfuscate code is problematic. You should consider providing a way to drop the bundle in in byte code or something too... while I'm writing out my laundry list of issues ;-)
Seriously, thanks for all your (and team's) hard work, I look forward to all my packages being on the new architecture and upgrading!
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)
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.
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.
It's a very basic, indie hacker, habit tracker app, if Capacitor wouldn't "just work" for that, that would be really bad.
Most mobile apps (at least the ones that get you paid), though, are different, usually need good quality integration with native APIs, keyboard, etc...
Capacitor is really cool because it allows you to build a web app in iOS and Android and access the platform APIs from JavaScript. The rendering layer is a bit different though, because in React Native you can use the platform APIs _and_ the platform components. In React Native, the views you render on iOS are the same UIKit UIViews that a native app would write. In Capacitor, these are DOM elements in a webview. There are different tradeoffs, but this difference is what makes React Native look and feel more native.
In my opinion no. Capacitor has the same pitfalls like NativeScript. They're both clunky and lacks proper integration between the native layer and the emulated javascript world.
No matter what framework you roll with, you're gonna hit the same ol' clunky mess—it's just how app development goes.
The trick is, some frameworks smooth over the rough spots and throw a few sweet perks your way, while others give you a taste of both the good and the gritty.
That is true and neither platform is free from their issues. But NativeScript, Capacitor, Ionic and at last... Cordova. Has each of ther own oddities. NativeScript has a really awesome typing translation of the native apis to typescript. That's honestly the most fantastic to work with of any of all of them. Great for prototyping.
But when it comes to performance. None of them beats RN. You can make some good looking continous animation of most of them (not cordova or ionic). But when it comes to lag when moving between screens, RN on mobile comes on top without doubt.
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.
This is pretty incredible, kudos to the team! I wonder if there's still an option to call native modules asynchronously (since I'd guess the synchronous native calls block JS execution?)
Also, I remember transferring lots of data through the bridge could be a bottleneck for some use cases. Is that effectively solved with this architecture?
I'm not familiar with UI development at all, but I'm kind of amazed that the old solution of a giant async bridge where the renderer enqueued native function calls worked at all. What was the initial reasoning behind this architecture? (that is to say, why did it seem like a good idea at the time?)
Can I comprehend this as a new Virtual Native UI immutable tree running in native space?
And react native mounts and updates basically synchronally updating this immutable tree and reconciliation being done in native space, dynamically updating the app layout?
Kind of. We already had a native UI tree running in native (the same way the browser has it's own internal representation of the DOM). The difference in this release is that we rewrote it in C++ and made it immutable. That means instead of having a different UI tree in each platform (one for iOS, one for Android, etc), we have one C++ tree that all platforms use. And since it's immutable, it's thread safe and we can read layout and commit it from different threads if needed.
Reconciliation is still done in React on the JS thread, similar to React DOM.
I have built a React Native app in the past. Nowadays I would go for Kotlin Multiplatform. It is already the primary language on Android and now it is possible to create native binaries on iOS. With Compose multiplatform it also has the ability to also share UI code with a declarative syntax on multiple platforms.
I think React Native was the go to place in the past but it has been surpassed now.
Love react native, I'll be updating to this version soon. Really hoping it makes suspense work correctly with libs like Relay. Well done and thank you RN team.
Is there any sane way of using RN without locking into the Expo ecosystem? Last I checked it was a nightmare dealing with native dependencies otherwise.
React Native added auto-linking years ago, which solved the native dependency problems. Just `yarn add` whatever you need, and if it has native code, the the Android side will incorporate it on the next build. On the iOS side, you do have to run `pod install` to lock in the changes, but everything after that is automatic.
Use Expo because you like the extra features it ships with, but not because you have problems with native dependencies. The React Native built-in experience is pretty much perfect to start with.
Config plugins have made this way easier - you’re now able to hook into the native code generation process to add native modules that aren’t already packaged for expo.
I love that you asked this question. As someone who has created a few react native applications in the past, non expo environments has felt as an afterthought. I hope the react native team will improve the documentation and encourage the native platform as well as the expo platform. Some of us don't want to be locked into yet another SaaS with questionable payment tiers - when building your own modules and publishing is:
- Easier in the long run
- You're able to ship a far more featureful application if you deal with media and/or VoIP
- Passing apples reviews seem to be faster if you ship the modules yourself in my experience
When you're using expo you cannot bundle your own native extensions. At my previous job we used pjsip. This extension uses JNI and native calls in iOS via objective-c. You can't bundle native extensions when using expo. You're locked to their prebuilt ones.
To use your own extensions you have to eject/or start a new application with their own native libraries. For most of what expo does you can use the unimodules libraries, they're quite good in my experience.
> When you're using expo you cannot bundle your own native extensions. [...] You're locked to their prebuilt ones.
Unless I'm misunderstanding what you're saying, this isn't true at all. At $day_job we have an Expo app with a custom native library and it works just fine; you just have to write an Expo-specific adapter for it and can't use Expo Go in that case.
Last time I played around with React Native was probably around when it first launched, there was no Expo then, and I haven't used React Native since so I don't even know what Expo is.
But another commentator wrote "yet another SaaS with questionable payment tiers" about Expo (https://news.ycombinator.com/item?id=41937886) which makes me already not want to use it if I ever touch React Native again. Not sure why a SaaS would be involved at all in this process.
You don't have to use Expo's SaaS to use Expo. Expo framework is 100% FOSS. However Expo Application Services is a really great SaaS product for doing things like cloud builds and Over-The-Air updates.
The anti expo sentiment is almost all based on the old days where you had to eject to use native dependencies. Expo is amazing now.
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.
Soooo.. more react-native contributors have bought in to the Apple ecosystem, so frameworks and components are better designed and tested there?
Which similar frameworks' developers have subscribed to the Android ecosystem and do much better work there?
> 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.
Welcome to Android. That's not just a React Native issue
https://github.com/M66B/FairEmail/blob/master/app/src/main/j...
At the time of writing this comment, we've got:
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
You forget:
1 person complaining about the amount of JavaScript loaded just to display this one article
Should we also complain at the amount of bootstrapping your OS had to do before your browser could show said site?
Yes, absolutely. Just because it's been hidden behind decades of advances in CPU and storage technology doesn't mean it's not incredibly wasteful.
Explain to me why rendering html in javascript in wasteful? GNOME and Edge does the exact same thing for ther shells.
The site doesn't even load at all now (lol)
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.
> 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.
Why do fake internet points matter so much? Yes, karma is difficult to attain, but it also does (almost) nothing other than indicate how active a person is here.
> 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.
In short, so what? Does it really matter if one thing you said one time gets downvoted? We're all (supposed to be) adults here. All that happens is fewer people read your comment. Big whoop.
You can say it shouldn't matter, but it looks like on every social media platform and for most people, they do care about these things.
Reddit does a lot better of job bringing good relevant comments to the top.
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)
I strongly disagree, Reddit brings the most engaging comment to the top, which is usually funny or ironic, but rarely informative.
Congrats on being the person comparing HN to Reddit.
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.
This is extremely elitist and reductionist. Plenty of the best comments/discussions on HN come from non-programmers. Personally, I like that people from various backgrounds come together like this as it tends to provoke more interesting discussion and makes HN less of an echo chamber than Reddit.
>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 ...
I've seen what you're describing and it worries me deeply.
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.
Oh man, this is a very interesting take.
Indeed, it is definitely the case that this kind of behavior/content gets amplified. When you log in, in some sense, any reality could be crafted just for you, for good or for bad. The overwhelming majority of people are vulnerable to this. What they see == what they think it's real, me included, btw.
I once read an article about how the vast majority of dating now begins through an online interaction (say , Tinder), and how also the vast majority of these apps are controlled by 2-3 companies. Think about the massive power they have over everyone else's lives. You want to encourage interracial relationships? Suppress matches within the same race and encourage matches outside of it. (And the opposite could be done, I'm not making a political statement here). These people have the power to completely change the demographic landscape of a country in a couple decades(!). They should be heavily regulated, but far from it, no one is even aware of this.
It will only get worse with "AI", unfortunately.
And you are complaining about the complaining. Great work.
EDIT: I’ve added to the problem which is ironic and just missed the delete button.
That's literally point #5 of my comment. Didn't you read it?
Congrats. You added nothing to the discussion.
You're not being clever. You're just being argumentative.
I was pointing out the needlessness of your original comment. Why post it in the first place....
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.
Who would've thought steve jobs was right (although premature) with the initial iPhones only having web apps.
That's interesting though, I would've expected iOS to be slower with android largely leveraging chrome because Google.
Premature by 17+ years? He was and remains completely wrong.
With all of the APIs _modern_ browsers are exposing these days, web apps are extremely capable and remain the best multi-platform solution.
No? Most modern apps these days _are_ just web apps. Why does it need the overhead architecture of running full standalone applications when a web clip works just as well? Plus there's no need for updating.
The problem at the time was multifaceted. The devices couldn't handle it, the network couldn't handle it, and webkit was still relatively limited. But it did work. https://9to5mac.com/2021/06/03/remembering-apples-sweet-solu...
I have never, ever used a web app that runs as well as the native app.
If that's the case, then why does nearly every company have a native app in addition to their website? Surely, they could save a lot of time and money by just not building and maintaining the app.
Because it's a pain in the ass to distribute. And there's not much for support integrated into mobile operating systems for seamless browser windows.
MacOS is getting there kind of lately with safari being able to turn web pages into apps. But there isn't really built in mechanisms for that: https://www.macrumors.com/2023/06/14/how-web-apps-work-macos...
Web apps will always on paper be slower (not including badly made applications on both) than native apps, and also bring in additional security issues (since code is loaded remotely) than native applications.
apps built using the webview don't necessarily have to be loaded remotely. If you're building with capacitor, then nothing happens remotely until you choose.
The part about being slower is still true though.
Native apps make more money, because of phone data. A lot of effort is now put into facilitating cross-platform builds, a wrapper/container around a glorified web app is among the easiest ways
Most modern apps are just services. If you don’t mind you computer being a thin client to someone’s computer on the internet, go ahead. But the rest of us do use native software because the web is just a pale imitation.
Reddit is a better place for non technical discussions.
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.
We don't use Expo, either. It's very painless.
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?
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.
> I believe that on the mid/long run you will be better off - even if you write things twice.
People have believed this the whole time and also a ton of people didn't then and don't now. What has actually changed?
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.
Hmm, what about desktop and/or web?
Compose UI has the potential answer there, as well: https://www.jetbrains.com/compose-multiplatform/
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.
Well, I need to make a media-player type of app, that will run on Linux/Wayland devices, which are like small desktops. Mainstream mobile devices would be a nice-to-have too, but there are so many bureaucratic issues, like getting into stores I might just avoid them for now. Web stuff can stay web.
Was thinking of learning Flutter or even RN, but now not so sure. On the other hand, it could mean writing it three times.
I helped write this post, so feel free to ask me anything about the New Architecture!
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.
Maybe I can un-eject given the plugins system from Expo. I do not like the way they throw all your code around though and I think this ability to steal peoples work given the prevalence of LLMs to unobsfuscate code is problematic. You should consider providing a way to drop the bundle in in byte code or something too... while I'm writing out my laundry list of issues ;-)
Seriously, thanks for all your (and team's) hard work, I look forward to all my packages being on the new architecture and upgrading!
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)
Again, thanks for all the work!
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.
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.
In the post we explain that this release removes the bridge, so the JS thread calls C++ directly without a queue, serialization, or bridge: https://reactnative.dev/blog/2024/10/23/the-new-architecture...
Thanks for the clarification.
Is Capacitor a viable solution yet? I saw this tweet saying "it just works" for porting a webapp on NextJS: https://x.com/marc_louvion/status/1836023560462360746
It's a very basic, indie hacker, habit tracker app, if Capacitor wouldn't "just work" for that, that would be really bad.
Most mobile apps (at least the ones that get you paid), though, are different, usually need good quality integration with native APIs, keyboard, etc...
Capacitor is really cool because it allows you to build a web app in iOS and Android and access the platform APIs from JavaScript. The rendering layer is a bit different though, because in React Native you can use the platform APIs _and_ the platform components. In React Native, the views you render on iOS are the same UIKit UIViews that a native app would write. In Capacitor, these are DOM elements in a webview. There are different tradeoffs, but this difference is what makes React Native look and feel more native.
In my opinion no. Capacitor has the same pitfalls like NativeScript. They're both clunky and lacks proper integration between the native layer and the emulated javascript world.
No matter what framework you roll with, you're gonna hit the same ol' clunky mess—it's just how app development goes.
The trick is, some frameworks smooth over the rough spots and throw a few sweet perks your way, while others give you a taste of both the good and the gritty.
That is true and neither platform is free from their issues. But NativeScript, Capacitor, Ionic and at last... Cordova. Has each of ther own oddities. NativeScript has a really awesome typing translation of the native apis to typescript. That's honestly the most fantastic to work with of any of all of them. Great for prototyping.
But when it comes to performance. None of them beats RN. You can make some good looking continous animation of most of them (not cordova or ionic). But when it comes to lag when moving between screens, RN on mobile comes on top without doubt.
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.
This is pretty incredible, kudos to the team! I wonder if there's still an option to call native modules asynchronously (since I'd guess the synchronous native calls block JS execution?)
Also, I remember transferring lots of data through the bridge could be a bottleneck for some use cases. Is that effectively solved with this architecture?
I'm not familiar with UI development at all, but I'm kind of amazed that the old solution of a giant async bridge where the renderer enqueued native function calls worked at all. What was the initial reasoning behind this architecture? (that is to say, why did it seem like a good idea at the time?)
React native is finally pretty good this year. It still has problems but I feel like it's really starting to pick up momentum.
When react-strict-dom is totally ready for prime time it's going to be a game changer and react native will become an absolute juggernaut.
How so? What makes this a game changer for the average dev?
It’s looking really good so far. Some known issues in the expo and RN ecosystem are called out under the troubleshooting section here:
https://docs.expo.dev/guides/new-architecture/
Guys, help me understand these changes:
Can I comprehend this as a new Virtual Native UI immutable tree running in native space?
And react native mounts and updates basically synchronally updating this immutable tree and reconciliation being done in native space, dynamically updating the app layout?
Kind of. We already had a native UI tree running in native (the same way the browser has it's own internal representation of the DOM). The difference in this release is that we rewrote it in C++ and made it immutable. That means instead of having a different UI tree in each platform (one for iOS, one for Android, etc), we have one C++ tree that all platforms use. And since it's immutable, it's thread safe and we can read layout and commit it from different threads if needed.
Reconciliation is still done in React on the JS thread, similar to React DOM.
Thanks for the clarification. Dumb question:
How does the renderer ensure consistency in case o multiple immutable tree references?
I have built a React Native app in the past. Nowadays I would go for Kotlin Multiplatform. It is already the primary language on Android and now it is possible to create native binaries on iOS. With Compose multiplatform it also has the ability to also share UI code with a declarative syntax on multiple platforms.
I think React Native was the go to place in the past but it has been surpassed now.
Love react native, I'll be updating to this version soon. Really hoping it makes suspense work correctly with libs like Relay. Well done and thank you RN team.
Is there any sane way of using RN without locking into the Expo ecosystem? Last I checked it was a nightmare dealing with native dependencies otherwise.
React Native added auto-linking years ago, which solved the native dependency problems. Just `yarn add` whatever you need, and if it has native code, the the Android side will incorporate it on the next build. On the iOS side, you do have to run `pod install` to lock in the changes, but everything after that is automatic.
Use Expo because you like the extra features it ships with, but not because you have problems with native dependencies. The React Native built-in experience is pretty much perfect to start with.
Config plugins have made this way easier - you’re now able to hook into the native code generation process to add native modules that aren’t already packaged for expo.
Having used bare RN for 5 years, and recently started using Expo, there really is no reason to not use Expo at this point.
The native dependencies are 100% solved by prebuilds, CNG, and config plugins.
I love that you asked this question. As someone who has created a few react native applications in the past, non expo environments has felt as an afterthought. I hope the react native team will improve the documentation and encourage the native platform as well as the expo platform. Some of us don't want to be locked into yet another SaaS with questionable payment tiers - when building your own modules and publishing is:
- Easier in the long run
- You're able to ship a far more featureful application if you deal with media and/or VoIP
- Passing apples reviews seem to be faster if you ship the modules yourself in my experience
> - You're able to ship a far more featureful application if you deal with media and/or VoIP
Can you expand on this? How does Expo prevent or make it harder for you to ship media- and VOIP-related features?
When you're using expo you cannot bundle your own native extensions. At my previous job we used pjsip. This extension uses JNI and native calls in iOS via objective-c. You can't bundle native extensions when using expo. You're locked to their prebuilt ones.
To use your own extensions you have to eject/or start a new application with their own native libraries. For most of what expo does you can use the unimodules libraries, they're quite good in my experience.
> When you're using expo you cannot bundle your own native extensions. [...] You're locked to their prebuilt ones.
Unless I'm misunderstanding what you're saying, this isn't true at all. At $day_job we have an Expo app with a custom native library and it works just fine; you just have to write an Expo-specific adapter for it and can't use Expo Go in that case.
Source: https://docs.expo.dev/workflow/customizing/
Been working on one RN project Expo-free since 0.6x. It's really not needed at all, neither is it complicated to set up without Expo.
I've only used Expo during hackathons and university to quickly get something running, but for actual production apps it's should be avoided imo.
that's an interesting perspective, curious to what your reasons are for avoiding expo in production?
Last time I played around with React Native was probably around when it first launched, there was no Expo then, and I haven't used React Native since so I don't even know what Expo is.
But another commentator wrote "yet another SaaS with questionable payment tiers" about Expo (https://news.ycombinator.com/item?id=41937886) which makes me already not want to use it if I ever touch React Native again. Not sure why a SaaS would be involved at all in this process.
You don't have to use Expo's SaaS to use Expo. Expo framework is 100% FOSS. However Expo Application Services is a really great SaaS product for doing things like cloud builds and Over-The-Air updates.
The anti expo sentiment is almost all based on the old days where you had to eject to use native dependencies. Expo is amazing now.
how long ago was the last time you checked?
expo has solved the native dependencies issue, and it's a fantastic way to build an app.
this is one of the few hills i'm willing to die on. expo is great for the RN community.
also you can download my RN expo app here: www.shopcats.app.
I will now inform everyone here that the Windows 11 Start Menu uses React Native. You're welcome :)
Only the "recommended" section.
Could someone suggest a good CRUD starter kit?