React Native 0.69(reactnative.dev)
reactnative.dev
React Native 0.69
https://reactnative.dev/blog/2022/06/21/version-069
73 comments
You can do both: two years ago I was looking for the best solution to ship a cross platform app (Android + Windows) and I just couldn’t decide whether to go platform-based UI + a shared C++ core or React Native. I ended up using React Native + a shared C++ core exposed as a RN module. As long as the API surface is narrow (and it is for my use case) this turned out well and it still gives me the possibility to scrap RN at any given time for platform based UIs.
Bonus: since most of my logic is C++, I am still able to ship the app using two RN versions: 0.59 for Windows 7 and 0.67 for Android
Bonus: since most of my logic is C++, I am still able to ship the app using two RN versions: 0.59 for Windows 7 and 0.67 for Android
Xamarin is a good alternative if you don't want the overhead of JS runtime, without going all the way down to the metal as you mentioned. Shared code base. But you sacrifice a bit of productivity for performance and maintainability.
In React Native they now use the Hermes engine which can have the JS code precompiled into byte code.
https://reactnative.dev/docs/hermes#confirming-hermes-is-in-...
https://reactnative.dev/docs/hermes#confirming-hermes-is-in-...
I'm currently looking at a cross platform development technology to learn. I've limited experience all of it with Cordova. I was looking at Dart/Flutter. Is react native much better?
Along what metrics is the question.
As far as I know it’s:
- less popular (https://gist.github.com/tkrotoff/93f5278a4e8df7e5f6928eff986...)
- worse performance
- much more frustrating developer experience (inherently subjective but not a particularly controversial opinion)
- less supported / actively developed (some very core parts of the RN ecosystem got punted to “community supported” where they basically died in place) but also worth comparing GitHub activity for Flutter https://github.com/flutter/flutter/pulse/monthly and RN https://github.com/facebook/react-native/pulse/monthly
I think Flutter is a much better long term bet despite the fact that it’s a much newer project.
As far as I know it’s:
- less popular (https://gist.github.com/tkrotoff/93f5278a4e8df7e5f6928eff986...)
- worse performance
- much more frustrating developer experience (inherently subjective but not a particularly controversial opinion)
- less supported / actively developed (some very core parts of the RN ecosystem got punted to “community supported” where they basically died in place) but also worth comparing GitHub activity for Flutter https://github.com/flutter/flutter/pulse/monthly and RN https://github.com/facebook/react-native/pulse/monthly
I think Flutter is a much better long term bet despite the fact that it’s a much newer project.
React Native did a lot of work with the performance issues. They have now their own JS interpreter called Hermes. It also allows your javascript code to be compiled to byte code for better performance. Furthermore their new architecture allows for better integration with native and faster performance.
https://reactnative.dev/docs/new-architecture-intro
I think a lot of people have their opinions based on an image of React Native in the past. It evolved a lot to be better performant and easier to work with. And for many people the React ecosystem is way more familiar than Dart.
I think a lot of people have their opinions based on an image of React Native in the past. It evolved a lot to be better performant and easier to work with. And for many people the React ecosystem is way more familiar than Dart.
Dart is compiled to machine code, not just byte code.
There's also new rendering engine being worked on for Flutter called Impeller. It's not just React Native that's improving.
There's also new rendering engine being worked on for Flutter called Impeller. It's not just React Native that's improving.
I think the core problem any cross platform solution is going to face is that maintaining a compatibility layer between 2+ proprietary OS’s* is a recipe for a bad time. It is why these projects need to be supported by a massive tech company. My only point being even if Flutter is at an advantage today over react native on this point, long term they will face the same problems as react native with stagnating cross platform support.
edit: silly mistake Android is open source, not sure how much it helps when compatibility layer is not a priority for the OS developers
edit: silly mistake Android is open source, not sure how much it helps when compatibility layer is not a priority for the OS developers
> I think the core problem any cross platform solution is going to face is that maintaining a compatibility layer between 2+ proprietary OS’s* is a recipe for a bad time.
Flutter has big advantage in this area as it doesn't wrap OS's controls, but has build it's own controls on top of lower level OS's APIs.
Avalonia (which also renders it's own controls) has posted an article, describing how it's easier supporting new platforms this way: https://dev.to/avalonia/avalonia-platform-support-why-its-si...
Avalonia GUI apps can run on Linux without a desktop environment installed because of this.
Flutter has big advantage in this area as it doesn't wrap OS's controls, but has build it's own controls on top of lower level OS's APIs.
Avalonia (which also renders it's own controls) has posted an article, describing how it's easier supporting new platforms this way: https://dev.to/avalonia/avalonia-platform-support-why-its-si...
Avalonia GUI apps can run on Linux without a desktop environment installed because of this.
Aha that is interesting I wasn’t aware of this difference. Pushing the layer down to lower level controls does seem like it would help with this but perhaps at the cost of ui consistency on the platforms?
Either way thanks for the link, I’ll check it out.
Either way thanks for the link, I’ll check it out.
Yeah, since all controls are created from scratch there is no inherited consistency with the controls of the underlying platform.
However, framework developers often develop controls that emulate platform controls. Not all are 100% match. Depends on the quality of the implementation.
The quality of Flutter controls is not yet on par with iOS's controls, but if they continue to improve at the same rate as they currently do, in 1-3 years they could match or even surpass them.
However, framework developers often develop controls that emulate platform controls. Not all are 100% match. Depends on the quality of the implementation.
The quality of Flutter controls is not yet on par with iOS's controls, but if they continue to improve at the same rate as they currently do, in 1-3 years they could match or even surpass them.
There are way more people knowing React and JS than dart. So it is easier to find engineers and thus help if you are stuck with basic React or JS concepts.
On this thread, there are bunch of comments which are just "Nice".
I clicked on a few of the usernames, and while a couple are new, many have decent Karma accrued.
I also tried to search for "React Native 'nice'" to see if anything came up on google. No luck.
So is that a meme that i'm not aware of or something?
I clicked on a few of the usernames, and while a couple are new, many have decent Karma accrued.
I also tried to search for "React Native 'nice'" to see if anything came up on google. No luck.
So is that a meme that i'm not aware of or something?
It is yes.
https://knowyourmeme.com/memes/69
https://knowyourmeme.com/memes/69
> Online, it (the number 69) has a reputation as "the sex number." People often joke about it by replying "nice" to posts that use the number 69 regardless of the context in which the number is used.
Why would people keep doing it in HN, and some of those accounts aren't event that new...
Why would people keep doing it in HN, and some of those accounts aren't event that new...
Because it’s funny.
No fun allowed on HN
Fun is definitely not disallowed, you can read the guidelines here: https://news.ycombinator.com/newsguidelines.html
But it also says:
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
Which puts your comment in a grey area :) That said, nobody follows rules to the letter, and you can definitely find a lot of comments from me as well that don't follow them strictly, but here is a community and by spending time here, you can surely get a good gut feeling of what's allowed really and what not. Remember: Nobody is here to teach a lesson to anyone, and it can be said that most basically just want some thought put into the comments. Having a hundred replies that says "nice" therefore won't do great.
But it also says:
> Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
Which puts your comment in a grey area :) That said, nobody follows rules to the letter, and you can definitely find a lot of comments from me as well that don't follow them strictly, but here is a community and by spending time here, you can surely get a good gut feeling of what's allowed really and what not. Remember: Nobody is here to teach a lesson to anyone, and it can be said that most basically just want some thought put into the comments. Having a hundred replies that says "nice" therefore won't do great.
"69 Dude!" - Bill and Ted
Coming from web I gave serious shot to React Native for quite sometime but I learned the hard way that it can go only so far in mobile app development. There will come a point in React Native development where you have to go under the hood to the native side of the operating system to deliver that last mile experience to your users.
That’s kind of the point though? It means most of your time is spent rapidly developing in cross platform React, and only some of it doing platform specific stuff, as opposed to 100% off the time. This is a feature.
Care to give some specific examples?
Navigation for example. If you use react-navigation stack and native-stack may look very similar but have tons of hidden implications.
If you are presenting a screen modally on iOS you cannot present a Modal component over it for example. This requires that you understand (or at least research) platform specific behavior.
Even so, I’d take RN any day of the week.
If you are presenting a screen modally on iOS you cannot present a Modal component over it for example. This requires that you understand (or at least research) platform specific behavior.
Even so, I’d take RN any day of the week.
[deleted]
How does react native compare to flutter nowadays? Is this still the framework for simple apps that need to be cross platform?
I switched to flutter a couple years ago after a RN upgrade caused me days of pain. Took a couple weeks to port the app over to flutter, and I've never looked back. I only use flutter for mobile apps, and I have no experience using flutter web because I have never had the use case IRL where the web apps map 1:1 with the mobile app. They almost always have different implementations and functionalities, and its better to just use react or svelte.
Seriously having a hard time coming up with cons, so here are my reasons why I like it:
- dart is super easy to use
- pub dev is nice, and using forked packages is easy
- great community support
- works for every use case I've encountered so far (push notifications, social logins, maps, video calls, background stuff, chat, etc.)
Seriously having a hard time coming up with cons, so here are my reasons why I like it:
- dart is super easy to use
- pub dev is nice, and using forked packages is easy
- great community support
- works for every use case I've encountered so far (push notifications, social logins, maps, video calls, background stuff, chat, etc.)
Personally I’d much rather work with Flutter than RN. The tooling and general developer experience I find to be far superior.
But of course the primary advantage of RN is the ecosystem of developers and libraries it comes with, so if those are important to you I don’t believe Flutter will catch up any time soon. Personally I think those are a bit overrated. Any competent JS developer could pick up Dart very quickly, and all the various bits of browser knowledge a front end developer would have that are more valuable wouldn’t be applicable here, so to me “used before” only offers rather modest gains, and over the long run isn’t much to base a decision on.
But of course the primary advantage of RN is the ecosystem of developers and libraries it comes with, so if those are important to you I don’t believe Flutter will catch up any time soon. Personally I think those are a bit overrated. Any competent JS developer could pick up Dart very quickly, and all the various bits of browser knowledge a front end developer would have that are more valuable wouldn’t be applicable here, so to me “used before” only offers rather modest gains, and over the long run isn’t much to base a decision on.
Flutter/Dart is amazing and it's OK to have fewer libraries. The JS ecosystem is varying in quality (much more so than the Dart ecosystem, in my experience).
What I would not use Flutter for yet is Flutter Web. I've made that mistake, and although it was a big success in the end, we had many many hurdles, some of which are serious bugs that remain to this day (like you can't autofocus a field, flickering, extremely slow scrolling, etc).
What I would not use Flutter for yet is Flutter Web. I've made that mistake, and although it was a big success in the end, we had many many hurdles, some of which are serious bugs that remain to this day (like you can't autofocus a field, flickering, extremely slow scrolling, etc).
I’m really waiting for WebGPU and WASM with garbage collection to land in the browser across the board. I think both of those technologies are going to be key to unlocking a the power of Flutter web.
Yes, I agree. Interesting times ahead, but it will likely take 2-3 years.
Agreed, this is also my timeline for Flutter web becoming a more serious contender.
There are one or two other technologies/ standards that are an important piece of the puzzle like the accessibility object model to start to decouple accessibility from the rendered DOM interface for example and allow canvas based interfaces to become better supported.
But I follow a lot of that stuff pretty closely and 2-3 years seems like more than enough time, a bunch of it is probably slated to happen as early as this year (WebGPU behind a flag already on all browsers I believe, WasmGC under active development in all browsers, dart already has a functional WASM compiler and a new graphics engine ready to go and take advantage of it etc..)
Some basic details here for anyone interested in this topic https://youtu.be/kCnYRhkfWHY
There are one or two other technologies/ standards that are an important piece of the puzzle like the accessibility object model to start to decouple accessibility from the rendered DOM interface for example and allow canvas based interfaces to become better supported.
But I follow a lot of that stuff pretty closely and 2-3 years seems like more than enough time, a bunch of it is probably slated to happen as early as this year (WebGPU behind a flag already on all browsers I believe, WasmGC under active development in all browsers, dart already has a functional WASM compiler and a new graphics engine ready to go and take advantage of it etc..)
Some basic details here for anyone interested in this topic https://youtu.be/kCnYRhkfWHY
Actually, since the RN team unbundled RN and handed maintenance of non-core libraries (e.g. filesystem, keychain, gestures...) to community maintainers, a lot of these libraries have lacked maintenance, and could really use more maintainer time.
The following example comes to mind. react-native-fs is the most popular lib for filesystem I/O. From Android 10's release in Sep 2019 until Feb 2022, all file overwrite operations on Android 10 and later would result in the file getting corrupted if the new file was smaller than the pre-existing one. Related issue: https://github.com/itinance/react-native-fs/pull/890
That's a very long 2 year and a half.
My intuition to explain this situation is that the intersection of these two is very small: - orgs using RN, and thus willing to maintain it - orgs staffed with experienced Java/Kotlin or ObjC/Swift developers with the good understanding of native Android/iOS APIs needed to maintain RN libraries
The following example comes to mind. react-native-fs is the most popular lib for filesystem I/O. From Android 10's release in Sep 2019 until Feb 2022, all file overwrite operations on Android 10 and later would result in the file getting corrupted if the new file was smaller than the pre-existing one. Related issue: https://github.com/itinance/react-native-fs/pull/890
That's a very long 2 year and a half.
My intuition to explain this situation is that the intersection of these two is very small: - orgs using RN, and thus willing to maintain it - orgs staffed with experienced Java/Kotlin or ObjC/Swift developers with the good understanding of native Android/iOS APIs needed to maintain RN libraries
React native is a wrapper around OS's native controls and Flutter is a framework with it's own implementation of UI controls. Each approach has it's pros and cons.
React native now has enough useful but abandoned projects to make it a minefield. Reading through the list of changes, I know of several projects which are unmaintained that I would have to scrap in order to upgrade.
I don’t know much about flutter.
I don’t know much about flutter.
That was my experience with RN. The React ecosystem is nice but the RN specific libraries that come with native components have been nightmares.
This includes libraries from major companies that were incomplete (as in didn't implement functionality that they claimed to have in the repository readme file), badly broken, and nearly no documentation.
Once I realized how common this was, I just implemented my own native components when required. React Native itself was and is very good, good enough to make it worth using despite the minefield ecosystem.
This includes libraries from major companies that were incomplete (as in didn't implement functionality that they claimed to have in the repository readme file), badly broken, and nearly no documentation.
Once I realized how common this was, I just implemented my own native components when required. React Native itself was and is very good, good enough to make it worth using despite the minefield ecosystem.
For those of who want to try out a Flutter app, here’s a HN client I wrote recently:
https://github.com/Livinglist/Hacki
https://github.com/Livinglist/Hacki
The whole idea of “learn once, write everywhere”, React being the #1 used web framework and the sheer amount of React developers out there is something that Flutter will likely never overcome.
If you’re starting a project tomorrow, you can easily find 100 developers with years of React experience, where there are barely any experienced Flutter devs.
At that point, might as well go completely native.
If you’re starting a project tomorrow, you can easily find 100 developers with years of React experience, where there are barely any experienced Flutter devs.
At that point, might as well go completely native.
For maybe a single weeks worth of investment you could pick up Dart (the learning curve is tiny) and have that exact same value proposition of write once and run anywhere but with many other substantial advantages on top of it.
Here’s a completely arbitrary one from just yesterday that focuses on supply chain security (https://opensource.googleblog.com/2022/06/Dart-and-Flutter-e...) but this kind of thing is happening on an almost weekly basis in the background around Dart and Flutter. I don’t think people understand what’s happening behind the scenes on these projects but they are developing some very solid fundamentals to build on top of into the future.
Seriously take a look at this basic language tour, it’s incredibly familiar for anyone with an OO background out of the box https://dart.dev/guides/language/language-tour
Here’s a completely arbitrary one from just yesterday that focuses on supply chain security (https://opensource.googleblog.com/2022/06/Dart-and-Flutter-e...) but this kind of thing is happening on an almost weekly basis in the background around Dart and Flutter. I don’t think people understand what’s happening behind the scenes on these projects but they are developing some very solid fundamentals to build on top of into the future.
Seriously take a look at this basic language tour, it’s incredibly familiar for anyone with an OO background out of the box https://dart.dev/guides/language/language-tour
>you can easily find 100 developers with years of React experience
And nearly all of them completely useless. Most react devs don't even understand Fibers or have any empathy with DOM, javascript, and other parts of the common web stack, most can barely explain when something will render, what memoization is, what reference equality is and so on. It's easy to breach the 10x factor as React dev and 100x is achievable.
And nearly all of them completely useless. Most react devs don't even understand Fibers or have any empathy with DOM, javascript, and other parts of the common web stack, most can barely explain when something will render, what memoization is, what reference equality is and so on. It's easy to breach the 10x factor as React dev and 100x is achievable.
None of those matter for mobile development though, so all good
What RN will never overcome is being an unstable wrapper around unstable native UI toolkits. Pretty much everyone who used RN complains about bugs, and this is the reason.
I just saw a bunch of numbers last night that suggested Flutter had taken the title as more popular and had it beat fairly comprehensively in terms of developer experience and performance.
I’m trying to find it now but not having a lot of luck as it was a random Twitter thread that was pulling in a bunch of things from various sources, so take it for what you will in the meantime.
For what it’s worth as someone who has spent a bunch of time with Flutter at this point, none of that surprised me to hear, it’s actually a really pleasant experience, the tooling is amazing and unlike anything I had seen before as all of my experience was with web before.
It’s underlying architecture feels really solid, also despite people talking a lot of trash about it, it turns out Dart is actually a really great language as a mix between C#, Java, Kotlin and JavaScript of sorts.
I think every serious criticism I have seen levelled at both Dart and Flutter is also actively addressed on their roadmap so I also feel extremely good about the future direction of both projects.
Like in short, probably the best thing I’ve discovered in a few years code wise, would recommend checking it out.
I’m trying to find it now but not having a lot of luck as it was a random Twitter thread that was pulling in a bunch of things from various sources, so take it for what you will in the meantime.
For what it’s worth as someone who has spent a bunch of time with Flutter at this point, none of that surprised me to hear, it’s actually a really pleasant experience, the tooling is amazing and unlike anything I had seen before as all of my experience was with web before.
It’s underlying architecture feels really solid, also despite people talking a lot of trash about it, it turns out Dart is actually a really great language as a mix between C#, Java, Kotlin and JavaScript of sorts.
I think every serious criticism I have seen levelled at both Dart and Flutter is also actively addressed on their roadmap so I also feel extremely good about the future direction of both projects.
Like in short, probably the best thing I’ve discovered in a few years code wise, would recommend checking it out.
I’m not sure what to tell you from a technical perspective, in my part of the world nobody uses flutter so there is that as a disclaimer.
From a developer resource perspective, however, you use react native because it lets you share developers across platforms. Similar to how you might use nodejs on the backend for the exact same reason. If you’re splitting your developer resources anyway, I would frankly just go native mobile department.
From a developer resource perspective, however, you use react native because it lets you share developers across platforms. Similar to how you might use nodejs on the backend for the exact same reason. If you’re splitting your developer resources anyway, I would frankly just go native mobile department.
They both have their issues, to be honest. I'd probably still pick RN though if I was going for cross-platform, despite its warts. Not convinced by Flutter at all yet. We're using Kotlin Multiplatform and Swift/Kotlin UI on a project I'm on now, but that might not be ideal for very small teams or a solo developer.
What is the reason for not releasing a v1 after so many years?
Checkout ZeroVer: 0-based Versioning https://0ver.org/
Probably psychological: major version change equals in people's minds to some marketing event/website announcement, developers/users meeting etc. Which is not how semver was designed. For this kind of event developers should reserve subname, like macOS Mojave, Monterey etc.
you don't simply skip v0.69 ... hehe
[deleted]
I am not primarily a front end developer but I am always intrigued by React as a way to develop UI (Its significantly better than having a separate XML).
Several things that bother me right now is while working on personal projects involving React:
1. Generating unique ID for debugging purposes. Currently, I simply use the project directory "component-user-settings-name".
2. React claims "As a React developer, you focus on what you want the user experience to look like, and React handles how to deliver that experience"[1] but this is not always true. JS have something like COW memory management and AFAIK, React already requires you to make a full clone for each render (if the object changes) so you _really_ want to avoid them if possible. So you actually do care what React does internally thus I wonder if the COW semantic can be made clearer.
3. You sometimes have to do object of arrays instead of array of objects when you have a short list of very complex objects. The fact that I have to care about this is unfortunate, as refactoring from one to the other is not always straightforward, especially when you need to consider if you changes will cause JS to make clones.
I also wish React can be transpiled/compiled into a much lower level language with clearer performance characteristics. I think Slint UI is the closest that I can find.
[1] https://reactjs.org/blog/2022/03/29/react-v18.html
1. Generating unique ID for debugging purposes. Currently, I simply use the project directory "component-user-settings-name".
2. React claims "As a React developer, you focus on what you want the user experience to look like, and React handles how to deliver that experience"[1] but this is not always true. JS have something like COW memory management and AFAIK, React already requires you to make a full clone for each render (if the object changes) so you _really_ want to avoid them if possible. So you actually do care what React does internally thus I wonder if the COW semantic can be made clearer.
3. You sometimes have to do object of arrays instead of array of objects when you have a short list of very complex objects. The fact that I have to care about this is unfortunate, as refactoring from one to the other is not always straightforward, especially when you need to consider if you changes will cause JS to make clones.
I also wish React can be transpiled/compiled into a much lower level language with clearer performance characteristics. I think Slint UI is the closest that I can find.
[1] https://reactjs.org/blog/2022/03/29/react-v18.html
Is anyone in the wild using herems? I tried upgrading our app to hermes but not all our dependencies were ready yet (think you need turbo modules?)? What issues did you encounter?
Not anything exciting for me in 0.69 :(
Not anything exciting for me in 0.69 :(
I use Hermes and have had zero issues with it. I use quite a bunch of native libraries.
[deleted]
[deleted]
[deleted]
tadpol(1)
Reason is simple. React Native abstracts only platform away by exposing base components. If you really need something for a specific platform it is very easy to write a custom plugin - so you will need some platform knowledge. I have used flutter as well but must admit it feels not the way as I would like to have - especially the shader compilation if a component gets shown for the first time I feel annoying.
So to me react native is best - but comes with its own pain points like updates...
If you can afford it go pure native and try to write business logic in a shareable language e.g. Rust, C, C++, Kotlin native... and integrate the UI based on the platform.
If thats not an option I recommend react native + if needed custom modules and try to not use too many third party libs.