22 ms·

React Native at Airbnb

498 points by msoad 8y ago

msoad 8y ago
This is a really good write up and I love how they were cautious not to feed the ongoing fanboyism in for and against React Native folks. Say what you like but this is a very mature move from a young engineering organization.
- faitswulff 8y ago
  I have to agree. It was really interesting that they highlighted that nearly 2/3rds of their engineers would use React Native again. I also assumed that the last part of the blog series was going to be mostly fluff / product announcements, but their efforts in server side rendered native screens and drastic reductions in build time are legitimate takeaways from devs who are used to development cycles at React-Native speeds.
  - akmarinov 8y ago
    Server side rendered native screens just seem like fancy words for browser to me… I get that it’ll have native performance and responsiveness, but still maybe just touch up your website and call it a day?
    - faitswulff 8y ago
      Ah, my mistake, it should say "server-driven," which is more accurate. The view isn't actually rendered on the server, it just seems to be sent over in a declarative format, which the client then renders into a native view.
      - mpweiher 8y ago
        > sent over in a declarative format like HTML? > which the client then renders into a native view. A WebView?
        scottmf 8y ago
        No
        scottmf 8y ago
        Sorry if the short response seemed rude. No is the answer to both of your questions. RN isn’t just “HTML in a webview” like PhoneGap or Cordova: elements are actually rendered as native UI components. E.g., a <Text> element becomes a native UILabel on iOS and a TextView on Android.
  - philipwhiuk 8y ago
    You have to wonder how many of their 100 engineers are going to dislike having to become iOS/Android devs.
    - gpeal 8y ago
      The vast majority of the 100 always have been and are still Android and iOS devs. React Native never made up more than 10-20% of our mobile engineers and many of them came from Android or iOS backgrounds.
      - heyheyhey 8y ago
        How's FB's RN team reacted to Airbnb's decision to move away from RN?
    - matwood 8y ago
      For me, in order of enjoyable front end developer experience it would go iOS > web/js/react > Android.
- electricslpnsld 8y ago
  > Say what you like but this is a very mature move from a young engineering organization. Airbnb is ten years old at this point, I'm not sure that really counts as young!
onedev 8y ago
Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently: https://twitter.com/sandofsky/status/1002634185566236679 https://twitter.com/sandofsky/status/1002634185566236679 https://twitter.com/VivekxK/status/1002694526467653632 https://twitter.com/VivekxK/status/1002694526467653632
- faitswulff 8y ago
  Don't forget Udacity removing it from their codebase: https://twitter.com/n8ebel/status/1006244834351312897 https://twitter.com/n8ebel/status/1006244834351312897
  - ex3ndr 8y ago
    Udacity is a bit strange example. This means that they have what? triple size of react native in their main app? That's weird because on android react native blows APK to much larger percentage.
- nickspag 8y ago
  Coursera also removed it completely.
  - rimliu 8y ago
    Source?
    - faitswulff 8y ago
      https://twitter.com/mustafasf/status/1002787351188332544?s=09 https://twitter.com/mustafasf/status/1002787351188332544?s=0...
- eysquared 8y ago
  The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can. For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript. I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.
benawad 8y ago
"Redux is notorious for its boilerplate and has a relatively difficult learning curve. We provided generators for some common templates but it was still one of the most challenging pieces and source of confusion while working with React Native." Interesting to see even Airbnb struggles with Redux
- bpicolo 8y ago
  The cognitive overhead of redux ends up being pretty high due to the boilerplate in my opinion. It feels like complexity increases very linearly as project size goes. I've found that MobX translates to a much simpler mental model, though it does have a variety of quirks to deal with that Redux doesn't face (like converting objects to non-observable for test case assertions)
  - rawrmaan 8y ago
    Yeah, MobX is significantly easier to reason about, even if it may have a few idiosyncrasies that make debugging more challenging. Also, performance optimization of React components is a cinch with MobX and a nightmare with Redux.
    - acemarke 8y ago
      Can you explain what you mean by "perf optimization is a nightmare with Redux" ? Generally, Redux helps improve performance in a React app, especially as you connect more components.
      - rawrmaan 8y ago
        Let's say you have a component deep in the hierarchy that needs to update based on a small but frequent change in a large object (thousands of keys). With Redux, you have to figure out how to diff the old and new copies of that object to figure out what changed. With MobX, you just observe the value of the exact key you're interested in. That's just one example, but I generally spent a ton of time writing complex shouldComponentUpdate functions and therefore making lots of mistakes with Redux. I've found MobX much more suited to building complex UIs with deep hierarchies and tens to hundreds of total elements on the screen at once, where updating only exactly when necessary is critical. I use MobX for my game Falcross, which I wrote about in the State of React Native 2018 thread from a few days ago: https://news.ycombinator.com/item?id=17316877 https://news.ycombinator.com/item?id=17316877 I initially used Redux, and I found it actually technically impossible to get the game to perform well using Redux. I tried everything.
smt88 8y ago
None of the recent articles or HN comment threads about React Native spend much time evaluating Haxe. I guess it's not that widely used for CRUD apps and is more popular for games? Anyway, I'd love to know how it would work for an Airbnb-like org.
- SneakerXZ 8y ago
  It is same with Xamarin. They don't have people that would know these languages, and they would be passionate about them.
  - woolvalley 8y ago
    Xamarin and co suffer from the same dual layer issues that react native has when I last looked into it. C# isn't that popular from a silicon valley engineering perspective, since the first class C# implementation wasn't open source until very recently. Yes mono has always be OSS, but it has also been a second class citizen too.
    - SneakerXZ 8y ago
      Only Xamarin.Forms introduces another layer for you (it is the same concept as React Native). If you use Xamarin.iOS and Xamarin.Android you call underlying APIs directly. Although there can be issues with bindings, nothing like you will face with React Native. I am aware of why C# isn't popular among startups. It is sad because C# is a great language that has amazing tooling support. It runs everywhere - Xamarin for apps, ASP.NET for servers, Blazor for browsers, and it is getting only better, and I cannot imagine how awesome it would be if other companies helped Microsoft. But I can only dream.
      - smt88 8y ago
        I think F# and .NET Core may become popular among certain kinds of startups (FinTech, logistics, etc.). It's a good compromise between Java and something like Haskell, in my opinion.
      - deleted 8y ago
cpeterso 8y ago
I haven't used React Native, but I've ready a few posts from people adopting it. They typically test the waters by writing new app views in React Native instead of rewriting everything. But how much cognitive overhead is there in maintaining multiple toolchains (React Native and native and/or web views) and debugging views in different languages in one app?
- MBCook 8y ago
  I work on an app that is written with a combination of iOS native code, JS, and server side code. It’s not easy to debug at all. The problem they mentioned where your stack traces just end at layer transitions is a real problem. Even if the server side isn’t involved in the bit you’re working on.
- k__ 8y ago
  If you can use Expo you're probably good to go without much tooling.
