Native to React Native
As in JS world we know everything comes and goes, even the biggest players in market such as JQuery, Angular and the same might happen to React JS which already started happening here:
Thus no one knows what is going to come to our plate and not all the developers like to develop on something which is in its early stages and bug prone.
How React Native works?
Lets see how ReactJS itself is:
Pros of ReactJS
- Component reusability and ease of maintenance in JS project.
- Flux architecture provides one way data flow which is easy to maintain data and DOM.
- Flexibility in development and designing.
- Great in performance.
- Mistakes in JSX are already caught at design time with linter or compile time instead of runtime.
- Virtual DOM concept allows creating light DOM tree which compares with previous one making the experience fast specially when we handle big amount of data.
Cons of ReactJS
- No MVC pattern, means you write html and css in your JS itself which is hard to maintain.
- Documentation is very limited.
- Large dataset handling might be slow due to frequent re-rendering.
- React is just a library and it doesn’t give all feature set, rather it depends on third party libraries for everything. This may or may not be maintained or updated or fixed by the third party developer.
- JSX way of writing your HTML and CSS in JS is not something everyone embrace and might be sometimes hard to maintain and develop.
- In case you are Typescript fan, it’s not popular within React community
Now lets see what React Native brings to plate:
Pros of React Native
- Component reusability and ease of maintenance for multiple platforms.
- Hot reload, you’ll get the feedback every time you save the code how your implementation looks like.
- For small projects React Native performance is mostly either close to native or sometimes above it as well.
- It’s easy to find a JS developer rather than a native app developer.
- Both native mobile projects doesn’t need to be play sync up game on features.
- Test development, maintenance and coverage gets huge improvement since you don’t have to do it twice. Approx 60% code can be tested in react rather than going to native codes.
Cons of React Native
Product owner’s obsession to have same design in two platforms just to create good UX is a naive idea since none of the users would be using both the platforms at once and compare the apps. This also mess up with how the app on platform should work and ends up in creating custom implementations which is time consuming and with imperfect user experience for user of that platform.
Design requirements of Android and iOS differ although the native elements are used then too placements and platform looks and feel may vary. This introduces too many if-else statements or separate code. Making almost same designs for both platforms may not works perfectly since the users of specific platforms are used to native elements and design implementations which might not be the case with ReactNative development.
JS itself becomes weak compared to Java, Swift, Kotlin, or Python for build in libraries, robustness and core framework. For example Cryptography, encoding, math, lists libraries are solid and consistent in other languages rather than JS.
Three Code bases
Your project will now have 3 code bases instead of 2 native mobile projects. There will be times when you might have to write platform specific code in the native code directly which needs requirement for developer to understand both native languages Java and Swift.
Instead of Android developers or iOS developers you’ll now need Mobile developers who should be excellent in JS, Java and Swift which looks like a hard task for any developer to cover 3 languages and know in and out of all three.
Third Party Libraries
- You’ll have to depend on 3rd party modules and libraries, these might be buggy and may or may not be maintained in future.
Even for maps implementation and many more functionalities React native refer to external libraries.
- Third party package lib may or may not work for your for which you’ll need proper document, which is usually not a case with a community developer maintained libraries.
- You may do manual installation which involve adding Java code for Android and Swift code for iOS. This might be a trouble if you are not familiar with either one of them which would probably be the case since one of the reason to choose React Native was coding in one language being JS.
- Third party libraries has smaller community as compared to native frameworks and may not be growing in future depending on how market responds.
Number of Dependencies, files and size
A very usual example would be a React Native Scaffolding which is a very minimal project vs Native code starter app. The React Native starter app vs native app would have
- ~1550 dependencies vs 2–10 in general,
- ~19k files vs 50–100 files &
- App size of 129 MB vs 500 KB — 1 MB.
This is like ~99% reduction in all three of app aspects.
Facebook may stop updating the framework or may change the underlying framework from React to React Fiber which is a complete rewrite & in progress here:
This we have seen in past that web technologies, frameworks and libraries came and went by, but if you are thinking of long term plan of your mobile project then going native would be the ideal scenario.
Frequent release cycle to react native bring many features and bug fixes but also brings breaking changes may be under the FB sprint “Move fast and break things”.
Coming from Native to React Native
- If you already have invested heavily on native apps in past, you’ll again have to start from scratch to develop your underlying utility set, features and architecture.
- Native development experience would really help as in cases when you have to handle platform specific feature sets. But this also means you’ll have to learn new set of languages and the underlying architecture how the bridge between native and React works.
Latest OS feature updates
Latest updates to feature set and improvements may be available late or may not be there at all in future. For example split screen, app icon notification, picture in picture, autofill, instant apps which were introduced in Android O 5 months before are still nowhere near available for developers in React Native.
Growing & consistent open issues
Also lots of known issues:
Here are some of major concerns:
- Animations API have performance issues which is one of the most upvoted issue
- SVG is not supported which is huge setback in Android since Vector Drawable decreases the size of the app upto 84%. (Check). Workmates size was also reduced almost the same size the time when Vector drawables were introduced.
- Issues closed without being resolved which was open since Oct 2015 till Aug 2017 just because it was not resolved, even from facebook
Although this is one of the most upscaled request from the community
- Performance issues been posted while developing with large data sets on ListView, UITable view.
- Rich Push Notifications in iOS from iOS 10 APIs are not supported and also not been taken care since January 2017 till August 2017 and may not be available in future as well.
- Out of Memory issues specially in Android is something that needs to be taken care off. RN for Android is based of Fresco for loading and displaying images where downsampling for png is disabled, since it’s still experimental. So if you are handling large png it’s hard to handle memory issues.
Unlike Android Studio and Xcode, React Native would have to be developed with either Sublime Text, Atom and their bunch of plugins, terminal or cmd, chrome debugger & lastly a emulator or physical device. This doesn’t end here as you’ll need Android Studio and Xcode and their whole dev setup as well for any native code tweaks or tests. You might have to miss on auto completes & have to have React Native documentation to know what to use.
Looking at ReactNative it does have huge love from our side & the community. It is also true that a lot of code may be more than 80% can be shared when implemented correctly. The concept to remove code duplication and increase code maintainability & test coverage would be of supreme importance but still looks like a bigger way to go to improve the whole development process and open issues with a proper channel and implementation.
Currently it doesn’t looks like it’s worth giving a shot given that I have already used Cordova, PhoneGap, Ionic & Titanium in past. Although a lot of projects have already adapted to it and are winning the race and a lot of them reverted back to native development, you should try it yourself a bit to understand if it actually works for your business requirements or not. These would be scenarios when to use it:
- Project doesn’t need complex animations and sophisticated UI
- Startup on shoe string budget and targeting for an MVP
- Minimal native API usage requirement
- Developers already have some Modern JS / ReactJS experience
- Don’t have separate Android and iOS teams
- Don’t have large reusable codebase in Swift and Java