Choosing React Native in 2019

As a head of mobile development, part of my role is to evaluate technologies in order for us to know what are the strengths and weaknesses of the said technology. This will inform us what we should use when a new project is starting up.
Gofore has used React Native extensively for the past two years. We have had success with it and enjoy using it. It is definitely possible to make real production grade apps, as an example, the Google play store Best of 2018 app was made using React Native. Still, there is room for improvement to be able to declare React Native 1.0 stable and ready. During 2018 there was some turbulence and uncertainty regarding the future of React Native. It made me begin closely following the future of the library. Here is a report of my findings.
TL;DR: It is looking like 2019 will be the year of React Native coming of age. There are many ongoing undertakings to make React Native even better than it is today. I am more excited for the future of React Native than I have ever been. Here are some of the (technical) reasons why.

Facebook contributions

React Native was created by Facebook and for a while, in 2018 it was a bit unclear how much Facebook was investing in the technology. After some rumours, Facebook made it clear through words and actions, that they are in it for the long haul.
One good sign that Facebook is ramping up work on React Native is the fact that they have been hiring more developers to their React Native team.
Firstly, React Native will enjoy improvements in React itself, which will have two big new features added in 2019: Hooks and Suspense. Hooks will let developers use state and other React features in functional components. After trying out hooks, I have been eagerly waiting to be able to use them everywhere! Suspense refers to Reacts new ability to “suspend” rendering while components are waiting for something and display a loading indicator. This will ease the typical pain point of having to figure out different states (init, loading, error, ready) for your component. Suspense will manage the complexity for you.
In June, Facebook published a blog post explaining that they are “working on a large-scale re-architecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps.”
This rework includes a JavaScript interface (JSI),UI re-architecture (called Fabric) and the new native module system (called TurboModules) but is generally referred to altogether as Fabric. This will offer significant improvements under the hood. It will also improve performance, simplify interoperability with other libraries, and set a strong foundation for the future of React Native.
In November Facebook published a roadmap for React Native. It gives an outline of their vision, including a healthy GitHub repository, stable APIs, a vibrant ecosystem and excellent documentation.
These are all areas where React Native has been criticized and I am really excited to see that Facebook has identified them and is actively working on improvements. It will lay a good foundation for the open source community to participate and contribute.

Open source community

React Native open source community got way more organized in 2018 and it seems we will reap the rewards of that in 2019. There is a new repository for transparent discussions and proposals, which facilitates changes proposed and made by the open source community.
There is an ongoing project called The Slimmening, which aims to make React Native core smaller, extracting parts of it that can be more easily maintained and developed separately. There are already two good examples of this. Jamon Holmgren (@jamonholmgren) championed extracting Webview and Mike Grabowski (@grabbou) spearheaded efforts to extract React Native CLI. Webview has already received much more love as a standalone library and it shows the potential of what The Slimmening, once done, can mean for the future of React Native.
Another ongoing project, which should be close to being finished, is updating Android JSC (which is used to run the Javascript on Android). The current version is archaic and results in differences between iOS and Android and performance issues. Having a modern runtime is crucial for the promise of a truly cross-platform development environment. Upgrading the JSC would greatly improve the performance of react native apps running on Android and allow support for x64 builds on Android apps.
Currently, there are a lot of 3rd party community libraries. The typical challenge with them is that they might not be well maintained. Expo is a company building on top of React Native. They have been pushing to be able to do React Native development without having to have knowledge of the native parts. Expo APIs look well thought of and maintained, but they have not been available out of the Expo React Native project. That is, until now. Having well-maintained community APIs available will make a significant difference for developers.

Conclusion

Hopefully, this list of ongoing technical projects and improvements in and around React Native has given you some insight into the potential that React Native has. Time will tell how well it delivers, but as of now, I am very positive and excited to be a mobile developer using React Native. I will be recommending React Native for many mobile projects at Gofore in the future as well. Let me know your thoughts in the comments below.

Juha Linnanen