pjmlp 8y ago
Yet another company discovers what many of us did ages ago with multi-platform frameworks. Additional layers not supported by platform owners, mean extra debugging efforts tracking down which layer is responsible, catching up with native SDK features, need to be an expert at both layers, lack of integration with native debugging tools... But business always wants the Ferrari solution at the cost of a Fiat panda.
- RussianCow 8y ago
  While I don't disagree with your premise, "need to be an expert at both layers" is absolutely still true if you build your app natively for each platform (more so, even). At least with a common platform, if nothing else, you can share quite a bit of code, and that alone might make it worth the extra layers.
  - chii 8y ago
    But the draw of cross platform is that you don't need to be an expert in them! Or at least, that's the advertised advantage.
    - eropple 8y ago
      For the happy path, you don't. And many apps can stick very comfortably on the happy path. I wrote a controller for a video mixer[0] that ran out-of-the-box on Android and iOS using websockets and everything Just Worked. (I still haven't released the iOS version due to lack of test equipment, but it runs just fine.) [0] - http://bit.ly/buymyapp http://bit.ly/buymyapp
  - jiaweihli 8y ago
    I understood 'both layers' to mean both the abstraction layer, and the underlying layer being abstracted. Actually, you might even understand it as 'all 3 layers' here - iOS, Android, React Native.
  - LeoNatan25 8y ago
    And “developing” in RN requires you to be an expert in three fields: iOS, Android and the RN layer, which is often buggy. How is that better?
s17n 8y ago
tl;dr: > Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.
ex3ndr 8y ago
While i don't have much experience in RN, but have a decade of mobile native development (android + iOS) and two years of React. The whole 10 years there were people that think that they can just get "web" technology and speedup mobile development. Almost always this companies had no mobile engineers that know how this stuff works. Developers that know that you just can't listen to scroll and update animations by sending messages to background js thread. This just completely wrong on mobile. Most mobile devs spend months to make it fast and easy to use. There are no way to do this in most cases on RN. AirBNB's app is a perfect example of this. Trying to deliver "better" experience they completely kill scrolling performance. Even top level iPhones feels laggy. But yay! We have animations! AirBNB's app is barely usable on two-year-old androids. This is just simply wrong, this is not how you can achieve good performance and nice animations on such small devices. In most cases this is a kind of art and a lot of testing and tweaking for every device. This can be done by only ONE talented developer per platform per year. Surely AirBNB has resources. Just take specific screen and tweak it to hell. On the other side, react and declarative kind of state is really doesn't work well for non-page oriented apps. Mapping history of navigation via redux store is just an awful and useless idea that helps with nothing. Right now there are still no navigation library. Every time i tried to start something in React Native i failed since i wasn't able to apply my skills to make it behave fast there are just no easy way to do this. React Native for sure is a good thing, but it's evolution shaped by web devs that try to reflect their experience from web development, but building a good mobile app is completely different from web one. For example, there are no dom, UI manipulation is not slow, navigation between pages and keeping it's state is not a problem most of the time (there are no real "back" button that you have to handle somehow). UI frameworks are more mature (while have less API than HTML).
- jeanregisser 8y ago
  > Right now there are still no navigation library. React Navigation and React Native Navigation are both viable options with their own pros and cons. Been using them successfully in different projects. https://reactnavigation.org https://reactnavigation.org https://wix.github.io/react-native-navigation https://wix.github.io/react-native-navigation
kbyatnal 8y ago
"While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit when toLocaleString worked on iOS and but only worked on Android while debugging. It turns out that the Android JSC doesn’t include it and it was silently failing unless you were debugging in which case it was using V8 which does." Wow, I can't imagine how frustrating this must have been to debug.
- MBCook 8y ago
  I had something like that once in native web dev. It turned out that by default when using the debugging pane the browser would disable cache so the issue (whatever it was) disappeared. Close debugging? It broke again. Maddening.
  - filleduchaos 8y ago
    > native web dev That has to be the strangest combination of terms I've seen this month.
    - skocznymroczny 8y ago
      I've seen people refer to bare metal Javascript, which sounds even weirder.
    - kroltan 8y ago
      Ever heard of PhoneGap or Electron?
      - filleduchaos 8y ago
        Yes, and neither of them are native, nor are either of them relevant to my comment. What was your point again?
  - efrafa 8y ago
hitekker 8y ago
>Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing. Buried lede. Why not just say it outright?
- pteredactyl 8y ago
  It's Airbnb!
- mychael 8y ago
  Airbnb has managed to over-engineer a Medium blog post.
akmarinov 8y ago
Reading a bit between the lines and keeping in mind that rumour that Facebook was removing RN from some of their projects… Could it be true? Does AirBNB see the writing on the wall somehow? I know that RN is open source and people will continue to support it and everything will be great, but without Facebook behind it, I wonder how much traction it’ll have.
- htormey 8y ago
  "keeping in mind that rumour that Facebook was removing RN from some of their projects" Where are you getting that from? The React Native team at Facebook just put out a roadmap that seemed to indicate they were still very committed to the project and investing in it: http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state... "At Facebook, we're using React Native more than ever and for many important projects. One of our most popular products is Marketplace, one of the top-level tabs in our app which is used by 800 million people each month. Since its creation in 2015, all of Marketplace has been built with React Native, including over a hundred full-screen views throughout different parts of the app."
