Seems like both AirBnB and Udacity made the mistake of not investing enough in the tech. If you keep building out full native features while transitioning a brownfield app to RN, you’re going to have this fragmentation problem.
I’ve converted, (with lots of help of course), a massive brownfield platform product to RN. It took a lot of work, building the right bridging layers, retraining the team, figuring out best practice, etc. We still have a lot of tech debt, but it works!
Pros: Solid cross platform development, easy to teach, easy to get up and running on Xcode/Android Studio (running and working on both in first week on the job), easy to teach the native languages from there, real time bug fixes, fast iteration times on new features. Cons: No 64b on Android, Android peformance lags behind iOS, RN bugs, build process was tough to nail down, no built in navigation support.
We’ve now solved most of the huge RN exclusive problems we had with RN we had when we started out, so at this point I’m not going to be abandoning it anytime soon. There are still problems, but just your average engineering problems, same as you’d get in native development land or any other platform. It’s been about 3 years now, with a 10+ person team now, so maybe I should write it all up somewhere.
Did it not before? Of those pros you mentioned, are they worth the many year investment you made and are continuing to make in the tech? Hypothetically, if the tech were to fall out of favor soon, does that change the worthiness?
I'm under the impression, in Udacity's case especially, that part of the problem stems from asking native engineers to use a language and ecosystem that they're not used to working with, and then trying to get them to integrate RN code into an established, brownfield native codebase.
As a sole dev in a 3-person startup, I’ve managed to build a pretty large app with React Native, having zero prior native experience (although, that’s not to say that I haven’t had to learn a _lot_ about Xcode!)
I had a pretty similar experience. It's still a challenging environment - getting performance and memory management nailed across platforms and devices took some very careful engineering.
Based on my limited experience with native iOS app development, RN actually requires an almost completely different way of working.
That sounds like unnecessary complexity, skills and cost. Until it’s simpler to build, higher quality and a more predictable result than native, i will continue to use native frameworks.
That was my impression as well. What he wrote about localisation as well - they are trying to localise text in RN files, native iOS files and Android files, maybe using a different approach for each platform, so of course it's complicated.
I managed to localise a relatively large cross-platform app built in Electron and React Native using gettext and had no problem with it. It supports 18 languages and people send me update from time to time, which are very easy to integrate.
It seemed a large part of their frustration was integrating the native with react native. I think too if you decide to use react native you don't hire more iOS and Android specific devs, you hire react native devs and replace the entire native codebase.
> stems from asking native engineers to use a language and ecosystem that they're not used to working with
yes, so reminiscent of “enterprise” situations where SAP (or put any of your other favorite's name here) is so dominant. In a recent situation, the marketing side of the business kept asking for newer agile mobile technologies, and so the cio-purchasing-manager engages Gartner (or put any of your other favorite consultant’s name here) for guidance. Well, the result is to start an in-house prototyping team composed of who -- folks seeped in SAP maintenance but who wants to learn the newer mobile technologies for career development. They do create some prototypes but so many things remain open while they are busy doing their daily SAP work, their forte. The CIO then steps in to satisfy the marketing folks: We buy SAP’s packaged solution for mobility and an outside consultant will integrate it. Problem solved. Or is it? The answer waits another three years when the integration is really completed, by then the CIO leaves and the issues need to be visited again.
Can I reach out to you? My team will shortly be starting out with RN to build our mobile app. I'd love to get some pointers and advice on what we can do to make it as successful an experience as possible.
Show us the app and ideally some code to let us judge how well you managed then. I believe the standards for native development are well known at this point.
Checked this app out of curiosity. It’s decent but doesn’t feel native to me. Each platform has its own nuanced differences that we might think is okay to ignore but customers see through when the experience isn’t consistent with past expectations.
The transition animations in some situations were what felt out of place to me in particular.
1. When the app starts, the onboarding screen appears with a flicker/glitch: https://imgur.com/IyjM82n
2. The app starts with a launch image (the logo in the center), which then fades away to show another launch image (with the logo on the top half of the screen): https://imgur.com/0n3Zbof (probably because ReactNative must load the JS bundle before it can show anything)
3. The login screen of the application fits on the screen, yet it can be scrolled up/down for seemingly no reason. The amount you can scroll feels suspiciously close to the height of the iOS status bar: https://imgur.com/P6conGz (probably because ReactNative sets the UIScrollView's contentInset incorrectly)
4. Text fields / buttons look like on a website.
5. When you navigate back from the login screen after a failed login, there's a brief moment while the "Unsuccessful login with Facebook" message is visible, which then quickly disappears: https://imgur.com/hTTKbIt
Sorry, but it feels like a webapp to me. Though it might be perfect for your use case!
Update:
I've found some other issues:
6. You can't interact with buttons (e.g. "Next" button on registration) while the keyboard is visible: https://imgur.com/dpy5xv8
7. The first time you switch to a tab, it's completely empty, then suddenly the content pops into place: https://imgur.com/JKaCJED
8. Tapping on the search button makes the content of the previous page jolt against the top of the screen while navigating to the search page: https://imgur.com/BJDYvda (focus on the panda)
9. The "sidebar" menu feels very out of place on iOS. Also, when you select e.g. "Settings", the content on the right does a very weird fade/slide animation: https://imgur.com/ChNzvwW
10. When you switch between two non-adjacent tabs, the viewport slides over the in-between tabs too: https://imgur.com/BZFU0Sv
1. I reviewed the app. I didn't attribute any of the issues to React Native itself, did I?
2. The Airbnb and UberEats apps were written by expert native developers (I happen to know a few of them), using some React Native.
You see, expert native engineers can deliver quality apps using native frameworks. And surely, if they look into React Native, most of the time they can manipulate it from the JS side to get the desired outcome on the native side. The middleware is a hinderance for them as it gets in their way of implementing what they want in the first place.
It's like building those ship models in a bottle: if you know how to build the ship, you just have to learn how to do it through the neck of the bottle. If you don't know how to build it in the first place, well... that's a different story.
You have it wrong, only the restaurant dashboard app is built using ReactNative, that was done because they had a website earlier and they wanted to convert that quickly to a tablet app and their developers who were working on that web app had very limited knowledge of iOS/Android, refer to https://eng.uber.com/ubereats-react-native/
I definitely agree with the fact that it feels like a web app, but this is the design the customer asked for. Most of this things are actually not a React Native problem but the way the app was made. Onto your points:
1. This can easily be fixed with a module, however time pressure didn't allow for additional "tweaks"
2. Same as 1.
3. Using Scrollview for this, since some android devices with smaller screens can make the Login screen look very ugly and small, so in that case scroll looked better.
4. Do they look like or feel like ones on a website? It is by design, but interested to see how you feel about the fields as a user (although we don't support the app anymore)
If only we could learn from past experiences, many companies have done that in the past because some CXO thought that they could save some money using hybrid frameworks, didn't go well for them and they ended up writing native apps. It's like you are asking people to fire "Master of one" and hire "Masters of none".
So I'll state my bias up front. I'm a pretty happy non-native react-native developer.
After reading this write up and AirBnB's write up about RN I keep wondering if the source of the problem is more with integration points between native features.
Like I said, I'm not a traditional native mobile engineer, but as a single dev I've been able to build a rather large and complicated app almost entirely in react-native. That's not to say that I don't use mobile features, I'm using a dozen or so libraries for native features, but the common problem that seems to arise is "this doesn't integrate well with the rest of our native app". IMHO if you're writing business logic in swift/java instead of javascript you're going to have a bad time. If, however, you use/implement narrowly scoped native libraries that are glued together with javascript it's a pretty nice experience.
I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.
I think there are a few other major problems, but I think many apps are unlikely to hit them in the same way that they are unlikely to have integration issues with native code, because they don't need much native code.
Most apps only need to be a bunch of table views and detail views, with some forms. Line of business apps that need to be efficient (not pretty) or that don't use many of the advanced platform features, short lived apps for events/marketing/competitions/etc, apps for restaurants or shops, these are all places where I think React Native fits perfectly.
However, if you want your app to have the best performance (spoiler alert, you probably don't), you want to be at the cutting edge of platform support, or you want to create experiences that fit on the target platform perfectly, then I think native is the way to go. Most apps do not need this.
> However, if you want your app to have the best performance (spoiler alert, you probably don't)
Actually you do. An app like Facebook, Instagram, etc are used for hours a day; having a suboptimal performance directly translates to battery drain and a poor user experience, which costs you money.
I'm sure someone smarter than me has a nice soundbite about using the best tool for the job. React Native is a compromise. Web technology on mobile is a compromise.
I did say “probably”. Facebook and Instagram definitely care about the last bit of performance. Your typical line of business apps don’t need to, and that’s a lot of the market.
You have no idea what kind of low powered devices are out there in third world countries, with fragile/low bandwidth internet connections that need to connect to Facebook. The main apps are not the problem.
But they DON'T USE React Native in the main feeds of either Instagram or Facebook. You know, where users spend all their time and performance matters.
You linked to a post about a bunch of settings/picker screens in Insta. On the FB side, my understanding is that only the Marketplace tab is RN, and maybe the settings & notifications.
Spoiler alert, more than you think you do. I was involved in refactoring a product detail page for an e-commerce app. It was a several month long project as the view is pretty complicated and the only goal was to improve UI performance. Our efforts led to a direct, measurable result in user engagement and an increase in items being added to the cart.
General user engagement is a measurable benefit, regardless if it's for e-commerce purposes or not. Other apps that provide a blazing fast experience set the standard for what users expect out of an app. If your app performs below that threshold, users are less likely to use it. Loading performance is the biggest reason I reach for my Harmony physical remote rather than ever using the app.
>I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.
I suspect that your experience as a single developer has VERY little in common with what the 100 people Airbnb team is doing.
I am not trying to say that you or your work are in any way lesser than the one of a big team but it is a very different problem.
I have worked in such an environment and even with native, we had to code a ton of custom Views in order to get exactly the specific behavior we had in mind.
There are tons of little tweaks that demand to exploit the platform to 100% that you can in a very large team and that you would just avoid a single dev because you don't have the time for this kind of stuff at big scale.
He's not wrong though. Other big teams have had success with React Native including Skype and Office teams, as well as Instagram.
When I read this article by Udemy, where they started with 1 dev for each platform and had a mere 3 or 4 react Native features and then ended up with 7 or 8 mobile devs split along platform lines, I wondered if 2 or 3 react native devs couldn't achieve the same thing if they actually tried to share 90% of the code across iOS and Android and went all in? The productivity boost is there if you embrace it.
It might be the right choice for some products but my experience on complex products more closely reflects the Airbnb one than the myth of 'only know js, write once, run everywhere'
> I wonder if the issues that they encounter are more a symptom of trying to "bolt on" react-native.
Exactly. React native shines exactly in your situation, not when you already have a few developers who can write native code for each platform, and especially not when you already have an established app for each platform.
> Exactly. React native shines exactly in your situation
It also works well when you have thousands of developers with established apps (Facebook). This React Native bashing storm is more a cultural thing as the other solutions (native, swift/objc, java/kotlin) are not technically superior, with obvious up and downs compared to RN.
B2B (Xamarin) team where I work. One huge step to help B2B adoption would be to include an official library to include some functionality instead of having to choose between many different fragmented options.
A perfect example is qr/barcode scanning - there are numerous commercially supported "enterprise" scanning engines which are substantially more performant than builtin solutions or existing open source solutions. If you can meet a few of these requirements with main library support it would become incredibly hard not to use react native in B2B solutions.
Like with React itself, as long as you play within the React-Native box the experience is great. For basic apps you don't need anything extra. Once you start having to go into the larger ecosystem for features not provided by RN, the weaknesses start to show up.
Airbnb complains had some real issues. Udacity “problems” looks artificial. Animation Performance on old androids - and then agreed it’s non RN issue.
Android SDK 26 playstore limits only NEW apps at first and react 0.56-RC support it, so plenty of time (4 month to adopt). Notch support was available before first devices hit the market.
I believe here is different beast - programming language as a religion. One of my devs was really sabotaging processes just because he hate JS.
> The load time when entering into the React Native portion of the app was longer than we would have liked. It often did not feel like a seamless transition.
That is a "real issue." Frame it however you want, React Native is a compromise. Performance is a huge deal to users. It's not hard to tell when you're running one of these "one size fits all" apps.
But to be even fairer, JS has evolved into quite a nice language to work with over the last few years and I'd hope that developers who've used it in the past would take the time to re-evaluate it.
Over the last few years, JavaScript has been ruined as a language for beginners, proponents of functional programming, and anyone who likes elegance.
But as a language for professionals who are willing to spend 40 hours a week on it and devote week after week to learning the internals of massive, rickety declarative APIs like Babel and Webpack, yes JavaScript has improved a lot for that audience.
You have to be a dedicated professional though, ideally a former Rubyist. If you’re not, stay away. Learn Python.
If you’re 20 and have learned just the basics of coding, but have not made any deep forays into software engineering, and can focus on a brand new codebase, and only support bleeding edge browsers, modern JavaScript is also ok too.
Personally I think it’s the wrong direction. I went back to ES5 and am developing a non-insane toolset for that language.
> What would you recommend to someone averse to js
I guess it depends on what your concerns are:
• If you're worried about too many libraries to pick from, I'd just go with the most popular ones. React is a pretty solid choice.
• If you're worried about config being a pain, I'd recommend going with one of the starter tools like Create React App. Build tools are indeed a bit complex, but hopefully that's getting better over time.
• If you're scared by lack of type safety or worried about language quirks, I'd recommend TypeScript. (Flow is also quite good.)
In particular, TypeScript (and Flow) provides much more flexible static typing than I've used in any other mainstream language. You get the nice navigation, autocomplete, and static checking that you'd expect from a typed language, and I've found that I spend much less time needing to think about how to write my code in a way that appeases the type system.
well, quite frankly I'm not really trying to change anyone's mind, ultimately people are going to come to their own conclusions about which languages they prefer or like to work with.
I don't know how anybody could see what's going on with React and not be interested, it (at least for me) took what was once a very painful process of manipulating the DOM and working with the front-end and made it into an enjoyable and streamlined process. React actually brings order to what once a very messy and insane process.
I've used Node in production, it works very well for rapid prototyping. I could get a Node app up communicating with a diverse set of public APIs in minutes. It's not like Java or C# where I'm having to fumble around with a hefty IDE, a bunch of very strict typing, an entire compilation process and massively bloated web libraries. Node is a very lightweight alternative to that.
I think it's kind of a shame that the JS ecosystem has such a steep learning curve, which I think is where a lot of the hate stems from but once you learn it can be quite a powerful stack.
What would you recommend to someone averse to js to try and change their mind?
I'd recommend taking a look at Vue (https://vuejs.org/v2/guide/). You can write nontrivial and well-structured apps with just a text editor and not deal with npm/node unless you choose to. I also find it to be both simpler and more flexible than React.
JS is a mess, but it's a fair compiler target. React Native is good because it lets you use nice languages like ClojureScript or Elm to write mobile apps.
I hope they fired the people who thought using JS in 2017/2018 unless absolutely necessary is a good idea.
Both Kotlin and Swift are extremely elegant and modern languages with awesome set of features while JS lacks fundamental things like type(s)afety and is filled with inconsistency errors/problems etc.
And yeah yeah, JS is not complete garbage. I'm well aware of that, but there is no point bringing a broken knife into a gun fight.
If you disagree with someone over a technical decision, that's one thing. Assuming you're a professional software developer, I'd like to think at least once in your career you've managed to find common ground with someone who disagreed with you, and have realized that disagreements over e.g. programming language preference usually (even if not always :P) just mean that person's priorities differ from yours, rather than that they're incompetent.
If you consciously produce poor work because you disagree with that technical decision, rather than either going along with it or finding more a more appropriate venue to express that disagreement, that belies an attitude that's seemingly at odds with being a member of a collaborative workplace.
Well, I guess going by your logic Microsoft should fire everyone busily writing Office365, Skype, Microsoft Teams, and Visual Studio Code in javascript.
Also, type safety isn't a "fundamental thing" it's a design decision made by the creators of the language.
Those things (or at least the one of them whose source we actually have access to) are written in TypeScript. Why do you think Microsoft created the language?
Also they aren't exactly being rewritten in JS - the person who tweeted that later casually clarified that "well, actually" they're using JS as a sort of build system/integration over a still huge amount of native code.
What's your point? Typescript is a superset of javascript, they're still using javascript.
And yeah I saw the tweet and the response, it sounds to me more like they're building specific components of applications with javascript, not really build systems.
It's almost like some of the best developers in the world like to use the right tool for the right job, and in many cases that tool appears to be javascript.
It's rather hypocritical to argue that the lack of type safety is a feature not a bug and then turn around and claim TypeScript as a superset of JavaScript.
It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good type system for any project intended to be maintainable in the long term is just bad engineering.
Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node.
Nevermind that it's easy to add types to JS these days if you really want them.
How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
Yes, it's clearly true that architecture plays a major role. I've worked on one of those inheritance towers before. But adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. The only notice I have in such systems that I have missed something is a production runtime exception. Sure it takes longer up front to add a feature. And it's typically harder than in a dynamic language. My point is that taking the convenience of an untyped language is usually a poor/lazy architectural decision.
> adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something.
Looking from the other side, this seems like "static typing gives me illusion of safety, and I miss it in dynamic languages". Sure, it might be justified for large projects in the long run, but
> taking the convenience of an untyped language is usually a poor/lazy architectural decision.
sounds like not understanding (or unwilligness to use?) trade-offs involved, due to personal preference.
I don't like these (unintentional?) claims of superiority based purely on personal preference. Static typing is just a tool, with its pros&cons.
Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
It’s incredible the lengths intelligent, experienced developers will go to, to avoid learning iOS or Android development. It’s a small bump to overcome to unshackle your project from an ever changing comfort blanket between yourselves and the platforms, that inevitably lags behind and is ultimately a comfort blanket that’s future is always in the hands of a third party. If your developing iOS and android apps in JS, then you’re smart enough to get stuck into Xcode/Swift and Android/Java, and you’ll probably never look back. Sounds like most RN devs find themselves in the trenches often enought as it is.
Software development is already crazy expensive. Do you know how much it costs to build and maintain web, iOS, and Android apps? It's ridiculous. It's not a matter of not wanting to learn each platform. As Udemy pointed out, they ended up with 4 devs on each platform. They also have who knows how many devs on web and platform / backend services. Udemy is a successful product with market fit I'm sure they're doing fine either way, but for many startups this kind of efficiency can mean life or death. Not many can afford to burn through $100-$200K per dev just to reinvent the wheel wiring a bunch of REST calls up.
That's precisely the point. Airbnb decided they were now maintaining web, iOS, Android, AND THEN React Native instead of only web and React Native. Their costs went up, not down.
I've found far too often over the years that companies decide to use a hybrid framework to save time and money and take just as long to write the app with equally as much cost. Then no one wants to maintain the finished product. It requires too many unlikely skill sets and trickier debugging.
React Native isn't automatically cheaper because it's a hybrid. Hybrids work great for trivial apps that look a lot like the examples. A hybrid framework also has to address every new niche the native solution fills or else integrations themselves add up to a massive cost.
Yes I agree. Hybrid platforms always foster great productivity at the start. In the early days it’s like “wow, we just produced two apps in no time at all with one codebase”. But eventually the curve plateaus, and its more like “for F* sake, I just want to access the camera api one the phone!” I feel that you eventually spend more time in the later stages footering with the corner cases, than you saved in the early stages by getting it up and running quickly. Also, when React is dead, you’ll find it much easier and cheaper to find native developers, and more living documentation/support for native apis.
Half an hour wiring up some well understood rest calls vs tearing your hair out close to a deadline when React won’t call a new feature? Always keep it simple I say.
The trouble here isn't with learning a platform, but with having to develop and maintain two.
Web tools often allow hot reloads so a smaller feedback loop.
Maintaining two code bases is not a big deal. Check them both out side by side. There they are right in front of you. Is sold as a bigger problem than it really is.
The issue is multiple codebase which can diverge as well. But yes using swift/kotlin would be the way to go. RN developer here learning native code now.
While React Native is constantly being improved, to use it in its current form, one has to be very aware of its under-developed parts, and more importantly, make them aware of by designers and PMs.
Surely for any "fancy" feature one may think of doing with RN, there are always some libraries, plugins, tutorials, solutions that exist in the vast ecosystem trying to help. But more often than not they eventually lead into a maintenance/integration nightmare, simply because how fast the whole mobile industry moves and leaves things behind.
Therefore, I suppose that a wise approach is what I would call "React Native-first design": let the whole team (PMs, designers, devs) know that anything that is not officially supported by React Native and without caveats is off the limit -- just try to avoid the design until it is fully supported.
Usually technology is used to solve business needs, but in this case the business has to adapt to the limits of a particular technology, even while other technologies offer the full range of features any business might need.
Adapting a business to technological limitations has always been the case. Entire industries are shaped by technology. That you are unaware of it is probably because you are a fish unaware of water.
All engineering may require tradeoffs, but when you're so prioritizing developer experience over the actual business that you're dropping perfectly viable features just so you can cling to the illusion of increased productivity, perhaps it's time to take a step back and reevaluate things.
What use is "productivity" without a performing product?
Is it a high-value feature to the end users? Then absolutely, you're correct.
Anyway, in my experience, most good PM and designers want an understanding as towards the amount of effort their features and designs mean for engineers. So if you aren't providing them that feedback, and letting them to factor that into their process, you're doing them a disservice.
Sure, I’m not advocating for developer experience above all else, just pointing out that the fast/cheap/good “pick any two” balancing problem can be solved in multiple ways. I totally agree that we build products for our users not ourselves.
This is far from novel. PMs, devs and architects allow the tech stack to influence product all the time, often on the basis of back of napkin cost-benefit analysis.
In fact, an org that doesn’t define tech constraints is setting itself for overengineering while a disciplined org can use those constraints to drive more, not less, business value.
If you tell me we can't hit business objectives because the team wants to use react native instead of swift without a really good reason, it's not going to work.
An example of where this is already common is when deciding to ship a web app vs a desktop app. Web apps will always be more limited, and sometimes those limitations get in the way of business needs, yet you still see web apps as the most common UIs these days. It's a tradeoff that the business should be consciously making.
Saving money might also be a business need. For this to work, obviously the whole business has to buy in to the benefits of RN, and they should be aware of the trade-offs up front.
But does RN actually save money? Or does e.g. having to keep up with the rapid development, maintaining your own native bridges and components, etc etc etc only cost more time and money in the long run?
I've read a bunch of react native postmortems and I'm usually reading "yes we're faster, but we're spending a lot of time on maintenance". It gives me the feeling it's probably faster short-term, but not viable long-term.
Besides, I'm sure there'll be a next big thing (Flutter?) soon enough, causing investment in RN to drop and it never getting up to par with the native platforms. (see also: PhoneGap / Cordova, Xamarin, etc).
I think Xamarin really stays up-to-date with the newest features for iOS. At least that was true back when I wrote some apps with it, a few years ago.
I believe they have some automated tooling to update the APIs when Apple releases newer versions of the iOS SDK, so usually new features arrive on the same day in Xamarin iOS SDK as they do in Apple's iOS SDK.
I am not sure if the situation is the same for Xamarin and Android.
I wouldn't really hesitate to use Xamarin again in the future if a client requested it, but I haven't tried React Native yet and not sure if I should dedicate time for it or if it'll be gone in a few years. Seems quite a few mobile jobs require React Native experience these days.
I’m not convinced everyone has these issues. I would agree if you have a native codebase then adding RN will only cost you. Not everyone has or needs a significant native code base.
+1 but there has to be a balance. Some features that non developers think is quite easy could take very high effort and vice versa. But I agree having to not have a feature that your competitor seems to have but you can't because you used 'X' would snowball into a big roadblock when multiple such cases crop up and the sexiness of the framework fades..
They didn't have a single JS/Web developer at the start.
> There was also an issue that caused a crash because one version of npm had a `package.lock` and the other didn’t which caused us to install incorrect versions of a dependency across a React Native upgrade.
This issue I would attribute to their lack of experience or knowledge of how NPM works, not to ReactNative.
> Lastly, CI for the iOS project was a pain point as well. We now had to add an npm dependency layer and make sure those were being updated properly before continuing the install. This added nontrivial amounts of time to our build step.
The same way if I would add Java to my JavaScript project, my build time would increase.
There are a lot of legitimate complaints in the article, but a lot of their issues stem from their lack of web experience.
Yeah, the team makeup is the interesting aspect for me. It seems they took an existing mobile engineering team and had them integrate react native.
Our experience was opposite in that we had a web/js team and decided to go to react native as a way to deal with a mobile app that we couldn't maintain well (and couldn't justify the hiring of dedicated devs for).
React native gave us an avenue to utilise existing skills and overall we found it pretty positive.
Look, cross platform is already a lost cause as OS manufacturers will always departs from competitor design flavors, so that it will be costlier to adapt to other platforms, so each OS manufacturers can have loyal developers who won't write code that work on competitor's platforms. This has been happening for ever.
Secondly, how many time is it necessary to whine that javascript is a bad technology, and that anything that stems from it is destined to less than optimal ends?
JS is great but only for deployment, and it has been its best strength, but JS cannot thrive on mobile, because mobile platform don't offer programming flexibility. Less memory, tighter chips, less battery. Converting from one language to another, and adapting design so it can fit is hacky.
Why does everybody is always jumping in on brand new shining ships?
A very good and nuanced write-up. React Native seems to get a bit of heat at the moment, or perhaps I am just paying more attention to the content, as I have just started building a project with it.
But nevertheless I am still sticking to it with what I have read so far. Building from scratch with no iOS or Android experience, but some "normal" React experience(and a lot of .Net experience) it seems like a no-brainer in my situation.
The issues I have gathered from numerous articles seems to relate more to existing teams with experience in iOS or Android. Or projects that have had high growth.
Starting out from scratch those issues are not of concern. I will deal with them if/when I get there. My main reason for using React Native is to build something fast that can target both iOS and Android at the same time. And they rightly also point to that as a good reason for selecting React Native in the end of the article.
Some of the criticism is valid, such as the performance issues and the fact that overall they didn't feel that it was worth it, the issues with the speed of the ecosystem.
Some of it isn't valid. Build times increasing when you add RN to an existing project is to be expected. If you want very different UX on each platform then you'll generally have to implement it (as you would anyway). Internationalization is always a task, he's unclear why React is being criticized for this.
Overall my takeaway is that if you're looking for an app customized to the UX of each platform, and that's more important to you than having devs who can cover both platforms, then RN is not the way to go. They seem to feel that the work involved in producing the RN features was greater than the work involved to just do things natively twice.
If they're only using React Native for 3 or 4 features (as they say in the article) I could see how adding in i18n support would be challenging as you'd now have to maintain Java/Kotlin, ObjC/Swift, JS versions of this. But thats just true of the whole approach in general. I think if you're using RN for only 20% or less of your product, it probably is more trouble than it's worth.
2500 commits seems shockingly low for all of Facebook. Doesn't that seem like there's some hardcore users and a lot of tepid users just kicking the tires? My "pizza" team at Amazon did almost that many commits in a year on mobile projects and we always rebased changes.
These retros are surprising. I tried RN for one day and realized the massive limitations and eventual need for native libraries and tools. It seems so obvious.
Support for iPhone X is trivial unless you’d made bad choices before.
Anecdote, but as having extensive experience in both areas (20 years web, 9 years iOS): natives has way way less annoyances.
I check out "modern" web development from time to time.
What's the state of the art in 2018? Can you have a DIV with a fixed aspect ratio fitted to the screen? Last time I've checked (in 2017) this was impossible without JS.
> Can you have a DIV with a fixed aspect ratio fitted to the screen?
It's admittedly far from obvious, but that should be doable by determining the height of the DIV with the padding-top of a child element, and limiting the width with max-width limited to at max height * aspectratio, so it doesn't overflow the bottom if the page gets to wide. Not really anything fancy and new in there either.
Ok, this works only for fullscreen because of vh. Let's say I want this to work within another DIV too, so you can't use vh. (and the parent DIV's size is flexible, so you can't hardcode it into calc(...)).
We'll you seem to think they work on Chrome Safari. I develop on Firefox and test on others. From other comments you seem to be a desktop developer now reluctantly working on web. Targeting just windows OS would be simpler and easier I agree. But we have moved into multi platform now. Needed to up the skills.
That said for native apps be it desktop or mobile using native tools would be the way to go.
Great read. There are obviously lots of different issues here, but the biggest takeaway I have seems to be: Udacity wasn't building a single app that ran on multiple platforms. They were building 2 separate apps that each ran on a single platform, and there happened to be a lot of overlap which made React Native look appealing.
It turned out that the overlap wasn't enough, or else the team would not have done things like ever allow a feature into the tree that didn't work on both platforms before merging (i.e. let the trees get out of sync). Useful to consider before you adopt React Native in another app.
I hope it produces a "counter attack" from RN the same way the trend about moving from React because of its license made Facebook remove that patent thing.
React Native usage at Facebook is growing. We know there are issues around integrations with existing native code, and they've been the motivation behind the ongoing large-scale changes in the internal architecture (which started in the beginning of this year).
Once that work is done it should make integrations with existing native code much easier. You can see that some of the post's content directly matches the pain points listed by Airbnb and Udacity -- because we bumped into the same problems and are working on the solutions.
I have a pretty solid counter argument lining up to be published soon (less than 2 weeks, hopefully not too late). I feel that those who had such a bad experience are just doing it wrong.
It has to do with native navigation. What apps are all about.
I wonder whether React Native was just a little too late to arrive. As someone with a majority JS background I could never quite get into Objective C (I never tried that much to be fair, just hobbyist stuff) but took to Swift immediately. There were enough rough edges around RN when I played with it that I preferred simply working with Swift directly.
The one exception to this is cross-platform stuff. I wish Swift could compile to be used on Android easily, but alas.
There's always Kotlin, which adds a lot of the niceties of Swift when writing Android code.
Kotlin also works on iOS through AppCode and Kotlin/Native, but that integration is still very young. I can't promise you won't have platform issues along the way.
I started as an iOS obj-c developer but do web development stuff mostly these days. I found it extremely frustrating to go back to Xcode and swift. It’s not about being able to write in JavaScript (or Typescript); in my opinion react native offers a significantly better developer experience around debugging, dependency management, interface building, iteration speed, testing, and sharing code. Hot reloading, npm, and “flex” layouts alone made react native more than worth it for me.
I am only writing simple apps—not even cross platform ones—so I can’t speak to the pain points from this article. But I do hope that Apple learns a thing or two from react native. Once you realize how much better iOS development could be, it’s very hard to go back to Apple’s current developer story.
For our use case RN has two major features missing:
- No file system access. We use react-native-fetch-blob (to which I actively contributed to add missing features and improve the code) which itself has quite a few disadvantages, such as a disappearing maintainer (fortunately a new one was found after a while, but the whole code has a few issues)
- The only way to transport binary data across the JS-to-native bridge is base64 encoded strings (expensive, has to be encoded and decoded on each side of the bridge) - if you need to read (raw binary) files and send them via websocket streams, as we do, you are screwed (I'm going to change the app design only because of RN so that this can be done within the native code without going through JS code)
We tried Expo and very quickly decided against it. I forgot the reasons, somebody else did it and reported the findings and we all agreed.
Besides, why would I add an entire pretty big layer on top of still beta RN (version number well below 1) only to get one tiny component? That only makes sense if one wants the entirety of Expo, and this is where our tester (if we should use it) quickly ran into numerous issues.
I understand that it's en vogue to immediately point to this or that npm package or github repo for every problem big or small, but we don't do that. We look at the sources of every package we include, and we look at possible maintenance issues. Our own stuff is trouble enough, we don't need the added problems of all those layers on top of layers of "stuff". I know it's "move quickly and sort it out later when the business has grown" - but we don't want to work like that whenever we can avoid it. Because we don't have an "exit plan", we ourselves will have to maintain the mess we create now...
I don't understand. You don't need file system access? Then of course that's not a problem, does that need to be mentioned? Or you do need it, use a 3rd party app, and have not found the many issues of having to rely on a 3rd party module, such as when RNFB's maintainer disappeared (plus numerous code issues)? Since I care about future maintenance and I know that unpaid volunteers fed up with the demands placed on them by more and more users of their free packages I am not satisfied when at the time of use the package happens to work, I always look ahead and fear the future. When you have to unravel the whole thing a year later, when you have long moved on and have other things to do but now have a big maintenance issue on your hands because of some 3rd party package that you now have to maintain your own fork of, it's no fun.
> And FB mentioned the native bridge will be overhauled.
That is a plan for the possibly far-away future. In the recent HN thread about RN plans the RN person who responded to questions ("spicyj") said "likely yes", so it's not a done deal yet even as far as plans go. Reference: https://news.ycombinator.com/item?id=17314315
We looked at Expo but quickly stopped looking at it for a variety of reasons. So it worked for you, and you don't care about the maintenance issues either (you only mention that you what you implemented worked).
RNFB and RN-fs are the main two 3rd party modules that provide filesystem access. I chose one of the two after checking the code, the API, and the user base and commits (at that time the RNFB maintainer still was very active and had plans) to see which one looked more promising for my use case. I'm pretty familiar with both those modules down to the code (out of necessity, had to provide a lot of patches, I'm still using my own fork because when the maintainer disappeared there was no chance to get anything merged).
It really does seem like that a commonality between the AirBnB apps (huge team) and the Udacity apps (much smaller team) is that both introduced React Native to preexisting apps. If they were designed and created with RN in mind from the ground up, the experience would be likely different. However I'm not sure if there's such a case study for any prominent app using RN complete- not even Facebook's apps. Instead, most of these are hybrid, between native and RN.
My issues have been related to difficult builds at times and hard to fix performance problems but my use case demands better performance with videos in a feed streaming as you scroll down when viewed. I would say react native is not bad when you keep things light and simple but go native when you have critical performance. you'll find that instagram uses rn in certain parts like that, definitely not on their feed and on their filters or AI related filters.
I can concur with the breaking changes point. That and unmaintained libraries. It seems after a certain size you need to devote 10% of your time to just trying to keep libraries up to date security wise.
And then libraries get abandoned. "Your still using LibA? Switch to LibB!"; "Critical vulnerability! Upgrade LibX now! See migration guide to go from 1.2 => 9.1" literally 30 times across our projects...
First , flutter uses an architecture similar to a game and uses it's own rendering pipeline and Layout system, meaning integrating with anything that exists is extremely challenging ( Chartings , Lottie etc... ) you'll be often waiting behind the Flutter team to implement the feature inside the engine.
On top of that the SDK supports for Darts right now are non-existent, maybe it'll change in the future , but Firebase + GCloud is pretty much all you'll get in terms of SDK as of now.
All in all is it still a terrible idea to try to build native apps with HTML?
In my experience going back to Phonegap, I have tried many evolutions of these products over the years and all of them are terrible. Like unusable. 3fps and unresponsive.
Is React Native a new generation, a new stable outlook, or is it simply making React 3fps and unresponsive?
React Native is native. There’s no HTML. You’re using JSX (probably) which is basically XML in JavaScript (it’s not as bad as it sounds) to build native UI. Can’t stress the native bit enough.
Where React Native differs from truly Native is that UI orchestration is batched into chunks on the JS side and sent asynchronously to a native receiver, which then applies those changes to the native side. This means that currently if your JS thread gets blocked, or the main thread gets blocked, your app will snag. Performance is a top priority for React Native and it mostly fulfills that goal too. It’s not hard to keep your app running at 60fps.
React native is an abstraction layer. It has all the problems of any abstraction layer has ever had on any platform that has ever existed. The lessons from this article (that is 15 years old) is still relevant today:
Not disingenuous at all - all the rendering code is _native_, no subtle hidden meanings. No webviews, no custom drawing, all existing platform components - that's as 'native' as you can get.
By that argument, all the rendering code in my browser is also native. The browser takes a markup language and CSS and renders this text using native components.
React Native takes smaller markup and a subset of CSS and renders it using native components. So how is that as native as you can get in comparison?
I agree that layer between markup and native controls is thinner in React Native but the actual abstraction is actually very comprehensive. iOS and Android applications are constructed quite differently from each other. And React Native is itself different from that. It has an entirely different API with a whole different model for how applications are made. So much so that the platform differences are almost completely papered over. So is that native?
I disagree that the idea of "native components" trumps the fact that practically everything you do in React Native is different from the underlying platform. Ultimately that seems like the least important detail. The abstraction is actually what makes React Native useful but it shouldn't be sold as "native".
RN isn't a wrapped HTML renderer like Phonegap. It uses bridge code to render native UI powered by JS business logic. You still write in JSX, which makes layout pretty straightforward. With some careful optimisation, I had pretty solid 60fps scrolling performance on 1000 item/image lists on old Android devices.
Did you use FlatList or ListView (or a custom module) for this? I've noticed that ListView sometimes does much better than FlatList, interested to hear what you used.
FlatList was absolutely the way to go here. In fact, we initially built the list in question when ListView was the only option. During development, FlatList was made available as an experimental component. It made a huge difference switching over to it. The optimisation we needed to do was to use onViewableItemsChanged to toggle the visibility of images. We found that otherwise it wasn't properly emptying the memory of Android devices, and it was easy to crash older devices. After implementing that, we got silky smooth 60fps everywhere.
Phonegap is pure crap in my mind. React Native is much much better, but still has it's issues. Also, it's not HTML based, you write JavaScript code to drive native components.
IMHO, The promise of multi-platform dev is sharing code and reusing resources (including developers) which generally comes subpar with native developing for several reasons. Having 2 separated teams of iOS and Android, they should aimed for native in each platform.
> At other times, React Native lags behind in the adoption
of new platform requirements such as Android apps being
required to target api 26 by August 2018.
Just keep moving the target, good strategy to mess them up.
so basically you hired more android and ios developers and they kicked out RN while the whole purpose of it is not ti have dedicated mobile developers. sounds like your taxi drivers would not like uber too..
Really think Flutter will eat into a lot of React Native use.
So far really loving Flutter. The hot reload speed is just incredible. Plus there is some unusual features.
One is widgets keep state so can go directly to where you were already at when developing. This makes you a lot more productive and experiment a lot more.
The other is able to be somewhere in the app your are coding and just click that page on the screen and takes you to the code behind it.
Also it does look like Flutter is the future as the native UI for Fuchsia.
I guess just looking over the flutter docs, I'd miss jsx too much. Also hopefully a more stable backend to target with less differences between platforms.
"We removed the last traces of React Native from the apps because the only remaining React Native feature was being sunset and we no longer had to support it."
I didn't expect a clickbait from a serious company like yours.
I’ve converted, (with lots of help of course), a massive brownfield platform product to RN. It took a lot of work, building the right bridging layers, retraining the team, figuring out best practice, etc. We still have a lot of tech debt, but it works!
Pros: Solid cross platform development, easy to teach, easy to get up and running on Xcode/Android Studio (running and working on both in first week on the job), easy to teach the native languages from there, real time bug fixes, fast iteration times on new features. Cons: No 64b on Android, Android peformance lags behind iOS, RN bugs, build process was tough to nail down, no built in navigation support.
We’ve now solved most of the huge RN exclusive problems we had with RN we had when we started out, so at this point I’m not going to be abandoning it anytime soon. There are still problems, but just your average engineering problems, same as you’d get in native development land or any other platform. It’s been about 3 years now, with a 10+ person team now, so maybe I should write it all up somewhere.