7 ms·

What do you dislike about React Native?

110 points by daanavitch 8y ago

debt 8y ago
It would be tight if we could purge from the web all posts and threads related to unsupported and outdated ReactNative versions. It's actually quite interesting to see the almost in real-time development of ReactNative through the lens of hobbled and broke-ass solutions to problems associated with deprecated RN versions posted on StackOverflow or Medium.
- bdcravens 8y ago
  Every technology has to deal with this problem.
- SketchySeaBeast 8y ago
  Ack, no! We need to find a way to version it, absolutely, but as I'm currently crawling through a codebase that's using an old version of react, I need those old threads.
- paraditedc 8y ago
  As someone who used to write frontend blog posts, I found this issue particularly frustrating, as an author. I have posts about Angular.js, webpack, React Apollo, etc and they become outdated every 6 months. The problem is that I wouldn't know about it. Despite having lots pageviews and me asking readers to help notify me in comments, people just come, read and close the window. So the one way I found out they were outdated is when I actually went back to reference them for my own work. It's not fun.
  - warmblanket 8y ago
    I think it’s a good idea to list versions at the top of the articles.
- burtonator 8y ago
  This is actually a problem that could be solved by naming actually. Angular has a similar problem because if you search for an olde version of Angular you get 2.x and they're up to 7 now... I think at some point it makes sense to rename the project to avoid the cruft of the past when it really deserves it.
  - EpicEng 8y ago
    I'm emphatically _not_ a front end dev, but recently I've needed to do some front end work on an existing AngularJs project. It took me about an hour to realize that AngularJs != Angular. A bunch of examples weren't working and I just couldn't figure out why...
SalimoS 8y ago
Facebook
- brink 8y ago
  How dare they do something good for the community
  - mchannon 8y ago
    There are many who would call unleashing React Native on the ecosystem anything but. In fact I went to the trouble of writing a whole website on the subject: www.xn--ls8h.st.
    - pkroll 8y ago
      By whole website, you mean of course, you bought a domain and put ONE PAGE up. And "there are many" flat earthers: is there a meaningful number of people who would say Facebook releasing React Native is a net negative for the community?
      - mchannon 8y ago
        Is that an honest question? Take a look at the dozens of posts in the parent article and tell me the quantity isn’t meaningful.
deleted 8y ago
[deleted]
shujito 8y ago
app bloat, the app size is too big for a simple example
dep_b 8y ago
* Javascript * NPM * It's still 0.59 or something and things are constantly breaking * Because of that every piece of information older than 1 month should be distrusted * App size * It doesn't play well when you try to gradually replace or add RN screens to an existing application. * There are multiple ways to do the same thing * It adds another layer on top of the iOS and Android builds
- EpicEng 8y ago
  * Javascript * NPM * It's still 0.59 or something and things are constantly breaking * Because of that every piece of information older than 1 month should be distrusted * App size * It doesn't play well when you try to gradually replace or add RN screens to an existing application. * There are multiple ways to do the same thing * It adds another layer on top of the iOS and Android builds
  - dep_b 8y ago
    Thanks! Fixed it.
vmarsy 8y ago
it'd be cool if there was a simple way to create typescript react-native app, similar to create-react-native-app[1] without a dependency on Babel[2] [1] https://facebook.github.io/react-native/blog/2017/03/13/introducing-create-react-native-app https://facebook.github.io/react-native/blog/2017/03/13/intr... [2] https://facebook.github.io/react-native/blog/2018/05/07/using-typescript-with-react-native https://facebook.github.io/react-native/blog/2018/05/07/usin...
JoeCortopassi 8y ago
Companies and teams don’t usually pick non-native solutions because they're better tech. Non-native solutions are picked so that teams can be more efficient with their time/resources. For some teams, that means delivering an app cheaper. For other teams, that means being able to spread resources thinner and stretch budgets. This doesn't have to be a bad thing per se, it's just a business decision. As a former iOS engineer, I for one really enjoy React Native. But I feel like it's focus is trying to maintain/supersede native development, where it's time and attention would be better served focusing on the efficiency of average developers on average tasks
- holografix 8y ago
  Great insight. How can we use something similar to Interface Builder to create React Native apps?