- shafte 8y ago
  That rumor was thoroughly debunked (see the discussion in the original HN thread: https://news.ycombinator.com/item?id=17216628 https://news.ycombinator.com/item?id=17216628). Please don't repeat and spread false rumors. It cheapens discussion about legitimate technical choices that organizations make.
deleted 8y ago
[deleted]
Apocryphon 8y ago
Really curious as to how Flutter (and Xamarin, NativeScript, Ionic, Vue-based write-once frameworks, etc.) can overcome the difficulties expressed in this piece.
- creyes 8y ago
  Me too. Last time I played with Ionic it was still mostly wrapped webviews though. And Vue-native is actually the worst. It transpiles Vue code into React Native code that then gets sent across the bridge to native apis.
  - Moter8 8y ago
    Sorry, have you got any source for the vue-native part? I haven't heard of that and I'm interested.
    - txmjs 8y ago
      Check out the landing page at https://vue-native.io/ https://vue-native.io/ at the bottom, "Compiles to React Native". It's important to note that "Vue Native" isn't officially endorsed by Vue.js.
- yesimahuman 8y ago
  At the risk of being flippant, few companies are building major consumer mobile apps like Airbnb (100 mobile devs is massive compared to the rest of the market), and many are building data-driven business apps. That, or they don’t have the history of native app dev so they don’t have existing native engineers or apps. So while most of the technologies mentioned above wouldn’t work for Airbnb, they work great for a huge chunk of the market. At Ionic we work with teams every day that are meeting their mobile goals with our tech, so we don’t live or die by what works for Airbnb or not.
- equasar 8y ago
  My guess is that Flutter will conquer the majority of data-driven business apps, since it is the closest multi-platform mobile framework to native code.
samfisher83 8y ago
If you are a small startup using react native makes sense. If you are a billion dollar company why not just have a team for each platform. Or better yet have have 2 teams for each and let them compete for whose product gets shipped.
- melvinram 8y ago
  Resources, even at a semi-large company, are finite. Teams have limited head counts and usually an ever increasing list of asks from Product team. Being efficient is not optional.
  - samfisher83 8y ago
    Lets do a little math. FB has 25k employees. Lets suppose they pay everyone a million buck. That is 25billion. Their gross profits were 35 billion. They can afford to have two teams or 3 teams or 4 teams working on the app. I don't know what Airbnb's numbers are, but I am sure they can afford to have multiple teams.
    - apahwa 8y ago
      I can't tell if you are trolling or not.
ajcodez 8y ago
I remember mid 2017 react native and the upgrade pain distinctly. It took a full week to set exact versions and run yarn outdated over and over, pull up the release notes one package at a time, try bumping the version, see if it breaks, try the next version, no that’s broken, try bumping react, no that breaks the other one, etc. It was hell.
jaequery 8y ago
well, its unfortunate that React Native didn't work for them. i think RN is great solution and direction for mobile in general. sure it can be improved but at the moment, it is the best we have for cross-platform mobile development.
- Reedx 8y ago
  Have you tried Flutter? That's looking promising.
  - weka 8y ago
    Yeah... but... dart.
    - Apocryphon 8y ago
      Is there actually something wrong with the language? If it's a matter of the issue of having to learn a new language, it's not as if there were many Objective-C, Swift, or Kotlin developers before mobile.
    - wootie512 8y ago
      Started learning Dart and I like it a lot. Not sure what the issue is except that it is yet another language to learn. Google designed it to be easy to learn for other devs. I am mainly only experienced in Java and some Kotlin, and I found Dart easy to pick up.
ksec 8y ago
What is wrong with TurboLink 5? Not Turbolink 3 or previous version, v5 is very much a total rewrite. Turbolinks 5 allows hybrid Apps that offers most of the benefits without many of the complexity, it is HTML after all. It seems there are sites that uses Rails, including AirBnB. But I have yet to seen a site that uses Turbolink apart from Bassecamp, even Github uses its own version of pjax rather then Turbolink.
- deedubaya 8y ago
  I use the turbolinks libraries for iOS and android and the experience has been great.
  - ksec 8y ago
    I am just wondering if there are any pitfalls. While not many are writing about their technical failure of React Native or whatever tech it is. You will at least know they have changed the stack, or words on the street / twitter they are retrying new things because old things didn't work etc. But TurboLinks 5? None, not even a mention or beep. As if no one is using it. While we are happily using it someone else may be running into issues we haven't yet doubt with. It is pretty much like Startup news, I don't want to read about how you succeed this just once. I want to read about your thousands other failure, what works, what not, and what you ( Or I could ) learned from it. By stating your problem, your intended solution, and the results I could make a better informed decision somewhere down the line. And all the time we got on the internet is everyone cheer leading mindlessly.
- maxfurman 8y ago
  My guess is that orgs that want a dynamic frontend are choosing SPAs over turbolinks, and orgs that want to serve static pages aren't bothering to put in the nonzero effort to make turbolinks work.
  - ksec 8y ago
    Excuses my ignorance. I don't understand how we could do 99% or even 100% with "pages", but instead we still insist on "apps".
rboyd 8y ago
Very good write-up, thanks for posting. Some of the frustrations definitely hit home. I think for small teams and indies React Native is an awesome piece of technology that can enable them to target both platforms where it would be nearly impossible otherwise. I can understand how orchestrating the work of a huge team could introduce new issues though. It would be interesting to know why some of the infra layers that the article mentions (i18n, networking) were behind bridge when they seem like prime candidates for js implementation. What I'd really like to know though is how other teams are managing the design pipeline (getting from psd/sketchapp to code without hand coding flexbox styles). We've looked at some tools like supernova.studio and BuilderX, and while showing promise these seem like they have a long road ahead.
- spiritcat 8y ago
  What's wrong with hand coding flexbox styles?
  - morenoh149 8y ago
    If we can help designers realize their designs in software without requiring an engineer, that would be a great thing.
- raphaelrk 8y ago
  Re: your last sentence, Pagedraw (YC W18) is a good choice for going from design to UI components and features great Sketch and Figma integration.
  - rboyd 8y ago
    Thanks for the pointer. That does look interesting. RN not yet GA though? I also noticed Framer announced an upcoming tool 'Framer X' with React support -- not sure if that includes RN either.
- gpeal 8y ago
  We wanted to leverage our existing infra to have a consistent experience between native and RN screens. For example, you want to have the same network cache.
hesarenu 8y ago
I have come to same conclusion. Have few production apps and an ongoing one in react native. Dealing with native code has been frustrating, additionally plugins would not be up to date as well. Going native would be a better choice. I would though love react jsx syntax for building native views in swift/Kotilin.
- ptx 8y ago
  Kotlin doesn't need JSX, as it already has features for building DSLs for such things[1], allowing you to easily express hierarchical structures as perfectly normal Kotlin code. [1] http://kotlinlang.org/docs/reference/type-safe-builders.html http://kotlinlang.org/docs/reference/type-safe-builders.html
crabl 8y ago
Tangential to this, he says Airbnb has 100 mobile devs writing about 80k LoC of app code, 40K LoC of infra, and 220 "screens". We've got an app with about the same "dimensions", developed in a similar timeframe, with some very complex financial business logic and 2 developers working on it... what on Earth do their devs spend their time on? Is their engineering organization really _that_ inefficient?
- apahwa 8y ago
  "For reference, we have about 10x the amount of code and 4x the number of screens on each native platform". So the amount of code and the complexity is substantially more difficult than you describe. You probably also don't have as rigorous AB testing, logging, internationalization, contributions to open source, etc.
  - deleted 8y ago
    [deleted]
  - Tade0 8y ago
    I used to be a CKEditor core dev. The codebase was 150k LOC of (mighty complex at times)JS and there were four of us working on the LTS(4.x) - we were somewhat understaffed, but not "we need a hundred devs for this" understaffed. On the other hand last year I spent two weeks working on a project for which I was borrowed from another one - they had a total of 120k LOC(Java, TypeScript), twenty people and at least the front-end was a dumpster fire. I guess people don't scale well.
    - hokkos 8y ago
      I guess quality is a factor, because CKEditor 4.X might have a lot of lines but it is one of the worst library I had the displeasure to use.
      - bigmanwalter 8y ago
        I use it extensively in my current project and it is a joy. Different strokes for different folks.
vinceyuan 8y ago
Great article. I started iOS programming in late 2009 and had solid experience of native mobile programming (iOS/Android) and web frontend/backend (RoR/Node.js/React/Go) before I started to use React Native in late 2016. I totally agree with the auther on what work well and what don't work well about React Native. Sad to see Airbnb sunsetting React Native. In my opinion, 2 of the reasons Airbnb had more and more issues with React Native are: 1. They don’t adopt type checking for JavaScript. “We explored adopting flow but cryptic error messages led to a frustrating developer experience. We also explored TypeScript but integrating it into our existing infrastructure such as babel and metro bundler proved to be problematic.” “A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone.” This is absolutely not just "a side-effect". In a real project, many developers modify the same code base, and the interfaces (Classes, function paramenters, props, etc) are changed frequently. I think type checking system, e.g. Flow, is a must for writing JavaScript code for either backend or frontend. My team is using Flow, and I ask my team members to adopt type checking as much as possible. When I see something like this funcA(a, b), I always ask the developer to change it to funcA(a: TypeA, b: TypeB): TypeC. It is really very helpful, especailly when we need to change code. 2. They don’t ask engineers to keep most code in JavaScript. “Often times, it is not clear whether code should be written in native or React Native. Naturally, an engineer will often choose the platform that they are more comfortable which can lead to unideal code.” All logic and UI should be written in JavaScript. Native code should only be used when we cannot do in JavaScript or the performance is very bad. When I am using React Native, I do miss the simplicity of writing and debugging native code. But when you need to support both iOS and Android, it's great to just keep one code base in JavaScript. Again, espeically when you need to change the code frequently, you don't need to do the some thing twice. (One for iOS, the other for Android.)
- vinceyuan 8y ago
  Typo. It should be "you don't need to do the same thing twice"
deleted 8y ago
[deleted]
xenadu02 8y ago
I’ve never seen anyone do a battery impact analysis of React Native. I wonder why? Person sally, I don’t want to use products where the developer prioritizes their problems over my experiencs but YMMV. Some will argue that an Electron dumpster fire is superior to nothing. I consider that debatable.
- rimliu 8y ago
  I am still waiting for tide to turn and for times when users mattered to come back. Not sure if it ever will.
  - mkohlmyr 8y ago
    I don't buy this sentiment one bit. In my opinion this nostalgia is almost entirely unjustified unless your primary metric of "when users mattered" is "software used less RAM and CPU". Which may not even be factually correct from a percentage of available resources perspective. Modern day software applications are far more accessible and usable on average than those of the 90s and 00s. And that's the metric that actually matters. More people are able to do more things with software.
- ricardobeat 8y ago
  RN is nothing like an Electron app though. Rendering is fully native, no browser engine involved. It does add not-insignificant overhead due to JSC, Yoga and native bridge, but it will depend a lot on the nature of the app.
- bengotow 8y ago
  Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is fairly fast, business logic doesn't take that long to run (100ms vs 200ms, whatever.), and it all pales in comparison to running GPS or the display for a few seconds. Unless you're playing a game or running some complex algorithm, most of your phone's battery goes to the wifi / cell radio and the display.
  - maga_2020 8y ago
tannhaeuser 8y ago
I was looking forward to using RN but I guess I fell victim (again!) to whishful thinking and the "No silver bullett" fallacy. Come to think of it, why have we accepted React as the go-to approach to this degree? React doesn't even make an effort to isolate from HTML and DOM at the conceptual level, and I'd wager an opinionated framework about "panels", "fields", "field groups" and events is more representative of what folks typically want to do with React, rather than manipulating pseudo-markup using JSX however elegant and neutral.
buremba 8y ago
The article doesn't seem to explain specifically why RN didn't work for them but I believe that the real pain for them is to organize 100 engineers to work on the same project. Often they were confused about native vs RN approach and had to write native libraries and integrated them with RN which requires 3 different teams to write & test and integrate their code. I can see that if one of the teams is either slow or run into strange bugs, they will be the bottleneck and slow down all of them. From this perspective, similar to why Netflix or other large organization choose micro-services rather than monoliths, it would be better for Airbnb to develop 2 different native apps separately rather than having 3 different teams depending on each other.
underwater 8y ago
I feel like we’re missing a lot of the story. Many of the React Native issues sound painful, but they handwave away a lot of the complexities and drawbacks of their new architecture. For example their answer to RN’s one second rebuilds is a custom Android build configuration that eliminates most of their 5 minute builds. They are proposing a custom server rendering setup and don’t know how to solve the hardest problems like wiring up events (HTML anyone?).
fs111 8y ago
As a user of AirBnb I would be so happy if they just stopped updating the app. They are making it worse and worse. When I travel and I arrive at an airport, I do not need spiffy animations and "fun things to do" in the city I am in, I need a way to quickly find the address of the place or a way to message the host. Stop with all this experience stuff and give me the facts I need right now
- spiderfarmer 8y ago
  Hey, they hired so many people. You can't let them just sit there doing nothing.
  - forgot-my-pw 8y ago
    Soon to be released: Airbnb Lite
  - russdpale 8y ago
    Yep, and offering local things to do is some of the lowest hanging fruit a project manager can grab on to now a days to CYOA on why he hired so many employees.
- whistlerbrk 8y ago
  I couldn't possibly agree more. The annoying minimalism is killing me. It took me 5 minutes to find a map view the other day because they've buried it so much and floated their "experiences" stuff up top.
  - lucasverra 8y ago
    >floated their "experiences" stuff up top That is no minimalism in my hand book
- wtvanhest 8y ago
  The experience stuff is fine, but they need to seriously evaluate how changes impact users. When a user is on a trip, getting host and address info should be easy. When searching for a listing, finding the map should be easy.
sandGorgon 8y ago
Isn't React Native end of lifed at Facebook? The effort is taking the best principles of React Native and focusing on Litho https://fblitho.com https://fblitho.com or ComponentKit - the effort to have a unified framework for both iOS and Android is pretty much abandoned. I think React Native is in legacy support mode rather than active innovation.
- Steltek 8y ago
  I can't find any reference to that with Google. Mind sharing a link?
  - ldavison 8y ago
    This was recently making the rounds, I suspect this is what OP was referring to: - https://twitter.com/sandofsky/status/1002637340291018754 https://twitter.com/sandofsky/status/1002637340291018754 Responses from someone at FB: - https://twitter.com/sophiebits/status/1003101478427357184 https://twitter.com/sophiebits/status/1003101478427357184 - https://twitter.com/sandofsky/status/1003104331833532416 https://twitter.com/sandofsky/status/1003104331833532416
- myguysi 8y ago
  Nope they posted a blog article[0] last week about their plans. Please check your facts first next time because there’s been nothing from Facebook to indicate that. [0] http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state...
- bigsassy 8y ago
  No, it's still being worked on. To quote their latest blog post: We're working on a large-scale rearchitecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps. http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state...
dawhizkid 8y ago
I wrote a few weeks ago about how ridiculous it was for AirBnB to spend 18 months testing a new font. A 5 part series on React Native is again next-level indulgent. Why am I not surprised engineers at Airbnb have so little to do than to write a novel about a framework?
- eugeniub 8y ago
  Yeah nothing weirder than engineers writing about their experiences with different technologies.
  - dawhizkid 8y ago
    A 5 part series. 5!!
- jongold 8y ago
  fwiw it wasn't 18 months "testing" a new font - most of that was font development with an external partner, then implementing across many surfaces without creating bugs that affected accessibility, then testing. doing things takes time, huge surprise right?
flamedoge 8y ago
tldr; https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...
ArtemTrityak 8y ago
It looks like if you have small team and you want to develop iOS / Android prototype fast RN is good choice. This case you're looking not for "best user-experience" but "okay user experience fast". But for big companies java/kotlin or/and Objective-C/swift native apps will be more efficient.

498 points by msoad 8y ago

This is a really good write up and I love how they were cautious not to feed the ongoing fanboyism in for and against React Native folks. Say what you like but this is a very mature move from a young engineering organization.

faitswulff 8y ago
I have to agree. It was really interesting that they highlighted that nearly 2/3rds of their engineers would use React Native again. I also assumed that the last part of the blog series was going to be mostly fluff / product announcements, but their efforts in server side rendered native screens and drastic reductions in build time are legitimate takeaways from devs who are used to development cycles at React-Native speeds.
- akmarinov 8y ago
  Server side rendered native screens just seem like fancy words for browser to me… I get that it’ll have native performance and responsiveness, but still maybe just touch up your website and call it a day?
  - faitswulff 8y ago
    Ah, my mistake, it should say "server-driven," which is more accurate. The view isn't actually rendered on the server, it just seems to be sent over in a declarative format, which the client then renders into a native view.
    - mpweiher 8y ago
      > sent over in a declarative format like HTML? > which the client then renders into a native view. A WebView?
      - scottmf 8y ago
        No
        scottmf 8y ago
        Sorry if the short response seemed rude. No is the answer to both of your questions. RN isn’t just “HTML in a webview” like PhoneGap or Cordova: elements are actually rendered as native UI components. E.g., a <Text> element becomes a native UILabel on iOS and a TextView on Android.
- philipwhiuk 8y ago
  You have to wonder how many of their 100 engineers are going to dislike having to become iOS/Android devs.
  - gpeal 8y ago
    The vast majority of the 100 always have been and are still Android and iOS devs. React Native never made up more than 10-20% of our mobile engineers and many of them came from Android or iOS backgrounds.
    - heyheyhey 8y ago
      How's FB's RN team reacted to Airbnb's decision to move away from RN?
  - matwood 8y ago
    For me, in order of enjoyable front end developer experience it would go iOS > web/js/react > Android.
electricslpnsld 8y ago
> Say what you like but this is a very mature move from a young engineering organization. Airbnb is ten years old at this point, I'm not sure that really counts as young!

onedev 8y ago

Others have been coming out and talking about similar experiences with React Native. This thread made the rounds on Twitter and Medium fairly recently: https://twitter.com/sandofsky/status/1002634185566236679 https://twitter.com/sandofsky/status/1002634185566236679 https://twitter.com/VivekxK/status/1002694526467653632 https://twitter.com/VivekxK/status/1002694526467653632

faitswulff 8y ago
Don't forget Udacity removing it from their codebase: https://twitter.com/n8ebel/status/1006244834351312897 https://twitter.com/n8ebel/status/1006244834351312897
- ex3ndr 8y ago
  Udacity is a bit strange example. This means that they have what? triple size of react native in their main app? That's weird because on android react native blows APK to much larger percentage.
nickspag 8y ago
Coursera also removed it completely.
- rimliu 8y ago
  Source?
  - faitswulff 8y ago
    https://twitter.com/mustafasf/status/1002787351188332544?s=09 https://twitter.com/mustafasf/status/1002787351188332544?s=0...
eysquared 8y ago
The common thread I see is that mixing native and react-native is hard. Doing so while working across organizations that may or may not use react-native is doubly so. Sometimes this boils down to the technology, knowledge, and the engineering systems needed to support both but I've also found native developers tend to strongly dislike react-native and lobby against whenever they can. For me, I'm using it to successfully build mobile apps for a large tech company with very limited mobile developer resources. We've been able to ship Android and iOS apps in a couple months using 100% react-native. I attribute a lot of this to knowing the limitations of the platform and designing a cross-platform experience from the start rather than trying to get the "best of native" out of abstracted JavaScript. I'll always argue that native is the way to go for the best user experience but react-native is a great tool to have in the mobile space.

benawad 8y ago

"Redux is notorious for its boilerplate and has a relatively difficult learning curve. We provided generators for some common templates but it was still one of the most challenging pieces and source of confusion while working with React Native." Interesting to see even Airbnb struggles with Redux

bpicolo 8y ago
The cognitive overhead of redux ends up being pretty high due to the boilerplate in my opinion. It feels like complexity increases very linearly as project size goes. I've found that MobX translates to a much simpler mental model, though it does have a variety of quirks to deal with that Redux doesn't face (like converting objects to non-observable for test case assertions)
- rawrmaan 8y ago
  Yeah, MobX is significantly easier to reason about, even if it may have a few idiosyncrasies that make debugging more challenging. Also, performance optimization of React components is a cinch with MobX and a nightmare with Redux.
  - acemarke 8y ago
    Can you explain what you mean by "perf optimization is a nightmare with Redux" ? Generally, Redux helps improve performance in a React app, especially as you connect more components.
    - rawrmaan 8y ago
      Let's say you have a component deep in the hierarchy that needs to update based on a small but frequent change in a large object (thousands of keys). With Redux, you have to figure out how to diff the old and new copies of that object to figure out what changed. With MobX, you just observe the value of the exact key you're interested in. That's just one example, but I generally spent a ton of time writing complex shouldComponentUpdate functions and therefore making lots of mistakes with Redux. I've found MobX much more suited to building complex UIs with deep hierarchies and tens to hundreds of total elements on the screen at once, where updating only exactly when necessary is critical. I use MobX for my game Falcross, which I wrote about in the State of React Native 2018 thread from a few days ago: https://news.ycombinator.com/item?id=17316877 https://news.ycombinator.com/item?id=17316877 I initially used Redux, and I found it actually technically impossible to get the game to perform well using Redux. I tried everything.

smt88 8y ago

None of the recent articles or HN comment threads about React Native spend much time evaluating Haxe. I guess it's not that widely used for CRUD apps and is more popular for games? Anyway, I'd love to know how it would work for an Airbnb-like org.

SneakerXZ 8y ago
It is same with Xamarin. They don't have people that would know these languages, and they would be passionate about them.
- woolvalley 8y ago
  Xamarin and co suffer from the same dual layer issues that react native has when I last looked into it. C# isn't that popular from a silicon valley engineering perspective, since the first class C# implementation wasn't open source until very recently. Yes mono has always be OSS, but it has also been a second class citizen too.
  - SneakerXZ 8y ago
    Only Xamarin.Forms introduces another layer for you (it is the same concept as React Native). If you use Xamarin.iOS and Xamarin.Android you call underlying APIs directly. Although there can be issues with bindings, nothing like you will face with React Native. I am aware of why C# isn't popular among startups. It is sad because C# is a great language that has amazing tooling support. It runs everywhere - Xamarin for apps, ASP.NET for servers, Blazor for browsers, and it is getting only better, and I cannot imagine how awesome it would be if other companies helped Microsoft. But I can only dream.
    - smt88 8y ago
      I think F# and .NET Core may become popular among certain kinds of startups (FinTech, logistics, etc.). It's a good compromise between Java and something like Haskell, in my opinion.
    - deleted 8y ago

cpeterso 8y ago

I haven't used React Native, but I've ready a few posts from people adopting it. They typically test the waters by writing new app views in React Native instead of rewriting everything. But how much cognitive overhead is there in maintaining multiple toolchains (React Native and native and/or web views) and debugging views in different languages in one app?

MBCook 8y ago
I work on an app that is written with a combination of iOS native code, JS, and server side code. It’s not easy to debug at all. The problem they mentioned where your stack traces just end at layer transitions is a real problem. Even if the server side isn’t involved in the bit you’re working on.
k__ 8y ago
If you can use Expo you're probably good to go without much tooling.

pjmlp 8y ago

Yet another company discovers what many of us did ages ago with multi-platform frameworks. Additional layers not supported by platform owners, mean extra debugging efforts tracking down which layer is responsible, catching up with native SDK features, need to be an expert at both layers, lack of integration with native debugging tools... But business always wants the Ferrari solution at the cost of a Fiat panda.

RussianCow 8y ago
While I don't disagree with your premise, "need to be an expert at both layers" is absolutely still true if you build your app natively for each platform (more so, even). At least with a common platform, if nothing else, you can share quite a bit of code, and that alone might make it worth the extra layers.
- chii 8y ago
  But the draw of cross platform is that you don't need to be an expert in them! Or at least, that's the advertised advantage.
  - eropple 8y ago
    For the happy path, you don't. And many apps can stick very comfortably on the happy path. I wrote a controller for a video mixer[0] that ran out-of-the-box on Android and iOS using websockets and everything Just Worked. (I still haven't released the iOS version due to lack of test equipment, but it runs just fine.) [0] - http://bit.ly/buymyapp http://bit.ly/buymyapp
