React Native at Instagram
engineering.instagram.com
engineering.instagram.com
> 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%
What are the negatives you have found?
Right now I will wait a little more and see how the tech evolves. Been burned by too many miracle technologies
-- Slide 1 --
Maybe we should use React Native:
- We know JS / React
- We have lots of web developers but few mobile
- Our design is brand-focused
- We're willing to invest in RN
- We want to get into OSS
- We want OTA code updates
Or maybe we shouldn't:
- We don't know JS / React
- We already have an iOS team and an Android team
- Our designs are heavily platform-specific
- We don't have the time or money for an RN team / OSS
-- Slide 2 --
Pros:
- Cross-platform
- Performant, native feel (with some effort)
- Great developer experience
- Push updates over-the-air
- Strong community
- Backed by Facebook
Cons:
- Early
- Unstable (bugs, APIs)
- Ecosystem not fully developed
- Polished apps are high effort
- You may need native code (so JS + Obj-C + Java)
The thing that captured my interest was the point about being backed by Facebook. Parse was backed by Facebook and look where it is now.
Parse was an acquisition by Facebook that didn't end up working out.
Also, every library (addon/plugin/whatever) I've tried to use so far has not been even close to up to date with the current version of RN.
Error messages are beyond cryptic.
I'm sticking with it for now, but compared to traditional web dev, it feels like coding in quicksand.
To me it's actually one of the strongest points of RN. It's not trying to shun away the build/custom native wrapper part in favor of a magical solution; instead, it's giving you full control and full power on how you want things done.
Things like Cordova have been easy and great for simple stuff, but anything that is a little bit different or needs real performance is impossible or extremely problematic to achieve. Not on RN. It can be difficult, as creating a custom native UI requires a lot of knowledge of both native platforms, and a lot of boilerplate. But the end result is superior in every way to what HTML wrappers can do.
Rather than RN being a solution of one-size-fits-all like what some platforms want to be, I look at it from another angle: it still requires native mobile devs with native knowledge, but offloads 90% of the UI/business logic effort to this one universal platform. That's what most no-compromise cross-platform apps need.
In my particular case, being a solo dev with web background, RN is the only sane option to make an app in Android and iOS in reasonable time.
I'd say it can be a good tech choice, if you plan to focus your work on platforms that React API and ecosystem touch (mobile and web, maybe not desktop).
EDIT: Some grammar cleanup and the bit about styling.
Areas where we diverged were things like permissions on Android versus iOS, code that has to run in the background while the app is not foregrounded, material design stuff.
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?
Take it from a former UIKit author: https://twitter.com/andy_matuschak/status/560511204867575808
I'd love to see some testing here. Are we talking fractions of a percent or something like 20% more battery drain? If its fractions I am willing to bet most people would pick an easier life (assuming JS is their definition of easier).
> have we forgotten the move from native > webtech > native
I doubt many have, especially Facebook themselves. What a large cost that must have been for them. To have failed that and be willing to risk doing it all over again with native > "webtech2.0" must say something.
I think the goal here is to target both iOS and Android with just one codebase.
But I also happen to hate this trend, and I see it on Windows too. It seems like companies stopped creating native, good-looking and performant GUI applications built on .NET (or on Win32 which I still would find acceptable), and instead opted for uglier and less performant applications running on some javascript or node.js framework, because those will also run elsewhere.
I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively.
This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time from concept (e.g. Photoshop mock) to implementation (interactive working app) so that iteration can happen quickly.
As much as I love the performance possible when coding directly against Native APIs, I also have direct experience using web views in native apps. The improvement in the design process around web views is worth investing in getting the performance as close as possible to native. This is multiplied when you consider the cross-platform benefits. However, the performance and UI experience of web views is not good enough.
I can't vouch for React Native giving the iterative benefits of pure web view development nor the performance benefits of pure native development. However, if it does strike a reasonable balance between them I can totally understand why people invest in it.
I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations smooth, infinite tiled scrolling). Very rarely was raw CPU processing a major concern. My experience may not be typical.
As for other cross platform native development libraries/platforms/etc. - I've had some experience with a few of them (e.g. marmalade[0] which was in C++) and generally they do not work for me. I even attempted to write my own and it was its own monster.
In general, I am personally biased towards Native. I would definitely take RN on a test spin if I was in the prototype phase of a new app. I would use that time to determine if I wanted to bring RN into production or re-write as Native.
" Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex,"
React Native is not based on WebViews/HTML. It uses a virtual DOM on top of native views:
https://facebook.github.io/react/docs/optimizing-performance...
"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."
This is quite different from similar Javascript based efforts such as Cordova.
http://stackoverflow.com/questions/33479180/what-does-react-...
"React Native uses a JavaScript runtime, but the UI is not HTML and it doesn't use a WebView. You use JSX and React Native specific components to define the UI."
Some notes on React's virtual DOM concept:
https://facebook.github.io/react/docs/optimizing-performance...
"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."
This is an important point to note as a lot of the problems associated with hybrid apps in the past come down to them being based on WebViews.
> I think that is willfully missing the point.
How is GP missing the point, when you go on to illustrate the point? Or, is your counter-point to GP that "design is special, so cut us some slack"?
If performance was the only thing that mattered to consumers then performance and optimization would be the only thing Instagram's developers would focus on. Facebook is a public company, it publishes Instagram's engagement, growth and advertisement numbers every quarter. Choosing a technology that hurts those numbers would be a poor decision.
Performance doesn't come for free it often comes at the cost of stability and slower time to market. In the case of React Native versus having separate Native teams it also comes at the cost of synchronizing different product teams and dealing with the bugs that come out of that.
To sum up, if React Native was a poor choice it would reflect in the user engagement/growth numbers and wouldn't last long within a metrics driven public company like Facebook.
I'm very sorry if my comment came across as a rant, that was not my intent. I actually never made the claim that React Native makes developers lives easier in that comment.
My main point was that raw performance is not the only thing that matters to users. App stability and the time that it takes to get new features to market are also things that users care about, sometimes at the expense of performance.
Facebook/Instagram make product and technology decisions based on metrics. Making life easier for their developers is a secondary concern. If a feature is not moving the engagement numbers in the right direction, it gets cut.
The proof of this is Paper, a beautiful fast native app that was originally meant to the replacement for the main Facebook app. It's numbers sucked, so Facebook cut it.
For the most part performance problems in consumer apps are things like pagination, poor re-use of data structures, over pre-caching, etc.
Instagram never has more than what... 10, 20 elements on the screen? And it's all pretty much text or at most a 10 second video clip. There's no reason even a crappy mobile processor can't handle those elements. It's all a matter of being intelligent about what you put on the screen and when.
There's no need for high performance rich data structures. There's no big data.
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.
The code for the binding classes lives in retrofit.adapter.{guava|rxjava|…} [0] but the respective library still lives in its usual package. [1]
If that weren't the case you could A) not manually provide a minor version via your dependencies block in your build script and B) would have interop problems between libraries and between a library and your code as the same interface copied to a different packages is not the same interface for Java.
[0] https://github.com/square/retrofit/tree/master/retrofit-adap...
[1] https://github.com/square/retrofit/blob/master/retrofit-adap...
This used to be a massive pain but lately the Android Studio / gradle multidex tooling has gotten so good that I don't notice anymore.
DEX uses a method table, listing every method with an ID, and using in the rest of the file only that ID to refer to it.
This ID is limited to 2 bytes.
Obviously, thats an issue, but short of using varint or straightaway uint32 there's few alternatives. And those use either more CPU or memory.
That said, you mention using a varint or uint32 which "use more CPU or memory" -- 16 bits vs 32 bits in applications that use megabytes seems trivial. Can you explain why that's a concern?
>Tor: So [regarding] the infamous 64k method [issue].. I understand that it is a dex file format limitation.. which is a short integer. Do you have plans to address this somehow, by either change the dex format or some other way?
>Anwar: So we've talked about revving DEX, so that limitation doesn't exist anymore. And there's a couple of reasons we haven't done that: one, there're other things we would like to do better as well, including supporting new language features. The other reason is - it doesn't help us with devices still in the field. It's hard to go and say "by the way, we're going to upgrade your runtime.." So what do we do in order to address that? We will do the DEX byte code [change], but I think there's sort of building block that we needed first - what we're calling multi-DEX. And the idea is.. here's something people were doing - they were breaking up their files into multiple DEX files (each of which exceeds the 64k limit), the main classes in DEX file could see the classes and use them in sort of references rather than loading those classes and having limitations in how you can use them. They will go and use reflection to find the boot class path and modify it to include their secondary DEX files. So this is kind of hack, but a necessary one for them.
>What we're doing in L is in runtime we will have a native support for multi-DEX. All your DEX files that you have in your app will get dexopt-ed or compiled by us and collapsed into a single .oat file which is a binary file we generate.. ..And we have a support library on top of that.. ..if you have multi-DEX it will work on older releases of Android back to Ice Cream Sandwich.. will work on Gingerbread too, but we're only validating back to ICS. So once you have that, than that free's you in the future to do the DEX byte code change, and then something that partitions it and runs on the existing [devices]..
One interesting note is that he mentions that they'll hopefully have the DEX revision by M. Well, we're on N so it looks like they missed that target date. Perhaps O will finally get the long awaited DEX file format revision.
1 - Meego reborn as Tizen
2 - Tizen gets the Bada C++ SDK, with its Symbian C++ like flavour
3 - Enlightment guys join Tizen
4 - C++ SDK gets kicked out and replaced by Enlightment C libraries
5 - Developers complain that Tizen 2.3 drops C++ and is a C only experience
6 - Samsung announces support for .NET Core as high level native Tizen tooling
Really, what SDK are they going to release next?!
Most people around the world are on pre-paid, not contracts, and they only update their devices when the current one dies.
Even now, the majority of the devices being sold on the 300 € border are Android 5 or 6, with no planned upgrade to 7.
Doubtful. This decision is what allowed Android to perform reasonably even in the early days circa 2008. Without such a restriction, it's possible that Android couldn't have competed with iOS on performance and die as a consequence.
It's easy to make fun of technical decisions made ten years ago, try to put things in perspective.
Besides, even today, this 65k limit is barely a minor annoyance that only a very tiny percentage of Android apps ever hit (and there are easy workarounds).
This is not true, you can easily hit this limit because of a dependency that you _need_ that pulls e.g. Gauva, of when you use 2 or 3 libraries from Play Services, which are huge
> (and there are easy workarounds)
Easy maybe, but the issue is still more than _a minor annoyance_ imo
Most of these methods are typically contributed by dependencies, not by the app itself.
No. I've built huge applications that didn't come nowhere near that. I don't dispute some apps might run into that, but it's not a regular occurrence at all.
The real problem here is that it depends on what kind of libraries you're using. If you're liberal with adding a lot of all-purpose libraries when you only need a feature or two, you can run into that limit fast.
For example, look at the comparison table ("Replacing existing libraries") here:
http://jeroenmols.com/blog/2016/05/06/methodcount/
If you just need to load an image, do you want a library with 12k methods (!) or 800?
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.
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.
Edit: 4 months because many novel solutions needed to be developed. Particularly a coarse indoor location that uses iBeacons and works without internet access and a statistics based learning audio player that alters content order based on what you have previously listened to.
I hope you open sourced these :)
I was looking at React Native the other day and the impression I got was that almost every piece that does more than display data from the web needed extra modules and far from all of them were written already.
Disclaimer: react-native-navigation is developed by Wix, my employer, but I have not worked on that one.
Often I see people touting "cross-platform development", but then, in practice, one platform always gets priority, and when it comes to support the other, a lot of the view code has to be rewritten. How much of an effort do you reckon would be required for this app to support Android?
If only iOS was the only target, why did you go through the RN hoop, when Swift would be much more natural?
I wouldn't list "cross-platform development" development as the most important feature to me. If that is the case then I would just as easily used Ionic or Cordova which are far more stable then React Native currently is. Rather it was a combination of things that got me to use React Native for a project:
1. Redux - Single direction data flow 2. React - Pure render functions 3. Ease - Both easier to learn/use and faster iteration times vs. Native.
This project was honestly a testing ground for React Native for my team and it was a small project that if we decided to we could switch to natively without too much of a time hit. We fell in love with pure render functions and single directional data flow and it would be hard to go back to MVC-like architectures. (Yes their are libraries for that for Native platforms but not with the same ecosystem and community behind them as React Native has.)
As for how hard would be to port over? I'd say we would could keep all the logic and would have to redo 40 - 50% of the UI for Android. Which is higher then it would be now because when we started navigation in React Native was the wild west so we dropped into a Native solution.
Our next project however is a cross platform React Native app, which we hope to release by the end of this month. This app shares about 80% - 85% of the code between platforms. We also believe as a team to making apps feel native to their platform so Tab Bars on iOS and hamburger menus on Android, which is why our numbers are lower then other apps that use their own branded UI vs. platform UI.
So if anything the general layout of an iOS app would meet the latest Android Design Guidelines quite well. There may be certain "iOSy" things left like very blurry backgrounds but overall there's little reason to have a different UI layout across platforms at this point.
I do hope to return to Swift once the language stabilizes a bit more. It was annoying not being able to easily use any third party swift libraries when Xcode 8/iOS 10 came out (Apple made some Swift language changes and all third party libraries had to update).
All that being said, I'm pretty happy with React Native, its waaay better than any other cross platform solutions I have tried.
It was interesting going to the React Native developer meet up in SF. Very few native developers were present, pretty much everyone in attendance was a web dev.
I think being a native developer who is good at react native gives you a competitive advantage.
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.
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.
Dude, I've been developing on the iOS platform since 2011 and Android not much later than that. I've developed in Xamarin, and RN has a MUCH better development toolchain and dev experience.
I really don't understand the JS hate. I'm using typescript for RN development and I have had 0 problems so far. JS/TS dev velocity is just so much better than ObjC/Java. Swift is a huge step in the right direction.
Not sure how you developed with Xamarin, or how long ago, but it most definitely does not have worse toolchain development. Starting with a proper IDE, to compilation, to native-interop, to performance, to actual base library that exists.
As a side note, it seems http://subvertapps.com is down.
What do you mean by feds? That's still a very confusing statement. Switched off of Xamarin about 8 months ago and haven't looked back. My organization had a ton of problems with Xamarin, without honestly that much gain at all. We still needed specific devs for Android and iOS. Sharing component and state code has been an absolute boon in productivity and speed in getting a world class suite of apps out. That plus a React stack for Web means I can help out on Web with no ramp up, and vice versa.
I am not sure why you have had bad experience with Xamarin. To me, using .NET for shared business logic sounds like a real winner, but I will give you the fact that it helps with web dev. However, as a purely technological observation and no interest in management considerations, I can only argue against using RN at this stage.
There's always articles like you're mentioning. I mean, go look at articles when Swift was first announced - or even iOS tutorials and forums ca. 2011.
Sharing business logic is a good thing. But it's hardly the number one feature of react-native. We share almost everything, and have almost no problems doing so. It's been a very good thing for our org, while Xamarin was the opposite.
It's also worth noting that we ramped everyone up from being C# front-end to React/React-Native front-end. So nobody really came in as cutting-edge web dev experts, but our developer velocity now is insane. I think React/RN are good things.
We are also starting to use .NET Core for Backend Microservices which would allow more code sharing and Backend devs could in theory chime in on the mobile codebase quite easily.
With all the cross compiling/ web assembly stuff going on it will probably soon be possible to use a .NET lib in JS frontend code as well.
I agree that RN is a good alternative to this if your team is very JS dev heavy and while i did a lot of nodeJS and Angular in my life, i just loathe the JS ecosystem of today.
In our organization, it ended up being UI code that was the 90% number. The actual business logic code wasn't extremely extensive in the same way that we had to know Android and iOS, and then basically transpile mentally what we know into C#. Though almost all of the core SDK methods are named the same, so it wasn't too huge of a mental switch.
At this point with react-native, almost everything is shared. UI code, business logic, app state, etc. I think the node ecosystem opens our organization up to a lot more possibilities as well.
I've found that 3rd party react-native libraries are about the same quality as Xamarin Nuget packages. Some are good, most are meh.
Also, I upvoted you. Thanks for sharing your experiences.
And I have tried MVVMCross and forms.
React Native (node-style cjs or es2015 module) based applications don't have to be poorly written, or ill-tested. I think a lot of your bias is unfounded, since Steve Jobs saw only web applications on iOS initially.
For every really good iOS/Android developer, there are probably 10 really good web developers that easily can pick up RN. As a web developer myself, it's a full time job to keep up with the JS ecosystem alone.
I tried learning ObjC a few years back but gave up because of limited time, weird syntax and very slow feedback loop.
Now I am stoked that I can finally build native apps with the web tech I spent so much time learning, and I don't think I'm alone in that regard.
The main reason to switch is that the user cannot tell the difference for their use case, and they get to iterate faster.
It's really more like Xamarin with code running in a JS engine and with somewhat easier native code integration.
"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
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
- 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.
Not completely though, you still have to think a lot more about ownership and object lifetimes (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) 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.)
Although I am now eyeing on Xamarin, because I got tired of having to deal with JNI all the time.
Javascript/RN, yes (at the cost of safety). Plus you can't throw a rock without hitting two JS devs, even in my non-tech-hub city.
Go, as mentioned elsewhere in this thread, would also be appropriate for the task (Google, for the love of god, make it a first class citizen on Android and use that as an excuse to refactor your SDK into something that doesn't seem like it was loosely designed by a committee then handed to the Summer interns to implement with no supervision or clear specs).
Are you talking about type safety? Because you can use TypeScript with React Native too, and it's probably a nicer dev experience than plain JS as well.
I'm shocked more people don't do this—I guess they don't know C++?
You can do that with JS (or TypeScript etc.) as well. Even Java (or Kotlin) and Swift, or anything really, if you care enough to separate it from the UI parts.
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.
We see space for React Native to grow inside of Instagram on flows similar to the ones mentioned on the blog post.
Also, what approach did you use for testing the RN flows? (unit testing, e2e testing, etc).
BTW, thanks for sharing your experiences!
Specifically how was performance across Android/iOS?
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/a3457486e39d...) for a sneak peek of what's coming up :).
Part of the issues were our own fault: overlaying a transparent image provided by our designers instead of asking for a non transparent one, not using flags like renderToHardwareTextureAndroid.
Others were due to our use of the navigation library, react-native-router-flux, which on Android is backed by fragments. This caused a bunch of overdraw issues (i.e previously pushed views, which were not visible were being rendered in the background). We are planning on migrating away from this routing library to another one.
I'd love to read more articles about react native and performance based on real world examples at scale so please keep publishing them.
I'll see a post which interests me for a few seconds and then it's gone. Happens often.
Side effects of RN?
Excellent work.
Edit: Answered in other comment below. Share logic, no UI.
Has that been your experience? When you moved any UI from UIKit or native Android views to React Native, was it worse in any way? Did it require a lot of work to get back to native-quality UX?
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.
How much, if any, code reuse can there be between React Native and React (proper)?
For Sleeperbot it's 50% code-sharing between desktop / mobile, and then 95% between iOS & Android.
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, …)
Are there any other ways of achieving the same result?
Good Read: https://www.reddit.com/r/androiddev/comments/5qr9xw/avoiding...
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.
The last thing I want is to see yet more traveling down the path of "web app" style development for my phone's apps.
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.
This article is about React Native, not React.
https://github.com/facebook/react-native/blob/master/React/V...
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?