What do you dislike about React Native?
github.com
github.com
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.
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.
- 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.
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.
An Instagram launching today would see much greater pressure to be on Android sooner rather than later.
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.
Perhaps windows is better? What about linux? :p But I see why people are disliking the native ui situation on desktop.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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
* 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.
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.
Similarly, Flutter felt much more like a cohesive solution compared to RN.
* 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
[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'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.
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.
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'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.
React Native multiplies the complexity of a project so much that IMHO it completely negates its own usefulness.