- jiaweihli 8y ago
  I understood 'both layers' to mean both the abstraction layer, and the underlying layer being abstracted. Actually, you might even understand it as 'all 3 layers' here - iOS, Android, React Native.
- LeoNatan25 8y ago
  And “developing” in RN requires you to be an expert in three fields: iOS, Android and the RN layer, which is often buggy. How is that better?

s17n 8y ago

tl;dr: > Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing.

ex3ndr 8y ago

While i don't have much experience in RN, but have a decade of mobile native development (android + iOS) and two years of React. The whole 10 years there were people that think that they can just get "web" technology and speedup mobile development. Almost always this companies had no mobile engineers that know how this stuff works. Developers that know that you just can't listen to scroll and update animations by sending messages to background js thread. This just completely wrong on mobile. Most mobile devs spend months to make it fast and easy to use. There are no way to do this in most cases on RN. AirBNB's app is a perfect example of this. Trying to deliver "better" experience they completely kill scrolling performance. Even top level iPhones feels laggy. But yay! We have animations! AirBNB's app is barely usable on two-year-old androids. This is just simply wrong, this is not how you can achieve good performance and nice animations on such small devices. In most cases this is a kind of art and a lot of testing and tweaking for every device. This can be done by only ONE talented developer per platform per year. Surely AirBNB has resources. Just take specific screen and tweak it to hell. On the other side, react and declarative kind of state is really doesn't work well for non-page oriented apps. Mapping history of navigation via redux store is just an awful and useless idea that helps with nothing. Right now there are still no navigation library. Every time i tried to start something in React Native i failed since i wasn't able to apply my skills to make it behave fast there are just no easy way to do this. React Native for sure is a good thing, but it's evolution shaped by web devs that try to reflect their experience from web development, but building a good mobile app is completely different from web one. For example, there are no dom, UI manipulation is not slow, navigation between pages and keeping it's state is not a problem most of the time (there are no real "back" button that you have to handle somehow). UI frameworks are more mature (while have less API than HTML).