malvosenior 8y ago
You can develop native apps in languages that range from ok, to really good (Java -> Swift). Javascript is a terrible language for many reasons (lack of a decent standard lib, weak typing, foot guns galore, psychotic build pipeline and tooling...). React Native encourages more JS development so I dislike it for that reason.
- cityzen 8y ago
  Thanks for "foot guns". Have never heard it but like it!
alsothrownaway 8y ago
I think it's constructive to point out that maybe the entire project, being a "hack" of sorts that tends to breed more hacks and more debt, ultimately isn't useful or valuable. The idea is wonderful, but in practice I still have to maintain cross-platform code that has nothing to do with wireup, and honestly think everyone should seriously consider writing portable code and plugging it into truly native projects. React Native multiplies the complexity of a project so much that IMHO it completely negates its own usefulness.
throwaway66666 8y ago
I will probably be heavily downvoted but here goes nothing. I have not used React Native yet, but I followed and was heavily invested in the "write once deploy anywhere" trend between 2009 - 2014. From phonegap (before it became cordova), to Adobe Air with it's bad performance and "native extensions", to Appcelerator Titanium that put a nodejs server in your phone and even had Windows Phone 7 support, to cordova, to Haxe, to sencha and others. Appcelerator Titanium was the only ones that did real native for some cases like scrollviews, Haxe used custom C++ apis, the rest used webviews, and adobe air was basically flash emulated that ran like shit. Write once deploy anywhere, meant write once, deploy somewhat anywhere, spend double the time to make that promise true. Kinda like having to do IE6 support in the past. I was deep in that madness up until mid-2014. At that point I decided to buy a macbook and give native development a try (obj-c for ios and java for android -- When I say native I mean real native and not React Native). What a magical experience! Things that are tough to do in web even today, like real never-ending scroll lists, are a breeze in native with their reusable cells. Things like standard headers and modals, are already built in and a few lines away. And I actually prefer the touch event handlers on both ios and android to the web's "mouse/touch/PointerEvents" ones. I do not understand why web developers have such a knee jerk reaction to native development. ObjectiveC/Swift and Java are actually easy to write. Tooling (especially for ios) is fantastic. In my experience, it is much faster to write UI interfaces in Objective C and Swift (I never use xcode's UI builder) than html+JS. But the real joy is being able to harness the real power of your phone. I run some C++ algorithms on both ios and android (I guess C/C++ is the original cross platform) that on android are faster than the built-in Java apis themselves! And of course, true multithreading! But here we are, non-stop chasing the "no! I want javascript in my frontend, and in my servers, and javascript in my ios apps and android too!" dream. Perhaps React Native accomplishes that. I hope it really does and solves that decade-long promise of "write once deploy anywhere". I guess all what I 'm trying to say is, don't be afraid of native people! Web devs are willing to go through insane hoops and loops instead of just... giving the real thing a go. So weird.
- gaze 8y ago
  I think deep down people understand that native development is better but somehow there's too much inertia behind everything being browser based. It's really frustrating. I genuinely miss Delphi.
pauliusj 8y ago
For me it feels like RN is still not ready for an enjoyable development experience (it feels more around alpha/beta version), which maybe it is because the version is 0.57 or somewhere around that. The main problems I have with RN are: * Cryptic error messages. Out of maybe hundreds of errors/crashes I had while developing a medium sized app, only a few of them provided useful info about what/where happened. * Lot's of outdated/abandonware/low-quality libs in the ecosystem. You really have to be careful when picking the dependencies. * Fragile and complex builds. You'll have to use dependencies to make anything more than a basic app (unless you want to DIY), so get ready for some "fun" when upgrading the project because not all of the dependencies will be upgraded at the same time, might also often have the APK/IPA or development builds fail because of dependencies not properly installing or not playing nicely with one another. * Lots of little stuff. For example, I had the ios simulator logs not work out of the box when launching with "react-native log-ios", so had to use a third-party solution for that. Metro bundler sometimes just breaks. I still have a problem of the app randomly closing down after some time on iOS, which I did not look deeply into yet but will have to solve before release. Constant issues with nesting scroll views on android. Hard to predict cross-platform inconsistencies in layout behaviour in some places. Can't name everything right now but they played on the nerves throughout the development. I hope it gets better some day, but until then I'll probably look for alternatives for my next project as I wasn't very happy with RN.
- JofArnold 8y ago
  This is a good and fair summary. It is a frustrating developer experience for sure - especially Android.
- atosatto 8y ago
  We had the same bug about random crashes in production and surprisingly we found that the problem was caused by console logging. There's a babel plugin that can help to remove console logging only in production, something like remove-console-log
pier25 8y ago
I tried RN in early 2016 but Android support and documentation were not great. Honestly, I've always thought that RN (and similar approaches) is kinda a hack. Yes, it solves a problem of reducing developer time across platforms, but it introduces other more obscure problems. A JavaScript engine with it's own set of problems giving orders through some bridge to the native part... I don't know, it's a lot of moving pieces. I feel Flutter is so much more solid in this respect. The approach has been used countless times by game engines such as Unity, UE, etc. The part where Google has to replicate the UI elements of each platform is not amazing, but otherwise I feel it's a much more solid approach than RN.
- darpa_escapee 8y ago
  I got a similar impression from ReactNative: it felt like a hack, and the hack came apart at the seams if you tried to debug it. Similarly, Flutter felt much more like a cohesive solution compared to RN.
reverite 8y ago
A few friends and I have noticed that applications that are using React Native, even in the best of situations in optimizing, it still drains battery life faster (sometimes far faster) than something written in Java/Kotlin or ObjC/Swift.
- deleted 8y ago
  [deleted]
- fitpolar 8y ago
  Do you have any examples of that, and how do you determine which apps are built with RN? I've noticed a similar thing, but have nothing to go on but my gut instinct. For instance, I'm pretty sure that the food ordering app Ritual is using RN, it just doesn't feel quite native.
  - reverite 8y ago
    I'm a little late to reply. I use Discord and Slack a lot which uses RN but I've noticed that there are frame stutters when scrolling or when viewing gifs, and other chat applications like Telegram (native) do not have this problem. The stuttering is how I notice if they're using RN or not here.

110 points by daanavitch 8y ago

debt 8y ago

It would be tight if we could purge from the web all posts and threads related to unsupported and outdated ReactNative versions. It's actually quite interesting to see the almost in real-time development of ReactNative through the lens of hobbled and broke-ass solutions to problems associated with deprecated RN versions posted on StackOverflow or Medium.

bdcravens 8y ago
Every technology has to deal with this problem.
SketchySeaBeast 8y ago
Ack, no! We need to find a way to version it, absolutely, but as I'm currently crawling through a codebase that's using an old version of react, I need those old threads.
paraditedc 8y ago
As someone who used to write frontend blog posts, I found this issue particularly frustrating, as an author. I have posts about Angular.js, webpack, React Apollo, etc and they become outdated every 6 months. The problem is that I wouldn't know about it. Despite having lots pageviews and me asking readers to help notify me in comments, people just come, read and close the window. So the one way I found out they were outdated is when I actually went back to reference them for my own work. It's not fun.
- warmblanket 8y ago
  I think it’s a good idea to list versions at the top of the articles.
burtonator 8y ago
This is actually a problem that could be solved by naming actually. Angular has a similar problem because if you search for an olde version of Angular you get 2.x and they're up to 7 now... I think at some point it makes sense to rename the project to avoid the cruft of the past when it really deserves it.
- EpicEng 8y ago
  I'm emphatically _not_ a front end dev, but recently I've needed to do some front end work on an existing AngularJs project. It took me about an hour to realize that AngularJs != Angular. A bunch of examples weren't working and I just couldn't figure out why...

SalimoS 8y ago

Facebook

brink 8y ago
How dare they do something good for the community
- mchannon 8y ago
  There are many who would call unleashing React Native on the ecosystem anything but. In fact I went to the trouble of writing a whole website on the subject: www.xn--ls8h.st.
  - pkroll 8y ago
    By whole website, you mean of course, you bought a domain and put ONE PAGE up. And "there are many" flat earthers: is there a meaningful number of people who would say Facebook releasing React Native is a net negative for the community?
    - mchannon 8y ago
      Is that an honest question? Take a look at the dozens of posts in the parent article and tell me the quantity isn’t meaningful.

deleted 8y ago

[deleted]

shujito 8y ago

app bloat, the app size is too big for a simple example

dep_b 8y ago

* Javascript * NPM * It's still 0.59 or something and things are constantly breaking * Because of that every piece of information older than 1 month should be distrusted * App size * It doesn't play well when you try to gradually replace or add RN screens to an existing application. * There are multiple ways to do the same thing * It adds another layer on top of the iOS and Android builds

EpicEng 8y ago
* Javascript * NPM * It's still 0.59 or something and things are constantly breaking * Because of that every piece of information older than 1 month should be distrusted * App size * It doesn't play well when you try to gradually replace or add RN screens to an existing application. * There are multiple ways to do the same thing * It adds another layer on top of the iOS and Android builds
- dep_b 8y ago
  Thanks! Fixed it.

vmarsy 8y ago

it'd be cool if there was a simple way to create typescript react-native app, similar to create-react-native-app[1] without a dependency on Babel[2] [1] https://facebook.github.io/react-native/blog/2017/03/13/introducing-create-react-native-app https://facebook.github.io/react-native/blog/2017/03/13/intr... [2] https://facebook.github.io/react-native/blog/2018/05/07/using-typescript-with-react-native https://facebook.github.io/react-native/blog/2018/05/07/usin...

JoeCortopassi 8y ago

Companies and teams don’t usually pick non-native solutions because they're better tech. Non-native solutions are picked so that teams can be more efficient with their time/resources. For some teams, that means delivering an app cheaper. For other teams, that means being able to spread resources thinner and stretch budgets. This doesn't have to be a bad thing per se, it's just a business decision. As a former iOS engineer, I for one really enjoy React Native. But I feel like it's focus is trying to maintain/supersede native development, where it's time and attention would be better served focusing on the efficiency of average developers on average tasks

holografix 8y ago
Great insight. How can we use something similar to Interface Builder to create React Native apps?

malvosenior 8y ago

You can develop native apps in languages that range from ok, to really good (Java -> Swift). Javascript is a terrible language for many reasons (lack of a decent standard lib, weak typing, foot guns galore, psychotic build pipeline and tooling...). React Native encourages more JS development so I dislike it for that reason.

cityzen 8y ago
Thanks for "foot guns". Have never heard it but like it!

alsothrownaway 8y ago

I think it's constructive to point out that maybe the entire project, being a "hack" of sorts that tends to breed more hacks and more debt, ultimately isn't useful or valuable. The idea is wonderful, but in practice I still have to maintain cross-platform code that has nothing to do with wireup, and honestly think everyone should seriously consider writing portable code and plugging it into truly native projects. React Native multiplies the complexity of a project so much that IMHO it completely negates its own usefulness.

throwaway66666 8y ago

I will probably be heavily downvoted but here goes nothing. I have not used React Native yet, but I followed and was heavily invested in the "write once deploy anywhere" trend between 2009 - 2014. From phonegap (before it became cordova), to Adobe Air with it's bad performance and "native extensions", to Appcelerator Titanium that put a nodejs server in your phone and even had Windows Phone 7 support, to cordova, to Haxe, to sencha and others. Appcelerator Titanium was the only ones that did real native for some cases like scrollviews, Haxe used custom C++ apis, the rest used webviews, and adobe air was basically flash emulated that ran like shit. Write once deploy anywhere, meant write once, deploy somewhat anywhere, spend double the time to make that promise true. Kinda like having to do IE6 support in the past. I was deep in that madness up until mid-2014. At that point I decided to buy a macbook and give native development a try (obj-c for ios and java for android -- When I say native I mean real native and not React Native). What a magical experience! Things that are tough to do in web even today, like real never-ending scroll lists, are a breeze in native with their reusable cells. Things like standard headers and modals, are already built in and a few lines away. And I actually prefer the touch event handlers on both ios and android to the web's "mouse/touch/PointerEvents" ones. I do not understand why web developers have such a knee jerk reaction to native development. ObjectiveC/Swift and Java are actually easy to write. Tooling (especially for ios) is fantastic. In my experience, it is much faster to write UI interfaces in Objective C and Swift (I never use xcode's UI builder) than html+JS. But the real joy is being able to harness the real power of your phone. I run some C++ algorithms on both ios and android (I guess C/C++ is the original cross platform) that on android are faster than the built-in Java apis themselves! And of course, true multithreading! But here we are, non-stop chasing the "no! I want javascript in my frontend, and in my servers, and javascript in my ios apps and android too!" dream. Perhaps React Native accomplishes that. I hope it really does and solves that decade-long promise of "write once deploy anywhere". I guess all what I 'm trying to say is, don't be afraid of native people! Web devs are willing to go through insane hoops and loops instead of just... giving the real thing a go. So weird.

gaze 8y ago
I think deep down people understand that native development is better but somehow there's too much inertia behind everything being browser based. It's really frustrating. I genuinely miss Delphi.

pauliusj 8y ago

For me it feels like RN is still not ready for an enjoyable development experience (it feels more around alpha/beta version), which maybe it is because the version is 0.57 or somewhere around that. The main problems I have with RN are: * Cryptic error messages. Out of maybe hundreds of errors/crashes I had while developing a medium sized app, only a few of them provided useful info about what/where happened. * Lot's of outdated/abandonware/low-quality libs in the ecosystem. You really have to be careful when picking the dependencies. * Fragile and complex builds. You'll have to use dependencies to make anything more than a basic app (unless you want to DIY), so get ready for some "fun" when upgrading the project because not all of the dependencies will be upgraded at the same time, might also often have the APK/IPA or development builds fail because of dependencies not properly installing or not playing nicely with one another. * Lots of little stuff. For example, I had the ios simulator logs not work out of the box when launching with "react-native log-ios", so had to use a third-party solution for that. Metro bundler sometimes just breaks. I still have a problem of the app randomly closing down after some time on iOS, which I did not look deeply into yet but will have to solve before release. Constant issues with nesting scroll views on android. Hard to predict cross-platform inconsistencies in layout behaviour in some places. Can't name everything right now but they played on the nerves throughout the development. I hope it gets better some day, but until then I'll probably look for alternatives for my next project as I wasn't very happy with RN.

JofArnold 8y ago
This is a good and fair summary. It is a frustrating developer experience for sure - especially Android.
atosatto 8y ago
We had the same bug about random crashes in production and surprisingly we found that the problem was caused by console logging. There's a babel plugin that can help to remove console logging only in production, something like remove-console-log

pier25 8y ago

I tried RN in early 2016 but Android support and documentation were not great. Honestly, I've always thought that RN (and similar approaches) is kinda a hack. Yes, it solves a problem of reducing developer time across platforms, but it introduces other more obscure problems. A JavaScript engine with it's own set of problems giving orders through some bridge to the native part... I don't know, it's a lot of moving pieces. I feel Flutter is so much more solid in this respect. The approach has been used countless times by game engines such as Unity, UE, etc. The part where Google has to replicate the UI elements of each platform is not amazing, but otherwise I feel it's a much more solid approach than RN.

darpa_escapee 8y ago
I got a similar impression from ReactNative: it felt like a hack, and the hack came apart at the seams if you tried to debug it. Similarly, Flutter felt much more like a cohesive solution compared to RN.

reverite 8y ago

A few friends and I have noticed that applications that are using React Native, even in the best of situations in optimizing, it still drains battery life faster (sometimes far faster) than something written in Java/Kotlin or ObjC/Swift.

deleted 8y ago
[deleted]
fitpolar 8y ago
Do you have any examples of that, and how do you determine which apps are built with RN? I've noticed a similar thing, but have nothing to go on but my gut instinct. For instance, I'm pretty sure that the food ordering app Ritual is using RN, it just doesn't feel quite native.
- reverite 8y ago
  I'm a little late to reply. I use Discord and Slack a lot which uses RN but I've noticed that there are frame stutters when scrolling or when viewing gifs, and other chat applications like Telegram (native) do not have this problem. The stuttering is how I notice if they're using RN or not here.