Juha Linnanen

Head of Mobile Development at Gofore Helsinki. Passionate about creating mobile applications that help achieve results.

Linkedin profile

Do you know a perfect match? Sharing is caring

The GraphQL Finland 2018 conference was held recently (18-19.10.2018) at Paasitorni and was the first event of its kind in Finland. The conference brought a day of workshops and a day of talks around GraphQL. It was organized by the same people as React Finland as the good organisation showed. The talks were interesting, the venue was appropriate, food delicious, the atmosphere was cosy and the after party was awesome. Gofore was one of the gold sponsors and organized the afterparty at Kamppi.

All of the talks were live streamed and they are available on Youtube. I was lucky to get a ticket to the event and be able to enjoy the talks live. Overall, most of the talks were easy to comprehend although I only had a little experience with GraphQL through experiments and what I had learnt a couple of months ago at the React Finland 2018 conference.

“GraphQL is an open source data query and manipulation language, and a runtime for fulfilling queries with existing data. It was developed internally by Facebook in 2012 before being publicly released in 2015. It provides a more efficient, powerful and flexible alternative to REST and ad-hoc web service architectures. It allows clients to define the structure of the data required, and exactly the same structure of the data is returned from the server, therefore preventing excessively large amounts of data from being returned. – Wikipedia

You can also read the organizer’s summary of the event and check out the photos.
the GraphQL team on stage

(Life is hard, learning GraphQL easy)

Notes from the conference

The talks at GraphQL Finland were quite fast paced and more like lightning talks compared to the React Finland event: it was quite tough to digest all the new information. Fortunately, the talks were recorded so you can concentrate on interesting and relevant topics and get back to others later. Also, the sponsor’s lounge by Gofore and Digia provided a nice relaxing space to get your thoughts together. I have to say, Digia’s Star Wars Pinball machine was quite fun (smile)
The talks covered different aspects of GraphQL and surrounding topics in details. Here’s my notes from the talks which I found most interesting and watched live at the event.
Goforeans in the sponsor lounge

(Goforeans in the sponsor lounge)

Goforeans challenging attendees to foosball

(Goforeans challenging attendees to foosball)

Adopting GraphQL in Large Codebases – Adam Miskiewicz

The event started with Adam Miskiewicz’s story from Airbnb and incrementally adopting GraphQL. It’s simple to start using GraphQL in your project but adding it incrementally and carefully in huge codebases powering large distributed systems is not quite as straightforward. The talk dived into how Airbnb is tackling this challenge, what they’ve learned so far, and how they plan to continue evolving their GraphQL infrastructure in the future. Towards GraphQL Native!

Going offline first with GraphQL — Kadi Kraman

Kadi Kraman from Formidable Labs talked about going offline first with GraphQL. She did a nice interactive demo with React Native and Apollo 2. Users expect your mobile app to work offline and the tooling in GraphQL makes it reasonably straightforward to get your React Native app working offline. Slides

“Do this as you go and offline comes almost as a side-effect”

Life is hard and so is learning GraphQL — Carolyn Stransky

Life is hard, without documentation. Carolyn Stransky presented her story of ups and downs when learning GraphQL and documentation’s role in it. The problem with GraphQL is that – because there’s no “vanilla” GraphQL – there’s no central hub for all of the information and tooling necessary to learn it. It’s under-utilised and scattered throughout our community. The talk touched on how to better enable GraphQL docs for learning and comprehension and the slides pointed to good resources.

Database-first GraphQL Development — Benjie Gillam

Benjie Gillam from PostGraphile taught how a database-centric approach to GraphQL API development can give your engineers more time to focus on the important parts of your application. Adhere to GraphQL best practices, embrace the power of PostgreSQL, and avoid common pitfalls. Interesting slides.

graphql-php — Christoffer Niska

Christoffer Niska gave some good tips for software development: Don’t over-abstract, test everything, use static type checking, follow best practices, don’t prematurely optimise.