jeanregisser 8y ago
> Right now there are still no navigation library. React Navigation and React Native Navigation are both viable options with their own pros and cons. Been using them successfully in different projects. https://reactnavigation.org https://reactnavigation.org https://wix.github.io/react-native-navigation https://wix.github.io/react-native-navigation

kbyatnal 8y ago

"While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit when toLocaleString worked on iOS and but only worked on Android while debugging. It turns out that the Android JSC doesn’t include it and it was silently failing unless you were debugging in which case it was using V8 which does." Wow, I can't imagine how frustrating this must have been to debug.

MBCook 8y ago
I had something like that once in native web dev. It turned out that by default when using the debugging pane the browser would disable cache so the issue (whatever it was) disappeared. Close debugging? It broke again. Maddening.
- filleduchaos 8y ago
  > native web dev That has to be the strangest combination of terms I've seen this month.
  - skocznymroczny 8y ago
    I've seen people refer to bare metal Javascript, which sounds even weirder.
  - kroltan 8y ago
    Ever heard of PhoneGap or Electron?
    - filleduchaos 8y ago
      Yes, and neither of them are native, nor are either of them relevant to my comment. What was your point again?
- efrafa 8y ago

hitekker 8y ago

>Due to a variety of technical and organizational issues, we will be sunsetting React Native and putting all of our efforts into making native amazing. Buried lede. Why not just say it outright?

