)
)
In the week that sees the 1st Birthday of Rect-Native being open-sourced, we take a look at it's journey so far.
The life of a developer BRN (Before React-Native) was a very different life indeed. A bleak existence in an environment which saw iOS and Android segregated and living in isolation and desolation of one another, just a screen and a keypad for company…
Hang on a minute… coding, unit testing, debugging, tweaking in peace and quiet? Only my own thoughts and Spotify playlist selection for distraction?…Why on earth did our community feel the need to do anything differently…?!
Well, whatever the motivation, React-Native has hugely changed the game and for the most part, for the better. If this week’s F8 Conference has told us anything, it is that this is just the start of the React-Native revolution.
Facebook, Microsoft and Samsung React-Native announcements from the F8 conference...
Notably, F8 saw the release of Facebook SDK for React-Native, which looks set to make it even easier for developers to integrate Facebook’s social features (Login, App analytics, Graph APIs) into their apps. It sets to do this by providing access to native components entirely through documented JavaScript modules, meaning you don’t have to call a single native function directly.
Additionally not only is Microsoft jumping on board to offer the potential of building React-Native on Windows PC, phone and Xbox, it is also providing open source tools and extensions to enable developers with the ability to create React-Native apps on the Windows platform.
Samsung has also announced that it is building React-Native for its hybrid platform, opening up a wealth of opportunities for building apps for a vast number of SmartTVs, mobile and wearables.
What have we learnt from using React-Native so far?
Though React-Native has only just reached it’s 1st Birthday, it’s implementation at 3 SIDED CUBE is even younger at just 2 months. That said the impact it has made of the team speaks for itself. So what is React-Native already doing to assist the team?
First things first, having an entire pool of developers to review the codebase means that the process of peer assessment has been vastly speeded up.
Additionally, with each line of code now being seen by more people, it is far more likely to work as expected.
As previously, developer resources can be allocated according to who is best suited to write particular logic, but with React-Native our pool of available developers has instantly doubled. When we team the speed of peer assessment and the increase in available resources, with the speed of development within the Javascript culture we feel that there is exciting potential to make our rapid prototyping even more rapid.
As Javascript code can be loaded dynamically to be executed on devices (allowing code to be swapped discreetly while the app is running) we are now able to add new features and fix bugs without the necessity of a time-consuming resubmission.
Any issues we've found since using React-Native?
The advantages are clear, but it has not been entirely plain sailing for the team at 3 SIDED CUBE to make the switch to React-Native – like the best of us in our youth, it has it’s flaws to be ironed out.
React-Native is still new enough to make upgrading a fairly tense experience. In recent weeks we have lost hours to dependency collisions, broken debuggers, and hanging bundlers after completing upgrades, and there is a sense of relief when we’ve finally got everything up and running again! It’d be naive to not expect teething issues when using such a new technology however, and thankfully the community is admirably quick at fixing issues such as these. Error messages and documentation can be visibly seen to be getting better from release to release too, which really helps us understand why things can go wrong.
Being an extra layer removed from the native system obviously means that when things do go wrong it can be that little bit harder to locate the route of the issue. Admittedly, as a result of this the performance of the code is relatively slow when compared to writing it directly and as such it still tends to work out quicker to do anything intensive in native code.
With Javascript being a less strict language it can at times result in less strict code, which is of course not a massive deal if you take precautions, but it does mean that as a team we’re dealing with an extra category of bugs we didn’t have to worry about before.
A further time-consuming elements of React-Native lies in the rapidity of development. Though speed plays a large part in React-Natives lure, the rapid development of Javascript culture can at times work to its disadvantage. With React-Native itself updating every few weeks (and typically breaking things in the process) as well as the fact that there is often a sparsity of third-party code documentation within the Javascript community, it can be difficult to stay on top of.
To summarise...
Drawbacks aside, when I look at what I achieved in my first year of being, I think it’s safe to say that React-Native has progressed with a superlative nature.
F8 has given us a glimpse at it’s future and the potential undeniably has the potential to prompt the next wave of the revolution.
Happy Birthday React-Native! We look forward to seeing what the troublesome twos might bring!
Published on 20 April 2016, last updated on 7 August 2018