What do you dislike about React Native?(github.com)
github.com
What do you dislike about React Native?
https://github.com/react-native-community/discussions-and-proposals/issues/64
61 comments
Everyone intrinsically understands that native is better, and I'm saying this as somebody who runs a 120k LoC Electron app (https://getaether.net) myself.
I'm painfully aware that native is better, all day, every day.
The problem is this: I'm a solo founder. I am both the engineer and designer (and PM). The alternative for me would be not to write a Mac app, a Windows app, and a Linux app separately, and have them work.
The alternative would be for Aether to not exist.
You're expressing a sentiment that everyone feels, but you're off on why — it's not change aversion, but the simple fact that these technologies make trying new things cheaper, things, by definition, that would be too expensive to try in slower-to-build tech.
In my case, a compromise I found worked was to use JS for just the UI and write all code that does something in Go. Since that code is native binary, it's fast and efficient. Vue in Electron handles the 'client' UI, and interacts with the Go app binaries via gRPC.
I'm painfully aware that native is better, all day, every day.
The problem is this: I'm a solo founder. I am both the engineer and designer (and PM). The alternative for me would be not to write a Mac app, a Windows app, and a Linux app separately, and have them work.
The alternative would be for Aether to not exist.
You're expressing a sentiment that everyone feels, but you're off on why — it's not change aversion, but the simple fact that these technologies make trying new things cheaper, things, by definition, that would be too expensive to try in slower-to-build tech.
In my case, a compromise I found worked was to use JS for just the UI and write all code that does something in Go. Since that code is native binary, it's fast and efficient. Vue in Electron handles the 'client' UI, and interacts with the Go app binaries via gRPC.
But why Electron? There are other cross-platform solutions with great performance.
There are no equivalents to electron. You either use a browser, or you get stuck in someone else's lacking UI, like qt. Electron just works, and that's why it's everywhere.
Qt actually performs better than Electron and works everywhere and
What you want is cross-platform:
- Web (IE, Safari, Firefox, Chrome, and older versions of those browsers)
- Web responsive (When you access it from small screens or access the web from your phone's browser)
- Android (old devices to recent ones)
- iOS (old devices to recent ones)
- And, eventually, get to a desktop app, ideally on windows, mac and linux.
The fact is, only very rarely are you in a team of 2-3 devs and you need to support ALL of these platforms. If that’s the case for a small startup, serious strategic errors and lack of focus is being made by the founders!
Even Instagram didn’t even have an Android app until they were acquired, and then it still took them another couple of years to support web. Their focus was their success.
Even Instagram didn’t even have an Android app until they were acquired, and then it still took them another couple of years to support web. Their focus was their success.
To be fair, Instagram didn’t have an Android app a long while ago. The Android market & demographic has changed a lot since, with high-end Android phones sporting great screens, cameras and costing nearly as much as the iPhone.
An Instagram launching today would see much greater pressure to be on Android sooner rather than later.
An Instagram launching today would see much greater pressure to be on Android sooner rather than later.
That’s true, and a good point that I should take into account when confronted with this decision in future.
Depends on what you're building. But sure, if you can remove the "cross-platform" spec. and say just build a desktop app on Linux, use whatever suits your boat.
Personally, I find it amazing to have one engineer builds a feature end-to-end from the server to the web/mobile devices by using the same language and re-using 90% of the code across all the clients.
Personally, I find it amazing to have one engineer builds a feature end-to-end from the server to the web/mobile devices by using the same language and re-using 90% of the code across all the clients.
Seconded this. The downside is you have to use C++ to beat Javascript performance. You can use Python of course but it is kinda slow.
The first version of Aether was in fact just that, Qt + Python. The performance was abysmal.
I agree with you that on desktop the situation is a bit different. I 've only played around with UI on OSX, and for some reason it is way harder than native ui on ios (old NextStep api vs UI api).
Fonts are handled differently. The coordinate system is different (starting from the bottom left corner if I remember correctly). Coding for multiple screens; like tracking pointer position on windows on different screens is awkward. Lots and lots of legacy stuff.
Perhaps windows is better? What about linux? :p But I see why people are disliking the native ui situation on desktop.
Perhaps windows is better? What about linux? :p But I see why people are disliking the native ui situation on desktop.
Native UI is nice for system dialogs and programs associated with the system in some manner. I wouldn't want a harddrive formatting software to be using some transitioney css+js.
But I would want my media player, or chat application, or something that's meant to be a media-based experience to be well presented.
But I would want my media player, or chat application, or something that's meant to be a media-based experience to be well presented.
I took a look at a large list of apps that uses electron. I found three that would actually have significant user bases. It might be used everywhere, just no one is using the result.
> The alternative would be for Aether to not exist.
Do you really think the only options are to target all platforms or none? There's nothing wrong with being platform specific and building other clients later, if you were specifically building an MVP then this would be the minimum.
Do you really think the only options are to target all platforms or none? There's nothing wrong with being platform specific and building other clients later, if you were specifically building an MVP then this would be the minimum.
You’re already limiting yourself by being desktop only, which I have to for the time being, because of its P2P nature. At that point, you don’t get to choose what to support.
I agree with most of the things you've said. But here's the thing: Even if you are able to write native apps in Objective C, Swift, and Java, React Native still saves you an enormous amount of time. And you don't have to do everything in JavaScript.
I'm a web developer who got into native iOS development, and then I built an app with React Native. I was blown away by how much easier it is to build a cross-platform iOS and Android app. But I think it's also a much better choice even if you're just building an iOS app.
But you can't be afraid of writing your own native libraries in multiple languages, or fixing bugs in open source projects. I built a write-once-deploy-anywhere app that runs on iOS, Android, Windows Phone, Windows Desktop, and the web (with react-native-web). It was a pretty magical experience and I would do it again. There were lots of challenges and bugs to figure out, but I enjoyed it much more than working in XCode with Swift and UIKit.
I'll definitely be using React Native for any mobile apps in the future, even if I'm just targeting a single platform (e.g. ARKit on iOS). I just love building the UI with React and managing state with Redux.
It could be a lot better, though. There's just not enough people working on it, and GitHub issues can go unresolved for months or years. And it hasn't been very easy to upgrade to newer versions. But on the whole, React Native is awesome.
I'm a web developer who got into native iOS development, and then I built an app with React Native. I was blown away by how much easier it is to build a cross-platform iOS and Android app. But I think it's also a much better choice even if you're just building an iOS app.
But you can't be afraid of writing your own native libraries in multiple languages, or fixing bugs in open source projects. I built a write-once-deploy-anywhere app that runs on iOS, Android, Windows Phone, Windows Desktop, and the web (with react-native-web). It was a pretty magical experience and I would do it again. There were lots of challenges and bugs to figure out, but I enjoyed it much more than working in XCode with Swift and UIKit.
I'll definitely be using React Native for any mobile apps in the future, even if I'm just targeting a single platform (e.g. ARKit on iOS). I just love building the UI with React and managing state with Redux.
It could be a lot better, though. There's just not enough people working on it, and GitHub issues can go unresolved for months or years. And it hasn't been very easy to upgrade to newer versions. But on the whole, React Native is awesome.
I don't think it saves as much time as it's often touted to. I've found the OP's point that you spend double the time to make the write once promise true more of a factor. I believe that what everyone is seeing currently is very small deposits of code being used in new apps. Wait until those apps become 3,4,5 years old and the strain of feature creep will start to show just like it always does in software.
I think the main advantage is the flexibility of it. Just like you said that you "love building the UI with React", then go for it. Personally I love Xcode and Android Studio. The ability to run the app right out of the box, and the performance measuring tools, especially when it comes to threading, are unmatched to what is offered in Chrome. Whatever suits a developer's passion and skill, to enable them to build with a CHOICE of languages and tools, that's the main benefit of React Native. It also introduces a bunch of web developers into Kotlin and Swift, and they might get a taste of it being not as intimidating as they think it is.
I think the main advantage is the flexibility of it. Just like you said that you "love building the UI with React", then go for it. Personally I love Xcode and Android Studio. The ability to run the app right out of the box, and the performance measuring tools, especially when it comes to threading, are unmatched to what is offered in Chrome. Whatever suits a developer's passion and skill, to enable them to build with a CHOICE of languages and tools, that's the main benefit of React Native. It also introduces a bunch of web developers into Kotlin and Swift, and they might get a taste of it being not as intimidating as they think it is.
>I will probably be heavily downvoted but here goes nothing.
>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.
And the weirder thing is the expectation of getting downvoted when expressing anything that dares to question the accepted religion. Despite making a polite and well presented argument, embedded in real experience. It's a shame.
It's almost like javascript developers prefer diversifying over 100 different frameworks than diversifying 1-2 different languages. All of this while Swift and Kotlin are very close to javascript. The learning curve is way easier than going from Angular to React.
>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.
And the weirder thing is the expectation of getting downvoted when expressing anything that dares to question the accepted religion. Despite making a polite and well presented argument, embedded in real experience. It's a shame.
It's almost like javascript developers prefer diversifying over 100 different frameworks than diversifying 1-2 different languages. All of this while Swift and Kotlin are very close to javascript. The learning curve is way easier than going from Angular to React.
> I do not understand why web developers have such a knee jerk reaction to native development.
So this is a one-off anecdote, but my experience with my teammates at work is that it's not so much an objection to native development, but an objection to having to learn more. Over half took a bootcamp-style class for web development after having never done any programming before, and managed to get hired. Their current status:
* One has kept on learning, and I see no issues with them doing native development if they ever encountered it; they have the right mindset to teach themselves.
* One has been on the team nearly as long as the first, but seems to be stuck in a rut. They've not progressed very far on their own and have to be handheld much of the way. This is a person I would expect to object to native development and push for using a framework like React Native, just so they don't have to go out and learn another language, expecting it to be too difficult (because of their inexperience with anything other than javascript and React).
* The others joined too recently to be sure yet, but I have an inkling one of them is going to be more like the first, just much slower at it.
I have the unnerving feeling that at least some of these web development bootcamps are presenting themselves as "learn this and you're good to for the rest of your life", with too many jumping in because it pays well right now, and not realizing they will have to keep on learning.
So this is a one-off anecdote, but my experience with my teammates at work is that it's not so much an objection to native development, but an objection to having to learn more. Over half took a bootcamp-style class for web development after having never done any programming before, and managed to get hired. Their current status:
* One has kept on learning, and I see no issues with them doing native development if they ever encountered it; they have the right mindset to teach themselves.
* One has been on the team nearly as long as the first, but seems to be stuck in a rut. They've not progressed very far on their own and have to be handheld much of the way. This is a person I would expect to object to native development and push for using a framework like React Native, just so they don't have to go out and learn another language, expecting it to be too difficult (because of their inexperience with anything other than javascript and React).
* The others joined too recently to be sure yet, but I have an inkling one of them is going to be more like the first, just much slower at it.
I have the unnerving feeling that at least some of these web development bootcamps are presenting themselves as "learn this and you're good to for the rest of your life", with too many jumping in because it pays well right now, and not realizing they will have to keep on learning.
I think you might be right, based on my experience anyway. Especially regarding the last paragraph.
Nothing against bootcampers per se, but I remember my university lecturers telling us this isn’t accounting, you’ll be learning for life. They didn’t tell us to get out of the class if we’re not up for it, they just set the expectation.
Even despite this, 5 years later I got a harsh reminder after other life factors getting in the way, and for about 2 years I stopped doing any extra curricular learning at all. It took me 1-2 years after that to pick up the pieces. Never again until I retire. You just can’t afford to not “want” to continually learn in this industry.
Nothing against bootcampers per se, but I remember my university lecturers telling us this isn’t accounting, you’ll be learning for life. They didn’t tell us to get out of the class if we’re not up for it, they just set the expectation.
Even despite this, 5 years later I got a harsh reminder after other life factors getting in the way, and for about 2 years I stopped doing any extra curricular learning at all. It took me 1-2 years after that to pick up the pieces. Never again until I retire. You just can’t afford to not “want” to continually learn in this industry.
As someone that has done native and react native development this is far from true. Laying out views in react native using flex is 1000 times easier than anything iOS/Android has.
Also you get to reload your code almost instantly to test changes in react native
Creating a UITableView compared to FlatList in code is way easier.
And don't get me started with the Android Activity/Fragments lifecycle methods mess.
Android Studio and Xcode sucks both in different ways.
Even if it was the same effort to do these things in native it's stupid that in 2018 we have to implement basically the same things using 2 very different languages and tools. It's just sad to see the actual state of native development right now.
Sure performance is still a lot off than native but is enough most of the time. The complains I have about React native is that with version 0.56 they did lots of breaking changes that meant I am stuck for now with 0.55, the performance has much room for improvement and the quality of many modules are subpar. But I am hopeful that with the fabric rewrite things change.
Even if it was the same effort to do these things in native it's stupid that in 2018 we have to implement basically the same things using 2 very different languages and tools. It's just sad to see the actual state of native development right now.
Sure performance is still a lot off than native but is enough most of the time. The complains I have about React native is that with version 0.56 they did lots of breaking changes that meant I am stuck for now with 0.55, the performance has much room for improvement and the quality of many modules are subpar. But I am hopeful that with the fabric rewrite things change.
I don't think it's "no! I want JavaScript everywhere!", it's that we're being told that we need to develop and maintain an identical, or near identical, app that runs on iOS, Android, and a host of browsers across a smattering of devices. If something could actually deliver on the promise of "write once, run anywhere" then it would reduce the redundant elements of my work many times over.
it's worth reading up on what react-native is. it isn't "write once deploy anywhere," but rather "learn once, write anywhere." in essence it allows us to enjoy the fairly transformative one way state driven view paradigm (think functional) to write apps. that is the magical part of it - the one language multiple platforms aspect is a tertiary consideration in my opinion. the pleasure comes from an environment where code changes are almost immediately visable without a lengthy compile/run step, and the pure joy of having views that depend purely on state input without the mess of side effects.
someday everyone will realize that one-way data binding is beautiful and that functional paradigms can save hours/days/weeks of testing and messiness. react-native is just bringing that beauty to the dev process now. i've done obj-c/swift xcode, and maybe i'm not good at it, but it ends up not being easy to read, and not fun waiting every time i want to test something for it to compile and run.
under the hood react-native does something very clever, it isn't a hack or ugly, but rather quite lovely. you get the pleasure of seeing your components and data flow as a tree, a tree that only updates nodes as necessary when state changes, and where each component is a fully fledged native component with all the functionality and speed of the native component. want a UIScrollView? sure `<ScrollView></ScrollView>`. data is passed through easily and it is all very easy to reason about. that is the goal right? code that is easy to read and makes sense.
someday everyone will realize that one-way data binding is beautiful and that functional paradigms can save hours/days/weeks of testing and messiness. react-native is just bringing that beauty to the dev process now. i've done obj-c/swift xcode, and maybe i'm not good at it, but it ends up not being easy to read, and not fun waiting every time i want to test something for it to compile and run.
under the hood react-native does something very clever, it isn't a hack or ugly, but rather quite lovely. you get the pleasure of seeing your components and data flow as a tree, a tree that only updates nodes as necessary when state changes, and where each component is a fully fledged native component with all the functionality and speed of the native component. want a UIScrollView? sure `<ScrollView></ScrollView>`. data is passed through easily and it is all very easy to reason about. that is the goal right? code that is easy to read and makes sense.
What you describe though are good software practises in general, not exclusive to react. I don’t blame you for thinking this though, because I hear this a lot, it’s not just you.
I’ve been building in react for a year after working in iOS and Android. Something like a tree structure capturing all of the view components is available right out of Xcode. Another example: time saved compiling is mitigated by time spent debugging, trying to find the source of exceptions etc is a mystery box and a huge time suck.
What I think is happening is that most Javascript and react developers have spent time only in one domain. So they make a lot of assumptions that all of these advantages of react are exclusive to the paradigm and platform, when that’s not true at all.
I’ve been building in react for a year after working in iOS and Android. Something like a tree structure capturing all of the view components is available right out of Xcode. Another example: time saved compiling is mitigated by time spent debugging, trying to find the source of exceptions etc is a mystery box and a huge time suck.
What I think is happening is that most Javascript and react developers have spent time only in one domain. So they make a lot of assumptions that all of these advantages of react are exclusive to the paradigm and platform, when that’s not true at all.
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.
If it were just 3 platforms (android iOS and browser) then it would be less of an issue - when you have to support 12+ platforms such as TVs, keep an always evolving design language up to date on all those platforms, making a change requires 12x the work.
Most apps are API based and react native works perfectly fine for them - I've done all 3 and in general, RN performance is sufficient. Previous cross platform frameworks were pretty disappointing but I truly believe rn is well engineered.
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
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
Great insight. How can we use something similar to Interface Builder to create React Native apps?
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.
* 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.
This is a good and fair summary. It is a frustrating developer experience for sure - especially Android.
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
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.
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.
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.
Similarly, Flutter felt much more like a cohesive solution compared to RN.
* 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
* 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
* 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
* 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
Thanks! Fixed it.
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.
Thanks for "foot guns". Have never heard it but like it!
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/intr...
[2] https://facebook.github.io/react-native/blog/2018/05/07/usin...
[1] https://facebook.github.io/react-native/blog/2017/03/13/intr...
[2] https://facebook.github.io/react-native/blog/2018/05/07/usin...
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.
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.
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.
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.
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.
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...
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.
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.
I think it’s a good idea to list versions at the top of the articles.
Every technology has to deal with this problem.
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.
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.
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.
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.
[deleted]
app bloat, the app size is too big for a simple example
[deleted]
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.
React Native multiplies the complexity of a project so much that IMHO it completely negates its own usefulness.
SalimoS(1)
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.