pteredactyl 8y ago
It's Airbnb!
mychael 8y ago
Airbnb has managed to over-engineer a Medium blog post.

akmarinov 8y ago

Reading a bit between the lines and keeping in mind that rumour that Facebook was removing RN from some of their projects… Could it be true? Does AirBNB see the writing on the wall somehow? I know that RN is open source and people will continue to support it and everything will be great, but without Facebook behind it, I wonder how much traction it’ll have.

htormey 8y ago
"keeping in mind that rumour that Facebook was removing RN from some of their projects" Where are you getting that from? The React Native team at Facebook just put out a roadmap that seemed to indicate they were still very committed to the project and investing in it: http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state... "At Facebook, we're using React Native more than ever and for many important projects. One of our most popular products is Marketplace, one of the top-level tabs in our app which is used by 800 million people each month. Since its creation in 2015, all of Marketplace has been built with React Native, including over a hundred full-screen views throughout different parts of the app."
shafte 8y ago
That rumor was thoroughly debunked (see the discussion in the original HN thread: https://news.ycombinator.com/item?id=17216628 https://news.ycombinator.com/item?id=17216628). Please don't repeat and spread false rumors. It cheapens discussion about legitimate technical choices that organizations make.

deleted 8y ago

[deleted]

Apocryphon 8y ago

Really curious as to how Flutter (and Xamarin, NativeScript, Ionic, Vue-based write-once frameworks, etc.) can overcome the difficulties expressed in this piece.

creyes 8y ago
Me too. Last time I played with Ionic it was still mostly wrapped webviews though. And Vue-native is actually the worst. It transpiles Vue code into React Native code that then gets sent across the bridge to native apis.
- Moter8 8y ago
  Sorry, have you got any source for the vue-native part? I haven't heard of that and I'm interested.
  - txmjs 8y ago
    Check out the landing page at https://vue-native.io/ https://vue-native.io/ at the bottom, "Compiles to React Native". It's important to note that "Vue Native" isn't officially endorsed by Vue.js.
yesimahuman 8y ago
At the risk of being flippant, few companies are building major consumer mobile apps like Airbnb (100 mobile devs is massive compared to the rest of the market), and many are building data-driven business apps. That, or they don’t have the history of native app dev so they don’t have existing native engineers or apps. So while most of the technologies mentioned above wouldn’t work for Airbnb, they work great for a huge chunk of the market. At Ionic we work with teams every day that are meeting their mobile goals with our tech, so we don’t live or die by what works for Airbnb or not.
equasar 8y ago
My guess is that Flutter will conquer the majority of data-driven business apps, since it is the closest multi-platform mobile framework to native code.

samfisher83 8y ago

If you are a small startup using react native makes sense. If you are a billion dollar company why not just have a team for each platform. Or better yet have have 2 teams for each and let them compete for whose product gets shipped.

melvinram 8y ago
Resources, even at a semi-large company, are finite. Teams have limited head counts and usually an ever increasing list of asks from Product team. Being efficient is not optional.
- samfisher83 8y ago
  Lets do a little math. FB has 25k employees. Lets suppose they pay everyone a million buck. That is 25billion. Their gross profits were 35 billion. They can afford to have two teams or 3 teams or 4 teams working on the app. I don't know what Airbnb's numbers are, but I am sure they can afford to have multiple teams.
  - apahwa 8y ago
    I can't tell if you are trolling or not.

ajcodez 8y ago

I remember mid 2017 react native and the upgrade pain distinctly. It took a full week to set exact versions and run yarn outdated over and over, pull up the release notes one package at a time, try bumping the version, see if it breaks, try the next version, no that’s broken, try bumping react, no that breaks the other one, etc. It was hell.

jaequery 8y ago

well, its unfortunate that React Native didn't work for them. i think RN is great solution and direction for mobile in general. sure it can be improved but at the moment, it is the best we have for cross-platform mobile development.

Reedx 8y ago
Have you tried Flutter? That's looking promising.
- weka 8y ago
  Yeah... but... dart.
  - Apocryphon 8y ago
    Is there actually something wrong with the language? If it's a matter of the issue of having to learn a new language, it's not as if there were many Objective-C, Swift, or Kotlin developers before mobile.
  - wootie512 8y ago
    Started learning Dart and I like it a lot. Not sure what the issue is except that it is yet another language to learn. Google designed it to be easy to learn for other devs. I am mainly only experienced in Java and some Kotlin, and I found Dart easy to pick up.

ksec 8y ago

What is wrong with TurboLink 5? Not Turbolink 3 or previous version, v5 is very much a total rewrite. Turbolinks 5 allows hybrid Apps that offers most of the benefits without many of the complexity, it is HTML after all. It seems there are sites that uses Rails, including AirBnB. But I have yet to seen a site that uses Turbolink apart from Bassecamp, even Github uses its own version of pjax rather then Turbolink.

deedubaya 8y ago
I use the turbolinks libraries for iOS and android and the experience has been great.
- ksec 8y ago
  I am just wondering if there are any pitfalls. While not many are writing about their technical failure of React Native or whatever tech it is. You will at least know they have changed the stack, or words on the street / twitter they are retrying new things because old things didn't work etc. But TurboLinks 5? None, not even a mention or beep. As if no one is using it. While we are happily using it someone else may be running into issues we haven't yet doubt with. It is pretty much like Startup news, I don't want to read about how you succeed this just once. I want to read about your thousands other failure, what works, what not, and what you ( Or I could ) learned from it. By stating your problem, your intended solution, and the results I could make a better informed decision somewhere down the line. And all the time we got on the internet is everyone cheer leading mindlessly.
maxfurman 8y ago
My guess is that orgs that want a dynamic frontend are choosing SPAs over turbolinks, and orgs that want to serve static pages aren't bothering to put in the nonzero effort to make turbolinks work.
- ksec 8y ago
  Excuses my ignorance. I don't understand how we could do 99% or even 100% with "pages", but instead we still insist on "apps".

rboyd 8y ago

Very good write-up, thanks for posting. Some of the frustrations definitely hit home. I think for small teams and indies React Native is an awesome piece of technology that can enable them to target both platforms where it would be nearly impossible otherwise. I can understand how orchestrating the work of a huge team could introduce new issues though. It would be interesting to know why some of the infra layers that the article mentions (i18n, networking) were behind bridge when they seem like prime candidates for js implementation. What I'd really like to know though is how other teams are managing the design pipeline (getting from psd/sketchapp to code without hand coding flexbox styles). We've looked at some tools like supernova.studio and BuilderX, and while showing promise these seem like they have a long road ahead.

spiritcat 8y ago
What's wrong with hand coding flexbox styles?
- morenoh149 8y ago
  If we can help designers realize their designs in software without requiring an engineer, that would be a great thing.
raphaelrk 8y ago
Re: your last sentence, Pagedraw (YC W18) is a good choice for going from design to UI components and features great Sketch and Figma integration.
- rboyd 8y ago
  Thanks for the pointer. That does look interesting. RN not yet GA though? I also noticed Framer announced an upcoming tool 'Framer X' with React support -- not sure if that includes RN either.
gpeal 8y ago
We wanted to leverage our existing infra to have a consistent experience between native and RN screens. For example, you want to have the same network cache.

hesarenu 8y ago

I have come to same conclusion. Have few production apps and an ongoing one in react native. Dealing with native code has been frustrating, additionally plugins would not be up to date as well. Going native would be a better choice. I would though love react jsx syntax for building native views in swift/Kotilin.

ptx 8y ago
Kotlin doesn't need JSX, as it already has features for building DSLs for such things[1], allowing you to easily express hierarchical structures as perfectly normal Kotlin code. [1] http://kotlinlang.org/docs/reference/type-safe-builders.html http://kotlinlang.org/docs/reference/type-safe-builders.html

crabl 8y ago

Tangential to this, he says Airbnb has 100 mobile devs writing about 80k LoC of app code, 40K LoC of infra, and 220 "screens". We've got an app with about the same "dimensions", developed in a similar timeframe, with some very complex financial business logic and 2 developers working on it... what on Earth do their devs spend their time on? Is their engineering organization really _that_ inefficient?

apahwa 8y ago
"For reference, we have about 10x the amount of code and 4x the number of screens on each native platform". So the amount of code and the complexity is substantially more difficult than you describe. You probably also don't have as rigorous AB testing, logging, internationalization, contributions to open source, etc.
- deleted 8y ago
  [deleted]
- Tade0 8y ago
  I used to be a CKEditor core dev. The codebase was 150k LOC of (mighty complex at times)JS and there were four of us working on the LTS(4.x) - we were somewhat understaffed, but not "we need a hundred devs for this" understaffed. On the other hand last year I spent two weeks working on a project for which I was borrowed from another one - they had a total of 120k LOC(Java, TypeScript), twenty people and at least the front-end was a dumpster fire. I guess people don't scale well.
  - hokkos 8y ago
    I guess quality is a factor, because CKEditor 4.X might have a lot of lines but it is one of the worst library I had the displeasure to use.
    - bigmanwalter 8y ago
      I use it extensively in my current project and it is a joy. Different strokes for different folks.

vinceyuan 8y ago

Great article. I started iOS programming in late 2009 and had solid experience of native mobile programming (iOS/Android) and web frontend/backend (RoR/Node.js/React/Go) before I started to use React Native in late 2016. I totally agree with the auther on what work well and what don't work well about React Native. Sad to see Airbnb sunsetting React Native. In my opinion, 2 of the reasons Airbnb had more and more issues with React Native are: 1. They don’t adopt type checking for JavaScript. “We explored adopting flow but cryptic error messages led to a frustrating developer experience. We also explored TypeScript but integrating it into our existing infrastructure such as babel and metro bundler proved to be problematic.” “A side-effect of JavaScript being untyped is that refactoring was extremely difficult and error-prone.” This is absolutely not just "a side-effect". In a real project, many developers modify the same code base, and the interfaces (Classes, function paramenters, props, etc) are changed frequently. I think type checking system, e.g. Flow, is a must for writing JavaScript code for either backend or frontend. My team is using Flow, and I ask my team members to adopt type checking as much as possible. When I see something like this funcA(a, b), I always ask the developer to change it to funcA(a: TypeA, b: TypeB): TypeC. It is really very helpful, especailly when we need to change code. 2. They don’t ask engineers to keep most code in JavaScript. “Often times, it is not clear whether code should be written in native or React Native. Naturally, an engineer will often choose the platform that they are more comfortable which can lead to unideal code.” All logic and UI should be written in JavaScript. Native code should only be used when we cannot do in JavaScript or the performance is very bad. When I am using React Native, I do miss the simplicity of writing and debugging native code. But when you need to support both iOS and Android, it's great to just keep one code base in JavaScript. Again, espeically when you need to change the code frequently, you don't need to do the some thing twice. (One for iOS, the other for Android.)

vinceyuan 8y ago
Typo. It should be "you don't need to do the same thing twice"

deleted 8y ago

[deleted]

xenadu02 8y ago

I’ve never seen anyone do a battery impact analysis of React Native. I wonder why? Person sally, I don’t want to use products where the developer prioritizes their problems over my experiencs but YMMV. Some will argue that an Electron dumpster fire is superior to nothing. I consider that debatable.

rimliu 8y ago
I am still waiting for tide to turn and for times when users mattered to come back. Not sure if it ever will.
- mkohlmyr 8y ago
  I don't buy this sentiment one bit. In my opinion this nostalgia is almost entirely unjustified unless your primary metric of "when users mattered" is "software used less RAM and CPU". Which may not even be factually correct from a percentage of available resources perspective. Modern day software applications are far more accessible and usable on average than those of the 90s and 00s. And that's the metric that actually matters. More people are able to do more things with software.
ricardobeat 8y ago
RN is nothing like an Electron app though. Rendering is fully native, no browser engine involved. It does add not-insignificant overhead due to JSC, Yoga and native bridge, but it will depend a lot on the nature of the app.
bengotow 8y ago
Eh, I can almost guarantee it has almost no battery impact. JavaScriptCore is fairly fast, business logic doesn't take that long to run (100ms vs 200ms, whatever.), and it all pales in comparison to running GPS or the display for a few seconds. Unless you're playing a game or running some complex algorithm, most of your phone's battery goes to the wifi / cell radio and the display.
- maga_2020 8y ago

tannhaeuser 8y ago

I was looking forward to using RN but I guess I fell victim (again!) to whishful thinking and the "No silver bullett" fallacy. Come to think of it, why have we accepted React as the go-to approach to this degree? React doesn't even make an effort to isolate from HTML and DOM at the conceptual level, and I'd wager an opinionated framework about "panels", "fields", "field groups" and events is more representative of what folks typically want to do with React, rather than manipulating pseudo-markup using JSX however elegant and neutral.

buremba 8y ago

The article doesn't seem to explain specifically why RN didn't work for them but I believe that the real pain for them is to organize 100 engineers to work on the same project. Often they were confused about native vs RN approach and had to write native libraries and integrated them with RN which requires 3 different teams to write & test and integrate their code. I can see that if one of the teams is either slow or run into strange bugs, they will be the bottleneck and slow down all of them. From this perspective, similar to why Netflix or other large organization choose micro-services rather than monoliths, it would be better for Airbnb to develop 2 different native apps separately rather than having 3 different teams depending on each other.

underwater 8y ago

I feel like we’re missing a lot of the story. Many of the React Native issues sound painful, but they handwave away a lot of the complexities and drawbacks of their new architecture. For example their answer to RN’s one second rebuilds is a custom Android build configuration that eliminates most of their 5 minute builds. They are proposing a custom server rendering setup and don’t know how to solve the hardest problems like wiring up events (HTML anyone?).

fs111 8y ago

As a user of AirBnb I would be so happy if they just stopped updating the app. They are making it worse and worse. When I travel and I arrive at an airport, I do not need spiffy animations and "fun things to do" in the city I am in, I need a way to quickly find the address of the place or a way to message the host. Stop with all this experience stuff and give me the facts I need right now

spiderfarmer 8y ago
Hey, they hired so many people. You can't let them just sit there doing nothing.
- forgot-my-pw 8y ago
  Soon to be released: Airbnb Lite
- russdpale 8y ago
  Yep, and offering local things to do is some of the lowest hanging fruit a project manager can grab on to now a days to CYOA on why he hired so many employees.
whistlerbrk 8y ago
I couldn't possibly agree more. The annoying minimalism is killing me. It took me 5 minutes to find a map view the other day because they've buried it so much and floated their "experiences" stuff up top.
- lucasverra 8y ago
  >floated their "experiences" stuff up top That is no minimalism in my hand book
wtvanhest 8y ago
The experience stuff is fine, but they need to seriously evaluate how changes impact users. When a user is on a trip, getting host and address info should be easy. When searching for a listing, finding the map should be easy.

sandGorgon 8y ago

Isn't React Native end of lifed at Facebook? The effort is taking the best principles of React Native and focusing on Litho https://fblitho.com https://fblitho.com or ComponentKit - the effort to have a unified framework for both iOS and Android is pretty much abandoned. I think React Native is in legacy support mode rather than active innovation.

Steltek 8y ago
I can't find any reference to that with Google. Mind sharing a link?
- ldavison 8y ago
  This was recently making the rounds, I suspect this is what OP was referring to: - https://twitter.com/sandofsky/status/1002637340291018754 https://twitter.com/sandofsky/status/1002637340291018754 Responses from someone at FB: - https://twitter.com/sophiebits/status/1003101478427357184 https://twitter.com/sophiebits/status/1003101478427357184 - https://twitter.com/sandofsky/status/1003104331833532416 https://twitter.com/sandofsky/status/1003104331833532416
myguysi 8y ago
Nope they posted a blog article[0] last week about their plans. Please check your facts first next time because there’s been nothing from Facebook to indicate that. [0] http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state...
bigsassy 8y ago
No, it's still being worked on. To quote their latest blog post: We're working on a large-scale rearchitecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps. http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018.html http://facebook.github.io/react-native/blog/2018/06/14/state...

dawhizkid 8y ago

I wrote a few weeks ago about how ridiculous it was for AirBnB to spend 18 months testing a new font. A 5 part series on React Native is again next-level indulgent. Why am I not surprised engineers at Airbnb have so little to do than to write a novel about a framework?

eugeniub 8y ago
Yeah nothing weirder than engineers writing about their experiences with different technologies.
- dawhizkid 8y ago
  A 5 part series. 5!!
jongold 8y ago
fwiw it wasn't 18 months "testing" a new font - most of that was font development with an external partner, then implementing across many surfaces without creating bugs that affected accessibility, then testing. doing things takes time, huge surprise right?

flamedoge 8y ago

tldr; https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a https://medium.com/airbnb-engineering/sunsetting-react-nativ...

ArtemTrityak 8y ago

It looks like if you have small team and you want to develop iOS / Android prototype fast RN is good choice. This case you're looking not for "best user-experience" but "okay user experience fast". But for big companies java/kotlin or/and Objective-C/swift native apps will be more efficient.