React Native 0.69
reactnative.dev
reactnative.dev
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.
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
https://reactnative.dev/docs/hermes#confirming-hermes-is-in-...
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.
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.
There's also new rendering engine being worked on for Flutter called Impeller. It's not just React Native that's improving.
edit: silly mistake Android is open source, not sure how much it helps when compatibility layer is not a priority for the OS developers
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.
Either way thanks for the link, I’ll check it out.
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.
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?
Why would people keep doing it in HN, and some of those accounts aren't event that new...
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.
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.
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.)
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.
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).
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
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
I don’t know much about flutter.
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.
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.
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
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.
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.
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.
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.
Not anything exciting for me in 0.69 :(
Or maybe it is just my fixated beliefs that 0.x are unstable and 1.x are stable.