41 ms·

React Native at Instagram

589 points by martin_bigio 10y ago

kumarm 10y ago
I don't think ReactNative has a reason to exist other than Facebook wanting to own Platform (Which they might abandon just like Parse). Good Read: https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding_react_native/dd1wuzn/ https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding...
- iLoch 10y ago
  I think you might be confusing Facebook with Google. Ask any app developer that's used React Native or any web developer that's had to create a native app if it has a reason to exist. Facebook has hundreds or thousands of React developers that - before React Native - could only develop for web. Now they can move their web developers to their native apps almost seamlessly.
  - sidlls 10y ago
    And that's a good thing? I'm being serious here. The web ranks among the crappiest user experience I have with software I use today. And when I speak with colleagues who do the web development at the company I work for they seem far from happy with their development environments and process. It's like the presentation, in which MB of JavaScript are required to render a few paragraphs of text with a side bar or drop-down menu, went to the development environment where thousands of dependencies are required to produce "hello world." The last thing I want is to see yet more traveling down the path of "web app" style development for my phone's apps.
- bennyg 10y ago
  A lot of that commenter's points are really diatribes without fully understanding RN, or the 3rd party environment around it. The absolute biggest con with RN is performance. Redux and aggressive shouldComponentUpdates are your friends here. Airbnb's Lottie library (and FB's keyframes) can help with complex animations and the bad perf associated with those. The dev tradeoffs are 100% worth it. The end-product tradeoffs are 95% worth it. We've had to do some things in-house to circumvent some RN bugs, but that time spent there pales by multiple orders of magnitude in comparison to the time saved by starting a cross-platform app from scratch with RN.
artursapek 10y ago
I opened Instagram the other day and saw a grey error message show up across the top of the app... it said something about a React error. I didn't get to read it well because it quickly disappeared. I thought I was tripping. Good to know I wasn't.
- dcgoss 10y ago
  Same here. Something about a debug error.
  - pacomerh 10y ago
    That is the one thing that is difficult in React Native, getting rid of those debug errors. Sometimes they don't make enough sense to know what they are. But we google are way out of them. Sometimes they're related to a compatibility issues, and communication issues between Objective C and RN.
    - spicyj 10y ago
      I would not expect any of these error messages to show up in a production build unless it was misconfigured (which it unfortunately sounds like the Instagram build was based on these reports).
- deleted 10y ago
  [deleted]
thecopy 10y ago
I'm getting tired of having to allow scripts to even get to see the images. Why dont they use <img> tags?
- sosuke 10y ago
  Checking the source the class is "progressiveMedia js-progressiveMedia graf-image" so in essence they don't use <img> tags for control. They could add in <noscript><img/></noscript> though.
- mastazi 10y ago
  In addition, if you happen to have a slow connection, all you see is blurred blobs instead of pictures. I never experience that with proper img tags because, you know, most major browsers have been doing progressive loading (which works with basic img tags) since several years ago and it works very well in most cases. I don't see why the guys at Medium felt they needed to reinvent the wheel. I hate Medium's layout and since they allow custom domains it's becoming very hard to avoid Medium links at all.
- spicyj 10y ago
  I think this must be a property of Medium, the blogging platform/host.
- robjan 10y ago
  The file names are probably bound to some data object that comes back from a service call. Not saying that's a good thing.
- xyzzy4 10y ago
  There's a lot of software developers who like to over-engineer things. Some are probably working at Medium.
  - intoverflow2 10y ago
    At times I feel filling the building with just a few too many smart people can sometimes cause a regression on experience as things are over engineered and too many people struggle to find smarter solutions to solved problems. Take Google Maps for example, the old tile based version is blazing fast and uses almost no CPU. "Modern" version of Maps makes my MacBook Pro fans turn on almost straight away, chugs and chokes when dragging and although the zoom motion is clearer the actual data display isn't any better.
martin_bigio 10y ago
@martinbigio here in case anyone has questions
- arstaetro 10y ago
  Are you considering to build the camera part with react or keep it native cause react wont add the needed functionality?
  - martin_bigio 10y ago
    No plans for powering camera using React Native for now. We already have great native infra for that and regardless, IMHO RN might not be the best technology to implement those kind of immersive ultra-performant flows. We see space for React Native to grow inside of Instagram on flows similar to the ones mentioned on the blog post.
- javiercr 10y ago
  Did you guys use any other libraries from the React ecosystem to implement these features? (redux, normalizr, redux-saga, etc.) Also, what approach did you use for testing the RN flows? (unit testing, e2e testing, etc). BTW, thanks for sharing your experiences!
  - martin_bigio 10y ago
    No, we didn't use any of those. For unit testing we used Jest <3 and for e2e an internal library developed by FB
- htormey 10y ago
  Great article Martin. Do you have any performance figures or tips that you learned when porting the save feature? Specifically how was performance across Android/iOS?
  - martin_bigio 10y ago
    Great question. First off, worth mentioning there are many performance metrics you might want to measure. On one hand start up times, but since you specifically mentioned Save, I assume you want to learn more about scroll perf (i.e.: dropped frames, memory usage, time to render next pages, etc). We don't have numbers we can share but but the React Native team is working on further improving this. Check out Spencer's commit (https://github.com/facebook/react-native/commit/a3457486e39dc752799b1103ebe606224a8e8d32 https://github.com/facebook/react-native/commit/a3457486e39d...) for a sneak peek of what's coming up :).
40acres 10y ago
I didn't know what single/multi-dex means so i looked it up. Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and methods in your own code. Getting past this limit requires that you configure your app build process to generate more than one DEX file, known as a multidex configuration. Do Android apps regularly encompass over 65.3k methods? I assume a majority of these would be framework type functionality, but it really seems that a multi-dex product would be near impossible to maintain.
- aeturnum 10y ago
  Iirc, the reason you end up hitting the limit for 65k methods is that each library tends to keep independent copies of its dependencies. This simplifies dependency control, but ends up mushrooming quickly.
  - unsoundInput 10y ago
    That is actually not true. Afaik multiversioning of dependencies is not actually supported by build systems without manual effort (not counting major versions in non-conflicting namespaces). Problem is really more in fat libraries and "unnecessary" (getters, setters) and synthetic (e.g. access to private methods from inner classes) methods that are usually not optimized away, especially in debug builds.
    - ashark 10y ago
      I've definitely included a library and then seen (otherlibrary).(library you included) as an option in autocomplete, fairly often. Happens a lot with utility-level things like okhttp.
      - zcoyle 10y ago
        I've seen this with okhttp as well.
wmblaettler 10y ago
The careers link posted in the footnote errors when loading: https://our.intern.facebook.com/l.php?d=AQHtPpH_2FKp-3oVD3c57N8Xi13ihf6dqJh6FoNsgrYMTVn7YWz-VEHqIRY&u=https%3A%2F%2Fwww.instagram.com%2Fabout%2Fjobs%2F&h=8AQFXdAKr&s=1 https://our.intern.facebook.com/l.php?d=AQHtPpH_2FKp-3oVD3c5... "Sorry, something went wrong. We're working on it and we'll get it fixed as soon as we can." Based on the URL, is this actually some internal FB link tracking redirect? You probably simply want direct URL: https://www.instagram.com/about/jobs https://www.instagram.com/about/jobs
- martin_bigio 10y ago
  Oops, that was an internal link - fixing now.
a13n 10y ago
This is huge. 87-99% shared code between iOS and Android. Someday companies as big as Instagram won't need to have entire separate product teams for separate platforms. > React Native allowed product teams to ship features faster to both our iOS and Android apps. The list below shows the percentage of code shared between the apps for some of the products, which could be used as a proxy to measure how we managed to improve developer velocity: Post Promote: 99% SMS Captcha Checkpoint: 97% Comment Moderation: 85% Lead Gen Ads: 87% Push Notification Settings: 92%
- codazoda 10y ago
  I'm working on a project where we are recreating a native app using React Native. We've found similar results; about 90% of our code is shared between both platforms. We also build both platforms every time, so both apps match really well. I'm not sold on React yet but this is a major plus to the platform.
  - what2 10y ago
    That seems like a big plus for React Native. What are the negatives you have found?
    - htormey 10y ago
      I was at the SF React Native developers meet up the other night, the speaker (Devin Abbott) gave several nice pro/con's slide re react native. Here's a picture of the slides: http://imgur.com/a/T3O7i http://imgur.com/a/T3O7i http://imgur.com/a/z2oIU http://imgur.com/a/z2oIU
      - what2 10y ago
        Awesome, thanks! Right now I will wait a little more and see how the tech evolves. Been burned by too many miracle technologies
        htormey 10y ago
huangc10 10y ago
As an iOS developer, I had to decide between investing more time in Swift or React-Native. I chose React-Native simply because I thought it will allow me to broaden my mobile development experience and maybe one day stretch to even the Android platform. Furthermore, it improved my javascript skills in general and allowed me to create React web apps as well. I think it is the right choice thus far. Anyone else have similar experiences?
- scibbidy 10y ago
  I've had a similar experience. I have had to spend time learning both, I think I am just paranoid about job security! Moving from Objective-C to Swift felt a lot more natural than moving to React Native, getting used to Javascript and the web development environment in general is quite daunting. What were your deciding factors when making your decision?
  - huangc10 10y ago
    I think job security was one of my decisions too. Another important decision was the fact that I wanted to be able to use React for both web and mobile apps. Mastering JS was a big bonus. That being said, it's definitely a smart move to invest time in swift (I did play around with some swift libraries), as it does seem the industry "might" move towards some kind of hybrid obj-c and/or swift + React-native app. I've personally decided to invest more time in JS than Swift. Yes, the React syntax and JS in general also wasn't as easy for me to catch on vs. obj-c (I wrote a lot of C in my previous job). As you write more, you'll get use to it.
- RubenSandwich 10y ago
  As someone who was in your shoes last year as I made a job transition into a lead developer role at a new company. I picked React Native for a small project over Swift: https://studio.carnegiemuseums.org/out-loud-cdc979453ef0#.rh2rkrgsb https://studio.carnegiemuseums.org/out-loud-cdc979453ef0#.rh.... It was worth it. Not only because immutable render functions make view code extremely pleasurable to write, but also because it's mostly JS and JSX it allowed me to quickly spin up a web developer to work on this project with me. (About 2-3 weeks.) Now React Native is not without it's downsides though. You pretty much have to know the platform underneath if you want to do anything past API calls and rendering to a list view. (And even that list view does not support the heavy recycling that iOS manages for you.) For the above project I had to write our own Bluetooth, Audio and Accessibility Native Modules. But the speed at which we were able to develop over a native solution was worth it alone. I highly suggest looking into React Native if your next project is simple enough.
thebouv 10y ago
I really want to look at React Native, but every time I pull up my Facebook app on my iPhone 6, it can take upwards of 30 seconds before the interface is useable. That's on a very fast connection. So to me the FB app is so slow, it makes me hesitant to give React Native much more thought as you'd figure the FB app would be THE showcase app for it. Maybe I'm the only one?
- jroblak 10y ago
  Last I'd heard, the Facebook app was still native per platform and not using React.
- untog 10y ago
  I wouldn't say you are the only one, but upwards of 30 seconds is very slow - I don't know anyone seeing that kind of performance. Perhaps try reinstalling?
  - thebouv 10y ago
    I think I'll try that. Every time the lag happens I'm surprised by just how slow the app feels.
- dvcrn 10y ago
  Someone correct me if I'm wrong but AFAIK the Facebook app isn't really using react native yet, just in very small parts (event dashboard). The rest is still plain old swift and objc.
  - brentvatne 10y ago
    this is correct
  - dingdongding 10y ago
    They have added quite a few screens on react native now. They don't use Swift at all right now.
  - thebouv 10y ago
iamleppert 10y ago
They probably traded a really nice iOS codebase that had been maintained and improved upon for something that is going to end up with tons of special cases for when the UI is running on iOS/Android etc and make it incredibly difficult to test, reason about. Instead of improving the code on each respective platform, you end up with an inbred red-headed step child that shares the limitations and thorns of each, all smushed together. Now, making a change that once was once limited in scope to a single UI on Android now has the potential to affect both apps in new and exciting (read: unpredictable) ways. I've been down this path before. There's something incredibly satisfying about reusing code, but there's such a thing as too much of a good thing. I'd like to see a case study done in a few years once the whiskers have had some time to accumulate on this codebase. Steve Jobs knew about the perils of this development methodology which is why he specifically put his foot down on technologies like Flash -- which (let's admit it, folks), React Native really has more in common than we'd like to admit.
- taurath 10y ago
  As a business decision, it's outsourcing expertise of the platforms to Facebook, which has plenty of resourses working on the problem. True it's been the holy grail as long as I've been a web dev, but outside of a bit of platform lock in risk it seems like it's come a long way with relatively simple apps like Instagram. It's trading expense for risk.
  - iamleppert 10y ago
    Do you really think there's much expense to having two code bases for simple apps (as you said) like Instagram? If these apps are written properly most (all) of any custom logic is done server side and they are just presentational only. In addition, a good developer/engineer/team that's properly focused on mobile (the size of the team of Instagram) should have absolutely no problem supporting two native codebases.
    - taurath 10y ago
      Think of it as not 2, but 3 different languages. Say your backend is node - your JavaScript developers can all work across the stack. You can keep code standards more or less the same across the whole company.
redtree 10y ago
This is great news for Enterprises as well, as most have many internal apps that need to be built for different platforms.
LeoNatan25 10y ago
Please speak, if you can, on the mental toll the move to web ecosystem has taken on your native developers that have until now developed on respective native ecosystems. In particularly, I refer to having to work in JS, having to install tens if not hundreds if not thousands npm dependencies in order to do the most routine tasks, having to restart packager and clear cache every few runs, etc.
- martin_bigio 10y ago
  Packager has gotten pretty stable lately, you shouldn't need to restart it anymore. In regards npm modules, you only need to do so when upgrading dependencies which doesn't happen that often. We also use yarn, an npm client FB built from the ground up to removes some of the pain with npm's one: https://code.facebook.com/posts/1840075619545360 https://code.facebook.com/posts/1840075619545360
ClayFerguson 10y ago
The dirty little secret about React is that it tries to 'reinvent' the DOM tree, and Web Components will be out soon making it all obsolete. Why not just move to Web Components NOW, and not have to rewrite your view logic in 3 or 4 years. Polymer wins easily. React got a head start, sure, but the W3C standards and native browser support for WebComponents makes React redundant and unnecessary, in the very near future.
- CharlesW 10y ago
  > Why not just move to Web Components… This article is about React Native, not React.
  - ClayFerguson 10y ago
    React Native uses React. React is still in the core of it.
- ec109685 10y ago
  ReactNative doesn't even have the concept of a DOM, so how can that be its dirty secret?
  - LeoNatan25 10y ago
    React Native has the native view hierarchy as its DOM, and it also has a "shadow" view hierarchy, which is very similar to the concept of shadow DOM. https://github.com/facebook/react-native/blob/master/React/Views/RCTShadowView.h https://github.com/facebook/react-native/blob/master/React/V...
  - ClayFerguson 10y ago
    I don't know anything about ReactNative. Nor did I claim I did. I am simply stating that React itself is a dead-end technology. I would think no one would want to use ReactNative unless they buy into the prospect of React itself having a long life ahead. But doesn't. It's a dead end. WebComponents are the future and react will be unnecessary.
DenisM 10y ago
So I see they have a lot of code reuse between RN iOS and RN Android. How much, if any, code reuse can there be between React Native and React (proper)?
- martin_bigio 10y ago
  Great Q. React and React Native use difference "renderers". I believe that with the right pattern to use a different set of low level components you could manage to reuse a big chunk, but this isn't something we have tried so I'm not that sure.
- weixiyen 10y ago
  You can't re-use the UI portion but all the business logic, API calls, stores, socket connections, etc... For Sleeperbot it's 50% code-sharing between desktop / mobile, and then 95% between iOS & Android.
  - DenisM 10y ago
    Thank you!
DenisM 10y ago
One thing that draws me to RN is over-the-air code updates on iOS. Are there any other ways of achieving the same result?
dvcrn 10y ago
I love react native but only in combination with clojurescript as javascript replacement. Speaking of high-performance, is anyone here who has some insights how performance would change when swapping JS with cljs?
ryandrake 10y ago
Call me old-fashioned, but I thought the Android/iOS code sharing nut was cracked: Business logic in C or C++ and UI in Objective-C (iOS) and Java (Android + NDK). As a bonus, you could bolt a desktop UI on top of the C++ as well.
- realharo 10y ago
  It's certainly possible, but comes with a large number of its own issues: - C++ is a way more complicated language with the manual memory management. C is way too low level for things like this. - Complicated builds if you need to use a bunch of C++ libraries as dependencies. - Much slower iteration. - Complicated debugging. - The need to either write (slow) or generate (constraining) the Java/ObjC bindings. Then there are things like having to reconcile the lifetime of your C++ objects with the Android Activity/Fragment lifecycles, etc. If I was faced with the decision of what technology to use for a set of typical mobile apps, I would definitely want to avoid the native C++ path if at all possible.
  - LeoNatan25 10y ago
    With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary. Debugging is only complicated on Android, where NDK is pain in the ass for some reason, even after so many years of Google developing the toolchain.
    - realharo 10y ago
      >With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary Not completely though, you still have to think a lot more about ownership and object lifetimes (https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE), which is a lot better than manual new/delete, but still not as simple as just having a GC. Plus you have to deal with lifetimes of objects proxied to Java code, where something in the Java code becomes the object's owner. Though you can use a bindings generator like djinni (https://github.com/dropbox/djinni https://github.com/dropbox/djinni) to handle this for you (with some tradeoffs). >Debugging is only complicated on Android It's gotten slightly better recently, but it still sucks. With Swift it's not trivial either, it's not that easy to set breakpoints into C++ code, stack traces on crashes are often not helpful (so any unhandled C++ exception that you didn't catch and convert into a Swift error is hard to track down, etc.)
Shooogur 10y ago
Very cool!
jakebasile 10y ago
React and React Native are pretty great pieces of tech, hopefully the ClojureScript story for them continues to improve. When I need to make a mobile app again I can't think of a reason I'd write it in Java/Swift.
- raspasov 10y ago
  The story is already quite good (having shipped a production app myself and maintained it for 6+ months). Checkout re-natal for a good template to start.
  - jakebasile 10y ago
    I had found that earlier, I wasn't sure if it was ready enough for production use. Glad to hear it worked for you!
therealmarv 10y ago
Great engineering. Instagram always runs snappy and also with low bandwidth (>1Mbit/s). Meanwhile Snapchat does not even know how to download first clicked story video first.
- dingdongding 10y ago
  Though Instagram stories are pretty slow to load.
ryancouto 10y ago
Did this change occur recently? I've noticed in the past 3-4 months Instagram has become a lot slower. To be fair, it's started to gain some speed in the past month, but I'd be interested to see how this increase in latency coincided with the migration to React Native.
- spicyj 10y ago
  When teams at Facebook roll out features or rewrites like this, they almost always monitor performance metrics so I'm comfortable claiming that React Native is unlikely to be responsible for slowness you've seen recently.
greenyouse 10y ago
I'm curious what you guys think of PWAs vs React Native? Is there a clear advantages of one over the other?
lewisl9029 10y ago
Has anyone tried using the React Native plugin for Windows [1] in a non-trivial app yet? I'd love to hear what experiences people have had with it, and if there's anything to watch out for coming from the RN Android/iOS camps. Any open source apps that makes use of React Native for Windows that you can point me to would be super helpful as well. [1] https://github.com/ReactWindows/react-native-windows https://github.com/ReactWindows/react-native-windows
- mnkypete 10y ago
  I mean, the Instagram App is also available on Windows, with almost all features as the iOS/Android counterparts. So I'm not sure, maybe they are already using that as well?
gigatexal 10y ago
This is probably stupid but does react native compile down to the running environment? Code in react and then build/compile against iOS SDKs?
- martin_bigio 10y ago
  JS code run on JSC, bridge modules are implemented on objc/java
jz10 10y ago
For my fellow vue.js enthusiasts, check out https://github.com/alibaba/weex https://github.com/alibaba/weex for compiling "vue-like" syntax to native apps
SilverWhiskey 10y ago
Argh, now I see why I can't change anything on the Push Notifications settings page. Nice experiment, Instagram, but could you please fix it and let me disable all notifications within the app, not iphone settings?
- martin_bigio 10y ago
  what's the problem? If it's a generic error message that's s server-side issue unrelated to RN the team is working on fixing.
intoverflow2 10y ago
This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been. Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance? Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft just to draw a few text boxes of a profile edit screen or a grid of photos (something I would have thought would be effortless to mobile devs in 2017). Rather than the handful of devs having a slightly easier day at the start of the process. This whole move seems especially strange to me coming from a Facebook company, have we forgotten the move from native > webtech > native already?
- a-saleh 10y ago
  I think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.
  - a13n 10y ago
    Especially as chips get faster, teams can afford opting towards a better developer experience to move faster and retain happier engineers. It isn't only developer experience, also developer velocity. That was the whole motivation behind React Native in the first place.
    - LeoNatan25 10y ago
      From my experience, any native developers that work with React Native have a mental toll from having to adapt to what seems like unnatural technologies from the native side. Add on top of that the terrible web ecosystem, terrible JS base library (and, perhaps, the language itself), the lack of IDE (not code editors), the debugging experience, the packager performance, and it's just not a good experience for people who have worked in better developer environments, such as Android Studio, Visual Studio and Xcode. The only people really happy, from my experience, are web developers who are already familiar with this technology and ecosystem.
joe_momma 10y ago
React Native is becoming the Wordpress of mobile apps.
- kgin 10y ago
  Not sure that's the best analogy.
  - joe_momma 10y ago
    Not sure you get it...
antoniuschan99 10y ago
My project (the weather sensor) is using React Native for the Mobile end. I would still like to work on a professional project to really see how well or bad RN is in an enterprise type project. Having used Titanium Appcelerator on a personal project, I find RN much better than Titanium. I assume it's much better than Xamarin as well. I think learning RN is a good bet because, it is coming from Facebook. I'm not sure if people remember, but FB on mobile was originally built using Webviews and had notoriously bad reviews because it was slow and laggy. It's because of this lesson that they are in a good position to create a competent platform. I also think as web developers, we should try to understand more of the tooling/language in one of the mobile platforms of our choice.
beeswax 10y ago
Thanks for sharing! I'm currently leading the (soft) transition of a two-platform, not-so-much-shared-code code base (ObjC, Java, Swift, C++) to React Native. We hit some snags early on (mostly wrt tooling; also prepare to alter your mind set) but as the article states RN yields an astonishing amount of code reuse between platforms as well as heavily reduced turnaround times. It’s way too early for conclusions/doing a post mortem for our project at this time. Nonetheless I’d say we’re able to iterate faster by an order of magnitude and the added value of discussing features and domain logic/behavior for both platforms at the same time while enabling UX/UI to get results/feedback faster is a huge win. That said, I’m really looking forward to the challenges that lie ahead (i18n, RTL quirks, proper unit/feature/integration testing scenarios, non-trivial native bridging, …)

589 points by martin_bigio 10y ago

I don't think ReactNative has a reason to exist other than Facebook wanting to own Platform (Which they might abandon just like Parse). Good Read: https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding_react_native/dd1wuzn/ https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding...

iLoch 10y ago
I think you might be confusing Facebook with Google. Ask any app developer that's used React Native or any web developer that's had to create a native app if it has a reason to exist. Facebook has hundreds or thousands of React developers that - before React Native - could only develop for web. Now they can move their web developers to their native apps almost seamlessly.
- sidlls 10y ago
  And that's a good thing? I'm being serious here. The web ranks among the crappiest user experience I have with software I use today. And when I speak with colleagues who do the web development at the company I work for they seem far from happy with their development environments and process. It's like the presentation, in which MB of JavaScript are required to render a few paragraphs of text with a side bar or drop-down menu, went to the development environment where thousands of dependencies are required to produce "hello world." The last thing I want is to see yet more traveling down the path of "web app" style development for my phone's apps.
bennyg 10y ago
A lot of that commenter's points are really diatribes without fully understanding RN, or the 3rd party environment around it. The absolute biggest con with RN is performance. Redux and aggressive shouldComponentUpdates are your friends here. Airbnb's Lottie library (and FB's keyframes) can help with complex animations and the bad perf associated with those. The dev tradeoffs are 100% worth it. The end-product tradeoffs are 95% worth it. We've had to do some things in-house to circumvent some RN bugs, but that time spent there pales by multiple orders of magnitude in comparison to the time saved by starting a cross-platform app from scratch with RN.

artursapek 10y ago

I opened Instagram the other day and saw a grey error message show up across the top of the app... it said something about a React error. I didn't get to read it well because it quickly disappeared. I thought I was tripping. Good to know I wasn't.

dcgoss 10y ago
Same here. Something about a debug error.
- pacomerh 10y ago
  That is the one thing that is difficult in React Native, getting rid of those debug errors. Sometimes they don't make enough sense to know what they are. But we google are way out of them. Sometimes they're related to a compatibility issues, and communication issues between Objective C and RN.
  - spicyj 10y ago
    I would not expect any of these error messages to show up in a production build unless it was misconfigured (which it unfortunately sounds like the Instagram build was based on these reports).
deleted 10y ago
[deleted]

thecopy 10y ago

I'm getting tired of having to allow scripts to even get to see the images. Why dont they use <img> tags?

sosuke 10y ago
Checking the source the class is "progressiveMedia js-progressiveMedia graf-image" so in essence they don't use <img> tags for control. They could add in <noscript><img/></noscript> though.
mastazi 10y ago
In addition, if you happen to have a slow connection, all you see is blurred blobs instead of pictures. I never experience that with proper img tags because, you know, most major browsers have been doing progressive loading (which works with basic img tags) since several years ago and it works very well in most cases. I don't see why the guys at Medium felt they needed to reinvent the wheel. I hate Medium's layout and since they allow custom domains it's becoming very hard to avoid Medium links at all.
spicyj 10y ago
I think this must be a property of Medium, the blogging platform/host.
robjan 10y ago
The file names are probably bound to some data object that comes back from a service call. Not saying that's a good thing.
xyzzy4 10y ago
There's a lot of software developers who like to over-engineer things. Some are probably working at Medium.
- intoverflow2 10y ago
  At times I feel filling the building with just a few too many smart people can sometimes cause a regression on experience as things are over engineered and too many people struggle to find smarter solutions to solved problems. Take Google Maps for example, the old tile based version is blazing fast and uses almost no CPU. "Modern" version of Maps makes my MacBook Pro fans turn on almost straight away, chugs and chokes when dragging and although the zoom motion is clearer the actual data display isn't any better.

martin_bigio 10y ago

@martinbigio here in case anyone has questions

arstaetro 10y ago
Are you considering to build the camera part with react or keep it native cause react wont add the needed functionality?
- martin_bigio 10y ago
  No plans for powering camera using React Native for now. We already have great native infra for that and regardless, IMHO RN might not be the best technology to implement those kind of immersive ultra-performant flows. We see space for React Native to grow inside of Instagram on flows similar to the ones mentioned on the blog post.
javiercr 10y ago
Did you guys use any other libraries from the React ecosystem to implement these features? (redux, normalizr, redux-saga, etc.) Also, what approach did you use for testing the RN flows? (unit testing, e2e testing, etc). BTW, thanks for sharing your experiences!
- martin_bigio 10y ago
  No, we didn't use any of those. For unit testing we used Jest <3 and for e2e an internal library developed by FB
htormey 10y ago
Great article Martin. Do you have any performance figures or tips that you learned when porting the save feature? Specifically how was performance across Android/iOS?
- martin_bigio 10y ago
  Great question. First off, worth mentioning there are many performance metrics you might want to measure. On one hand start up times, but since you specifically mentioned Save, I assume you want to learn more about scroll perf (i.e.: dropped frames, memory usage, time to render next pages, etc). We don't have numbers we can share but but the React Native team is working on further improving this. Check out Spencer's commit (https://github.com/facebook/react-native/commit/a3457486e39dc752799b1103ebe606224a8e8d32 https://github.com/facebook/react-native/commit/a3457486e39d...) for a sneak peek of what's coming up :).

40acres 10y ago

I didn't know what single/multi-dex means so i looked it up. Android application (APK) files contain executable bytecode files in the form of Dalvik Executable (DEX) files, which contain the compiled code used to run your app. The Dalvik Executable specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and methods in your own code. Getting past this limit requires that you configure your app build process to generate more than one DEX file, known as a multidex configuration. Do Android apps regularly encompass over 65.3k methods? I assume a majority of these would be framework type functionality, but it really seems that a multi-dex product would be near impossible to maintain.

aeturnum 10y ago
Iirc, the reason you end up hitting the limit for 65k methods is that each library tends to keep independent copies of its dependencies. This simplifies dependency control, but ends up mushrooming quickly.
- unsoundInput 10y ago
  That is actually not true. Afaik multiversioning of dependencies is not actually supported by build systems without manual effort (not counting major versions in non-conflicting namespaces). Problem is really more in fat libraries and "unnecessary" (getters, setters) and synthetic (e.g. access to private methods from inner classes) methods that are usually not optimized away, especially in debug builds.
  - ashark 10y ago
    I've definitely included a library and then seen (otherlibrary).(library you included) as an option in autocomplete, fairly often. Happens a lot with utility-level things like okhttp.
    - zcoyle 10y ago
      I've seen this with okhttp as well.

wmblaettler 10y ago

The careers link posted in the footnote errors when loading: https://our.intern.facebook.com/l.php?d=AQHtPpH_2FKp-3oVD3c57N8Xi13ihf6dqJh6FoNsgrYMTVn7YWz-VEHqIRY&u=https%3A%2F%2Fwww.instagram.com%2Fabout%2Fjobs%2F&h=8AQFXdAKr&s=1 https://our.intern.facebook.com/l.php?d=AQHtPpH_2FKp-3oVD3c5... "Sorry, something went wrong. We're working on it and we'll get it fixed as soon as we can." Based on the URL, is this actually some internal FB link tracking redirect? You probably simply want direct URL: https://www.instagram.com/about/jobs https://www.instagram.com/about/jobs

martin_bigio 10y ago
Oops, that was an internal link - fixing now.

a13n 10y ago

This is huge. 87-99% shared code between iOS and Android. Someday companies as big as Instagram won't need to have entire separate product teams for separate platforms. > React Native allowed product teams to ship features faster to both our iOS and Android apps. The list below shows the percentage of code shared between the apps for some of the products, which could be used as a proxy to measure how we managed to improve developer velocity: Post Promote: 99% SMS Captcha Checkpoint: 97% Comment Moderation: 85% Lead Gen Ads: 87% Push Notification Settings: 92%

codazoda 10y ago
I'm working on a project where we are recreating a native app using React Native. We've found similar results; about 90% of our code is shared between both platforms. We also build both platforms every time, so both apps match really well. I'm not sold on React yet but this is a major plus to the platform.
- what2 10y ago
  That seems like a big plus for React Native. What are the negatives you have found?
  - htormey 10y ago
    I was at the SF React Native developers meet up the other night, the speaker (Devin Abbott) gave several nice pro/con's slide re react native. Here's a picture of the slides: http://imgur.com/a/T3O7i http://imgur.com/a/T3O7i http://imgur.com/a/z2oIU http://imgur.com/a/z2oIU
    - what2 10y ago
      Awesome, thanks! Right now I will wait a little more and see how the tech evolves. Been burned by too many miracle technologies
      - htormey 10y ago

huangc10 10y ago

As an iOS developer, I had to decide between investing more time in Swift or React-Native. I chose React-Native simply because I thought it will allow me to broaden my mobile development experience and maybe one day stretch to even the Android platform. Furthermore, it improved my javascript skills in general and allowed me to create React web apps as well. I think it is the right choice thus far. Anyone else have similar experiences?

scibbidy 10y ago
I've had a similar experience. I have had to spend time learning both, I think I am just paranoid about job security! Moving from Objective-C to Swift felt a lot more natural than moving to React Native, getting used to Javascript and the web development environment in general is quite daunting. What were your deciding factors when making your decision?
- huangc10 10y ago
  I think job security was one of my decisions too. Another important decision was the fact that I wanted to be able to use React for both web and mobile apps. Mastering JS was a big bonus. That being said, it's definitely a smart move to invest time in swift (I did play around with some swift libraries), as it does seem the industry "might" move towards some kind of hybrid obj-c and/or swift + React-native app. I've personally decided to invest more time in JS than Swift. Yes, the React syntax and JS in general also wasn't as easy for me to catch on vs. obj-c (I wrote a lot of C in my previous job). As you write more, you'll get use to it.
RubenSandwich 10y ago
As someone who was in your shoes last year as I made a job transition into a lead developer role at a new company. I picked React Native for a small project over Swift: https://studio.carnegiemuseums.org/out-loud-cdc979453ef0#.rh2rkrgsb https://studio.carnegiemuseums.org/out-loud-cdc979453ef0#.rh.... It was worth it. Not only because immutable render functions make view code extremely pleasurable to write, but also because it's mostly JS and JSX it allowed me to quickly spin up a web developer to work on this project with me. (About 2-3 weeks.) Now React Native is not without it's downsides though. You pretty much have to know the platform underneath if you want to do anything past API calls and rendering to a list view. (And even that list view does not support the heavy recycling that iOS manages for you.) For the above project I had to write our own Bluetooth, Audio and Accessibility Native Modules. But the speed at which we were able to develop over a native solution was worth it alone. I highly suggest looking into React Native if your next project is simple enough.

thebouv 10y ago

I really want to look at React Native, but every time I pull up my Facebook app on my iPhone 6, it can take upwards of 30 seconds before the interface is useable. That's on a very fast connection. So to me the FB app is so slow, it makes me hesitant to give React Native much more thought as you'd figure the FB app would be THE showcase app for it. Maybe I'm the only one?

jroblak 10y ago
Last I'd heard, the Facebook app was still native per platform and not using React.
untog 10y ago
I wouldn't say you are the only one, but upwards of 30 seconds is very slow - I don't know anyone seeing that kind of performance. Perhaps try reinstalling?
- thebouv 10y ago
  I think I'll try that. Every time the lag happens I'm surprised by just how slow the app feels.
dvcrn 10y ago
Someone correct me if I'm wrong but AFAIK the Facebook app isn't really using react native yet, just in very small parts (event dashboard). The rest is still plain old swift and objc.
- brentvatne 10y ago
  this is correct
- dingdongding 10y ago
  They have added quite a few screens on react native now. They don't use Swift at all right now.
- thebouv 10y ago

iamleppert 10y ago

They probably traded a really nice iOS codebase that had been maintained and improved upon for something that is going to end up with tons of special cases for when the UI is running on iOS/Android etc and make it incredibly difficult to test, reason about. Instead of improving the code on each respective platform, you end up with an inbred red-headed step child that shares the limitations and thorns of each, all smushed together. Now, making a change that once was once limited in scope to a single UI on Android now has the potential to affect both apps in new and exciting (read: unpredictable) ways. I've been down this path before. There's something incredibly satisfying about reusing code, but there's such a thing as too much of a good thing. I'd like to see a case study done in a few years once the whiskers have had some time to accumulate on this codebase. Steve Jobs knew about the perils of this development methodology which is why he specifically put his foot down on technologies like Flash -- which (let's admit it, folks), React Native really has more in common than we'd like to admit.

taurath 10y ago
As a business decision, it's outsourcing expertise of the platforms to Facebook, which has plenty of resourses working on the problem. True it's been the holy grail as long as I've been a web dev, but outside of a bit of platform lock in risk it seems like it's come a long way with relatively simple apps like Instagram. It's trading expense for risk.
- iamleppert 10y ago
  Do you really think there's much expense to having two code bases for simple apps (as you said) like Instagram? If these apps are written properly most (all) of any custom logic is done server side and they are just presentational only. In addition, a good developer/engineer/team that's properly focused on mobile (the size of the team of Instagram) should have absolutely no problem supporting two native codebases.
  - taurath 10y ago
    Think of it as not 2, but 3 different languages. Say your backend is node - your JavaScript developers can all work across the stack. You can keep code standards more or less the same across the whole company.

redtree 10y ago

This is great news for Enterprises as well, as most have many internal apps that need to be built for different platforms.

LeoNatan25 10y ago

Please speak, if you can, on the mental toll the move to web ecosystem has taken on your native developers that have until now developed on respective native ecosystems. In particularly, I refer to having to work in JS, having to install tens if not hundreds if not thousands npm dependencies in order to do the most routine tasks, having to restart packager and clear cache every few runs, etc.

martin_bigio 10y ago
Packager has gotten pretty stable lately, you shouldn't need to restart it anymore. In regards npm modules, you only need to do so when upgrading dependencies which doesn't happen that often. We also use yarn, an npm client FB built from the ground up to removes some of the pain with npm's one: https://code.facebook.com/posts/1840075619545360 https://code.facebook.com/posts/1840075619545360

ClayFerguson 10y ago

The dirty little secret about React is that it tries to 'reinvent' the DOM tree, and Web Components will be out soon making it all obsolete. Why not just move to Web Components NOW, and not have to rewrite your view logic in 3 or 4 years. Polymer wins easily. React got a head start, sure, but the W3C standards and native browser support for WebComponents makes React redundant and unnecessary, in the very near future.

CharlesW 10y ago
> Why not just move to Web Components… This article is about React Native, not React.
- ClayFerguson 10y ago
  React Native uses React. React is still in the core of it.
ec109685 10y ago
ReactNative doesn't even have the concept of a DOM, so how can that be its dirty secret?
- LeoNatan25 10y ago
  React Native has the native view hierarchy as its DOM, and it also has a "shadow" view hierarchy, which is very similar to the concept of shadow DOM. https://github.com/facebook/react-native/blob/master/React/Views/RCTShadowView.h https://github.com/facebook/react-native/blob/master/React/V...
- ClayFerguson 10y ago
  I don't know anything about ReactNative. Nor did I claim I did. I am simply stating that React itself is a dead-end technology. I would think no one would want to use ReactNative unless they buy into the prospect of React itself having a long life ahead. But doesn't. It's a dead end. WebComponents are the future and react will be unnecessary.

DenisM 10y ago

So I see they have a lot of code reuse between RN iOS and RN Android. How much, if any, code reuse can there be between React Native and React (proper)?

martin_bigio 10y ago
Great Q. React and React Native use difference "renderers". I believe that with the right pattern to use a different set of low level components you could manage to reuse a big chunk, but this isn't something we have tried so I'm not that sure.
weixiyen 10y ago
You can't re-use the UI portion but all the business logic, API calls, stores, socket connections, etc... For Sleeperbot it's 50% code-sharing between desktop / mobile, and then 95% between iOS & Android.
- DenisM 10y ago
  Thank you!

DenisM 10y ago

One thing that draws me to RN is over-the-air code updates on iOS. Are there any other ways of achieving the same result?

dvcrn 10y ago

I love react native but only in combination with clojurescript as javascript replacement. Speaking of high-performance, is anyone here who has some insights how performance would change when swapping JS with cljs?

ryandrake 10y ago

Call me old-fashioned, but I thought the Android/iOS code sharing nut was cracked: Business logic in C or C++ and UI in Objective-C (iOS) and Java (Android + NDK). As a bonus, you could bolt a desktop UI on top of the C++ as well.

realharo 10y ago
It's certainly possible, but comes with a large number of its own issues: - C++ is a way more complicated language with the manual memory management. C is way too low level for things like this. - Complicated builds if you need to use a bunch of C++ libraries as dependencies. - Much slower iteration. - Complicated debugging. - The need to either write (slow) or generate (constraining) the Java/ObjC bindings. Then there are things like having to reconcile the lifetime of your C++ objects with the Android Activity/Fragment lifecycles, etc. If I was faced with the decision of what technology to use for a set of typical mobile apps, I would definitely want to avoid the native C++ path if at all possible.
- LeoNatan25 10y ago
  With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary. Debugging is only complicated on Android, where NDK is pain in the ass for some reason, even after so many years of Google developing the toolchain.
  - realharo 10y ago
    >With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary Not completely though, you still have to think a lot more about ownership and object lifetimes (https://www.youtube.com/watch?v=JfmTagWcqoE https://www.youtube.com/watch?v=JfmTagWcqoE), which is a lot better than manual new/delete, but still not as simple as just having a GC. Plus you have to deal with lifetimes of objects proxied to Java code, where something in the Java code becomes the object's owner. Though you can use a bindings generator like djinni (https://github.com/dropbox/djinni https://github.com/dropbox/djinni) to handle this for you (with some tradeoffs). >Debugging is only complicated on Android It's gotten slightly better recently, but it still sucks. With Swift it's not trivial either, it's not that easy to set breakpoints into C++ code, stack traces on crashes are often not helpful (so any unhandled C++ exception that you didn't catch and convert into a Swift error is hard to track down, etc.)

Shooogur 10y ago

Very cool!

jakebasile 10y ago

React and React Native are pretty great pieces of tech, hopefully the ClojureScript story for them continues to improve. When I need to make a mobile app again I can't think of a reason I'd write it in Java/Swift.

raspasov 10y ago
The story is already quite good (having shipped a production app myself and maintained it for 6+ months). Checkout re-natal for a good template to start.
- jakebasile 10y ago
  I had found that earlier, I wasn't sure if it was ready enough for production use. Glad to hear it worked for you!

therealmarv 10y ago

Great engineering. Instagram always runs snappy and also with low bandwidth (>1Mbit/s). Meanwhile Snapchat does not even know how to download first clicked story video first.

dingdongding 10y ago
Though Instagram stories are pretty slow to load.

ryancouto 10y ago

Did this change occur recently? I've noticed in the past 3-4 months Instagram has become a lot slower. To be fair, it's started to gain some speed in the past month, but I'd be interested to see how this increase in latency coincided with the migration to React Native.

spicyj 10y ago
When teams at Facebook roll out features or rewrites like this, they almost always monitor performance metrics so I'm comfortable claiming that React Native is unlikely to be responsible for slowness you've seen recently.

greenyouse 10y ago

I'm curious what you guys think of PWAs vs React Native? Is there a clear advantages of one over the other?

lewisl9029 10y ago

Has anyone tried using the React Native plugin for Windows [1] in a non-trivial app yet? I'd love to hear what experiences people have had with it, and if there's anything to watch out for coming from the RN Android/iOS camps. Any open source apps that makes use of React Native for Windows that you can point me to would be super helpful as well. [1] https://github.com/ReactWindows/react-native-windows https://github.com/ReactWindows/react-native-windows

mnkypete 10y ago
I mean, the Instagram App is also available on Windows, with almost all features as the iOS/Android counterparts. So I'm not sure, maybe they are already using that as well?

gigatexal 10y ago

This is probably stupid but does react native compile down to the running environment? Code in react and then build/compile against iOS SDKs?

martin_bigio 10y ago
JS code run on JSC, bridge modules are implemented on objc/java

jz10 10y ago

For my fellow vue.js enthusiasts, check out https://github.com/alibaba/weex https://github.com/alibaba/weex for compiling "vue-like" syntax to native apps

SilverWhiskey 10y ago

Argh, now I see why I can't change anything on the Push Notifications settings page. Nice experiment, Instagram, but could you please fix it and let me disable all notifications within the app, not iphone settings?

martin_bigio 10y ago
what's the problem? If it's a generic error message that's s server-side issue unrelated to RN the team is working on fixing.

intoverflow2 10y ago

This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been. Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance? Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft just to draw a few text boxes of a profile edit screen or a grid of photos (something I would have thought would be effortless to mobile devs in 2017). Rather than the handful of devs having a slightly easier day at the start of the process. This whole move seems especially strange to me coming from a Facebook company, have we forgotten the move from native > webtech > native already?

a-saleh 10y ago
I think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.
- a13n 10y ago
  Especially as chips get faster, teams can afford opting towards a better developer experience to move faster and retain happier engineers. It isn't only developer experience, also developer velocity. That was the whole motivation behind React Native in the first place.
  - LeoNatan25 10y ago
    From my experience, any native developers that work with React Native have a mental toll from having to adapt to what seems like unnatural technologies from the native side. Add on top of that the terrible web ecosystem, terrible JS base library (and, perhaps, the language itself), the lack of IDE (not code editors), the debugging experience, the packager performance, and it's just not a good experience for people who have worked in better developer environments, such as Android Studio, Visual Studio and Xcode. The only people really happy, from my experience, are web developers who are already familiar with this technology and ecosystem.

joe_momma 10y ago

React Native is becoming the Wordpress of mobile apps.

kgin 10y ago
Not sure that's the best analogy.
- joe_momma 10y ago
  Not sure you get it...

antoniuschan99 10y ago

My project (the weather sensor) is using React Native for the Mobile end. I would still like to work on a professional project to really see how well or bad RN is in an enterprise type project. Having used Titanium Appcelerator on a personal project, I find RN much better than Titanium. I assume it's much better than Xamarin as well. I think learning RN is a good bet because, it is coming from Facebook. I'm not sure if people remember, but FB on mobile was originally built using Webviews and had notoriously bad reviews because it was slow and laggy. It's because of this lesson that they are in a good position to create a competent platform. I also think as web developers, we should try to understand more of the tooling/language in one of the mobile platforms of our choice.

beeswax 10y ago

Thanks for sharing! I'm currently leading the (soft) transition of a two-platform, not-so-much-shared-code code base (ObjC, Java, Swift, C++) to React Native. We hit some snags early on (mostly wrt tooling; also prepare to alter your mind set) but as the article states RN yields an astonishing amount of code reuse between platforms as well as heavily reduced turnaround times. It’s way too early for conclusions/doing a post mortem for our project at this time. Nonetheless I’d say we’re able to iterate faster by an order of magnitude and the added value of discussing features and domain logic/behavior for both platforms at the same time while enabling UX/UI to get results/feedback faster is a huge win. That said, I’m really looking forward to the challenges that lie ahead (i18n, RTL quirks, proper unit/feature/integration testing scenarios, non-trivial native bridging, …)