The (Un)expected use of GraphQL talk by Helen Zhukova showed the benefit of a single code base on the client and server side. Partly live coded with i.a. CodeSandbox. The any DB, in this case, was MongoDB.

Mysterious closing keynote — Dan Schafer

The mysterious closing keynote was Dan Schafer talking about GraphQL history, present and future. “Strive for single sources of truth”. Still lots of things to do in the ecosystem.

Afterwords

The last chance to practice your Finnish was at the Afterparty  🎉  at the Gofore office!

“Someone said your afterparty was the best conference party ever :)”

foosball

Foosball was popular also at the afterparty.

 
 

Avatar

Marko Wallin

Marko works as a full stack software engineer and creates better world through digitalization. He writes technology and software development related blog and developes open source applications e.g. for mobile phones. He also likes mountain biking.

Do you know a perfect match? Sharing is caring

Gofore Project Radar 2018 Summary

By now, it has become an annual tradition at Gofore to conduct a Project Radar survey at some point of the year to gain better insight into our presently running software projects. The 2018 Gofore Project Radar builds on two previous Project Radar iterations, conducted in fall 2016 (in Finnish only) and spring 2017, containing a set of questions relating to currently employed tech stacks, development practices and projected (or hoped-for) technological changes. Most of the questions from last year’s Project Radar made their way into this year’s Project Radar to allow for year-on-year variation detection. We also added some new questions that were considered important enough to warrant their inclusion in the survey.
So with the 2018 Project Radar results in, what can we tell about our projects’ technological landscape? What can we say has changed in our technological preferences and project realities over the past year?
 

The Gofore Project Radar survey results for 2018 are in! [Click on the image to enlarge it].

End of JavaScript framework fatigue?

Over the past few years, the frontend development scene has shown intermittent signs of “framework fatigue” as a steady stream of new frameworks, libraries and tools has flooded the scene, challenging developers to work hard to keep pace with the latest developments, current community preferences and best practices. A look at our Project Radar data tells us that at Gofore there has been no significant churn when it comes to primary frontend technologies employed by individual projects. Instead, the results indicate a distinct consolidation around React, Angular and Vue.js, the three major contenders in the JS framework race. All these three have gained ground on older frontend techs (AngularJS, jQuery etc.) and ratcheted up their project adoption percentage, React being the top dog at a near-50% adoption rate among projects represented in the survey. If given a chance to completely rewrite their project’s frontend, most respondents would, however, pick Vue.js for the job.
The fact that there was no major change from last year in preferred frontend frameworks is perfectly in line with developments (or lack thereof) on the frontend scene over the past year. While last year saw major releases of both React and Angular roll out (with Vue.js 3.0 still somewhere on the horizon), there were no new frameworks to come along that would have been able to upset the status quo and catch on big time in the community (regardless of distinct upticks of interest in at least Svelte.js and Preact). This stability comes in stark contrast to the unsettled years in the not-too-distant past when the balance of power between different JS frameworks was constantly shifting as new frameworks and libraries appeared on the scene.
Looking beyond the battle of JS frameworks, a significant trend with regard to frontend development is the ever-increasing share of single-page applications among our projects’ frontends. Around 64% of this year’s Project Radar respondents reported to be working with single-page applications, up from 57% in last year’s Project Radar results.

Node.js on the rise

