It's an extremely conservative language, offering little to nothing interesting that would make anyone switch from other solutions.
The ecosystem doesn't help it either:
For the frontend, it's stuck in a middle ground where it requires a JS interop layer (unlike TS, where it's typings are just an extra) but doesn't offer anything significant like Elm, BuckleScript, F#, ClojureScript and so many other great languages do when it comes to expresiveness. It doesn't even have algebraic data types, something TS does.
For the backend, it competes against almost all the frontend languages (due to node or native) as well as the big boys with huge ecosystems, variety of paradigms and amazing performance.
For mobile it has Flutter, which competes with Xamarin, Kivy, Qt and other bring-your-own-widgets solutions (deal-breaker for some apps and teams). In this case, Flutter is something I wanted to try out since those other solutions left me wanting and so did React Native, but Dart being such a lackluster language completely put me off of it, now having to turn to native with Kotlin after all this time looking at (and somewhat helping develop) the x-plat ecosystem.
I don't doubt that Dart will remain healthy for a long time due to Google's investment in it, but honestly, even if Fuchsia ends up being Android's succesor and Flutter ends up as its graphical toolkit, I'd instantly start looking for languages targeting the Dart VM or native interop.
The three biggest issues I have with it are these:
1) Language. Elm has set the standard for web languages and after using it for a while, JS or many of the popular replacements such as TypeScript are plain insufficient when it comes to providing as many compile-time safety guarantees. Doesn't help that I'm getting into Idris and even Elm's shoes are starting to feel a little too tight.
There's a project to write Elm and target React Native, but it's still too immature and it makes the next two issues worse.
I've yet to look at RN development through a BuckleScript stack, so that may be an acceptable alternative (even if not as safe as Elm, but on par/better than Kotlin)... but won't help at all with the next point.
2) Requires very complex tooling. This complexity will rear its ugly head when doing anything slightly out of the ordinary. All solutions (including Expo) I've seen seem to suffer from that issue, just with different defaults and different amounts of work necessary for different tasks.
I am not oblivious to why this is, since RN is not only based around the JS ecosystem and all the insanity that comes with it, it also has to deal with being a fat abstraction over native rather than take the easy way out, rolling its own cross-plat rendering and give up native widgets.
3) While it has come a long, long way, performance on old Android devices is still not always as smooth as native. I'm not sure how much this can realistically be improved since the bottleneck is interop, and avoiding it or shifting work around between native and JS is just not something I want to worry about.
However, this third point has improved so much I'm ready to handwave it away if the former two weren't a thing.
Lastly, not an issue with React Native itself, but JetBrains absolutely has the intention to bite into iOS' territory with Kotlin Native... and assuming they can pull off a half-decent adaptation of Apple's APIs I'm betting they will be the ones to finally take the x-plat cake, which makes it hard for me to believe investing time and code into RN solutions is a better proposition than native.
Hope that was useful in some way. If I should clarify anything or I have any misconception about RN please let me know.
" offering little to nothing interesting that would make anyone switch from other solutions"
Huh ? Compared to JS - Dart seems like a heaven. Don't known Elm - but looking on syntax it seems it's not so easy to pick up as for someone with Java/C# background. It's true Dart is not another fancy lang - it's very pragmatic.
Compared to JS, yes. But it's not JS that Dart truly competes against, it's all the other compile-to-JS languages some of which I mentioned, and Dart simply can't beat their pragmatism and/or expresiveness.
Elm is deceptively easy since it has great docs, the best compiler errors in the entire industry (no exaggeration here) and skips all the voodoo incantations of pure functional programming favoring a familiar language instead. Took me a couple of days to start writing toy websites with it coming with no functional experience, and a week to be productive.
It's an extremely conservative language, offering little to nothing interesting that would make anyone switch from other solutions.
The ecosystem doesn't help it either:
For the frontend, it's stuck in a middle ground where it requires a JS interop layer (unlike TS, where it's typings are just an extra) but doesn't offer anything significant like Elm, BuckleScript, F#, ClojureScript and so many other great languages do when it comes to expresiveness. It doesn't even have algebraic data types, something TS does.
For the backend, it competes against almost all the frontend languages (due to node or native) as well as the big boys with huge ecosystems, variety of paradigms and amazing performance.
For mobile it has Flutter, which competes with Xamarin, Kivy, Qt and other bring-your-own-widgets solutions (deal-breaker for some apps and teams). In this case, Flutter is something I wanted to try out since those other solutions left me wanting and so did React Native, but Dart being such a lackluster language completely put me off of it, now having to turn to native with Kotlin after all this time looking at (and somewhat helping develop) the x-plat ecosystem.
I don't doubt that Dart will remain healthy for a long time due to Google's investment in it, but honestly, even if Fuchsia ends up being Android's succesor and Flutter ends up as its graphical toolkit, I'd instantly start looking for languages targeting the Dart VM or native interop.