Why we use ReactJS as our front-end library of choice.

September 20, 2018

by  Chris Carreck

When we first started developing apps in the early days of CLD (2010), the landscape for app development was pretty restricted. For iPhone development is was Xcode and objective C (before swift came along), Android studio for, well, android, and for windows, well, ugh, lets not go there. But we focused primarily producing rich interfaces for iOS, it was still reasonably early days for the smart phone and we were able to output sleek, highly involving user experiences for our clients.

This did come with some issues though. For example clients requiring both a website and an app, developers in our team would need to either cross skill, or, we hire those specialising in only web development, and others in Objective-C, and then another group that were java developers and happy to get their hands dirty in Android studio. Luckily for us, we had a team of very talented developers that were able to cross skill, and with a little bit of patience, we were able to effectively produce web builds, as well as native mobile builds, with the help of one or two “experts” in that field laying the foundations for others.

Then came along Cordova, and we were able to use our same core javascript skillset (our back-ends are primarily Node), and build a suite of apps that could target iOS, android and windows devices on a “Single” code-base. This was great! It meant we could now have developers that didn’t need to completely switch from one language and code base to another when producing the same app. We could build the core code using javascript and CSS, utilising our developers expert knowledge working across the full stack, to develop on a single code base to eventually target iOS and android. This all sounds perfect, the perfect framework to produce multi-platform apps on a single code base with a general skillset, what more could we want, lets all hang up our boots and go home.

Except something was still missing. We tried a few different flavours of Cordova and Js frameworks, we used Crosswalk for smooth experiences on android, later trying ionic and angular for some of our clients, backbone for some, phone gap etc, and while we were able to still get really good results, we found that we always were tweaking something here, a branch there for some thing else, css especially for android, some javascript specially for IOS.

Then there were the JS frameworks and libraries them selves, Knockout, Ember, Backbone, Angular, React, theres a long list, but these are some of the ones we touched on. MVC and MVVM were all the rage in javascript, and separating concerns and decoupling logic from the app itself are all good, solid practices when architecting any application. Backbone allowed us to quickly scaffold interfaces and seperate logic. Angular, although producing a solid framework to decouple views, services, whatever.. in an agency environment, where we needed to rapidly produce UIs and demo products to clients at a fast moving pace, just seemed… heavy. There was a large amount of overhead involved in getting a new, custom angular build off the ground. To quickly prototype UIs and not necessarily have all the moving components in place involved a lot of setup, and this was time we didn’t want to spend writing boilerplate code.

So we had a few frameworks, some worked well, some we weren’t so sure on, and we still had to use a flavour of Cordova on top of them to effectively target different platforms. It was working well for us, and our clients were happy with the results, so it was ok.

Then we decided to give reactJS and react-native a turn. It had been around for a little while at this point, but was still a relatively less popular library than it is today. We found that is was really much quicker and easier for our team to spin up a prototype, create some engaging UIs for our clients, and get feedback quickly. As we always do in an agency environment, learn fast, fail fast. We were able to pivot quickly when changes were necessary.

Now its not just that simple to spin up a demo in react and then suddenly turn it into a native app for iOS and Android, you still need to create the react-native components for each of the platforms you wish to target, which involves writing code for both, but we can still write all that UI code in one place, and its still *native* for that platform. So we have the benefit of a single code base, with more targeted native code for our platforms, which brings me to my next point: our app UIs feel a lot sleeker in react than anything we got with Cordova. We don’t have any benchmarks to prove this, just 1000s of hours sitting with our developers, testers, and clients looking at, demo-ing and using the apps we produce, and there is a definite feel of a richer, sleeker experience in the end result using react, and react-native, than I think we have been able to get with a Cordova app.

Some of the main advantages we’ve found from using the react library are: quick turnaround for prototyping; a clean code base able to target web and native; developers can work on any part of our stack more easily; we no longer need to use different compilers to get better results on different devices; and of course, a much slicker end result for our clients. There are of course some downsides - especially if SEO is important, as not all search bots can render out javascript; JSX if you don’t want to pollute your HTML; web pack can be complex at times to learn, so we had to come up with solutions to ensure there were no negative impacts there, but these have been easily overcome (we will talk about SEO and react in another article).

Here at Creative Licence Digital, we are loving some of the apps we’ve been able to output for our clients, and using react and react-native plays a big part of that.

Be sure to follow us on Twitter @Cre8iveLicence, and if this kind of stuff interests you, then you'll love working with us).