Moving our focus to the backend, where Java has traditionally held a predominant position among our projects, a somewhat different trend emerges. While the Project Radar data clearly brought out a tendency toward consolidation around the three major frontend frameworks, the picture on the backend side, on the other hand, looks a little more fragmented. Last year’s Gofore Project Radar pegged Java usage at nearly 50% among all projects represented in the survey, trailed by Node.js and C# each with a 15% share of the cake. While Java still came out on top this year, it was reported as the primary backend language in only 32% of the projects, down a whopping 15 points from last year’s results.
This drop was fully matched by an upward surge by Node.js, which more than doubled its share of the overall pie, up 17 points from last year. While C# stood its ground at close to 15%, a crop of new languages, missing from previous years’ results, entered the fray in the from of Kotlin, Clojure and TypeScript. Regardless of there being only a handful of projects where they were reported as being primary backend languages, they contributed to the growing share of minority languages in our backend landscape, a group previously comprised of Scala, Python, Ruby and PHP.
Similarly to how respondents were asked to choose their hoped-for replacement tech for their frontends, we also asked our developers what was their preferred language for rewriting their backends if given the chance to do so. Last year most respondents would take the cautious approach and stick with their previously established backend languages. This year, however, there was considerable interest in rewriting backends in Kotlin, particularly among respondents who reported Java as their primary backend language (55% of all respondents were eager to switch to Kotlin from some other language).
Before drawing any conclusions from these statistics, it should be noted that upwards of 55% of respondents reported to be working with a microservices-type backend stack, suggesting that potentially multiple languages and server-side frameworks might be used within a single project. Still, the appeal of Kotlin, particularly among Java developers, is clearly apparent, as is the shift toward Node.js being the centerpiece of most of our backend stacks.
While the Project Radar does not shed any light on the reasons behind any technological decisions, the increasing popularity of Node.js can probably be put down to the above-mentioned prevalence of microservices-esque backend setups, where Node.js often slots in to serve as an API gateway fronting other services, which, in turn, might be written in other languages. Another contributing factor might be the emergence of universal JavaScript applications, where the initial render is handled by running JavaScript on the backend.
The popularity of Kotlin, on the other hand, has been picking up ever since Google enshrined it as a fully supported language for Android development. Considering its status as one of the fastest-growing programming languages in the world, its increasing presence in server environments is hardly surprising.

Going serverless

Now where do we run our project infrastructure in the year 2018? According to last year’s Project Radar results, more than two thirds (68%) of all respondents were still running their production code in a data center that was managed either by the client or a third party. This year, that number had come down to 59%. While this isn’t particularly surprising, what is mildly surprising, though, is the fact that IaaS-type infrastructure saw an even greater decline in utilization. Only 47% of all respondents reported to be running their production code in an IaaS (Infrastructure as a Service) environment, as opposed to 60% last year.
As the utilization of both traditional data center environments and IaaS services fell off, PaaS (Platform as a Service) and, especially, serverless (or FaaS, Function as a Service) platforms were reported to take up a fair portion of the overall share of production environments. While still in the minority, PaaS services were reported to be used by 12% of all respondents, tripling their share of 4% from last year, and serverless platforms by 16.5% of all respondents (no reported usage last year as there was no dedicated response option for it).
As our projects’ production code is more and more removed from the actual hardware running it, containerization has also become more commonplace, as evidenced by the fact that Docker is now being used by 76% of all respondents (up from 43% last year). Despite Docker’s increasing adoption rate, there wasn’t much reported use for the most popular heavy-duty container orchestration platforms: Kubernetes, Docker Swarm, Amazon Elastic Container Service and OpenShift Container Platform were only reported to be used by 14% of all respondents.
Since running our code in cloud environments enables shorter deployment intervals, one could think we’d be spending more time flipping that CI switch that kicks off production deployment. And to some extent, we do: we have fewer projects where production deployments occur only once a month or less often (10% as opposed to 20% last year), but, somewhat surprisingly, fewer projects where production deployments are done on a daily basis (10.5% vs 12% last year).

Miscellaneous findings

  • Key-value databases doubled their reported project adoption (32% vs 16.5% last year)
  • Jenkins was the most prevalent CI platform among represented projects, with a 57% adoption rate (its closest competitor, Visual Studio Team Services/Azure DevOps well behind at 17%)
  • Close to nine percent of all respondents reported to be using a headless CMS (Content Management System)
  • Ansible was being used by 71% of respondents who reported using some configuration management (CM) tool, clear ahead of any other CM tools (Chef was being used by a little shy of eight percent of CM tool users, while Puppet had no reported users)
  • Development team sizes were smaller than last year (57% of dev teams had five or more team members last year, whereas this year such team sizes were reported by 52% of respondents)
  • The reported number of multi-vendor teams was smaller than last year (41% vs 47% last year)
  • Most respondents reported to be working on a project that had been running 1-3 years at the time of responding
  • Most project codebases clock in at 10k – 100k in terms of LOC (lines of code)
  • Scrum was the most favored project methodology, being employed by nearly 51% of all represented projects. Kanban, on the other hand, saw the most growth of any methodology (22% vs 12% last year)

Some closing thoughts

Once again, the annual Project Radar has told us a great deal about our preferred programming languages, frameworks, tooling and various other aspects of software development at Gofore. While the survey is by no means perfect – and I can easily come up with heaps of improvement ideas for the next iteration – the breakdown of its results enables us to more easily pick up technological trends in our ever-increasing multitude of projects. This year’s key takeaways are mostly reflections of industry trends at large, but there are some curiosities that would be hard, if not impossible, to spot if not for the Project Radar. The usefulness of these findings is debatable, as some of them fall under trivia, but still they come as close to a “look in the mirror”, technology-wise, as one can get at a rapidly growing company of this size.

Henri Heiskanen

Henri Heiskanen

Henri is a software architect specializing primarily in modern web technologies, JavaScript/Node.js & JVM ecosystems and automated infrastructure management. A stickler for clean code and enforcement of best practices in project settings, Henri is uncompromising in delivering well-tested, high-quality code across the stack.

Do you know a perfect match? Sharing is caring

I am so proud that I participated in helping to organise such an amazing event. Most of the things went quite well, people were happy, and it was fun. Kudos to Samuli Hakonemi, Aleksi Pousar, Harri Määttä, Juho Vepsäläinen and Joni Nevalainen and everyone else who stepped in to make this amazing event happen. All the sponsors, volunteers, the venue, Sea Life. This was a success because we have so many companies and individuals who are active in the community. I encourage you to step up and join the active developers who organise events and meetups and keep talks and discussions going in all community forums.
Gofore has been an active contributor in the meetups because for us, the community matters. We want people to learn and hear about new things because that’s what we do internally at Gofore. In our field, we need to learn new things and keep improving ourselves professionally (and personally) and it is easier to do that together. It is also fun to have some beer and snacks with other developers and talk about developing software.

Use Judgement, no need for Permission

It took some daring to go to the marketing people to say “Can we get the GOLD sponsorship please”, and some daring to join the meeting when React Finland was created. Also, it took a lot of daring to step onto the stage with over 200 people – but daring is part of our company culture. I dare you to step onto the stage in meetups, and conferences – it was a blast!
I was lucky to meet a lot of the speakers and hang out a little with them, and all of them were really nice down to earth people. Such a privilege to be able to attend the speakers’ dinner, talk to them backstage and hang out with them.
React Finland App, lessons learned
I was not sure if I should do a lightning talk to such a big audience since I have only done few meetup talks. I got encouragement from Ken Wheeler just before my talk, and my colleagues were cheering me from the Lounge when I was about to start. I am so happy I did the talk because I dared to do it. People said it went well – and I think it did. There was only one hiccup with my slides since I was reordering things just before getting onto the stage.
I was happy to see that so many people had installed the React Finland Conference App. We got some good feedback and we will be repeating ‘the mistake’ next year, hopefully with some additional features that we can use during the conference. This year we simply ran out of time adding all the features we wanted. You can still give us feedback on the react-Finland slack channel, tell us what you want to have in next years app.
The Gofore Crew
Last week was so amazing and now I am a bit exhausted but happy that I participated. A lot of goforeans dared to buy a ticket and dared to come onto the stage when we introduced ourselves. The support and cheers from colleagues have given me a warm and fuzzy feeling!
I hope to see You at meetups and conferences in the future!
Gofore stand chilling at React FInland

Avatar

Toni Ristola

Linkedin profile

Do you know a perfect match? Sharing is caring