Pourquoi React Native est toujours une bonne solution en 2021

Pourquoi React Native est toujours une bonne solution en 2021
23 / 02 / 2021Temps de lecture 4 min.
FacebookLinkedInTwitter

On ne présente plus React Native en 2021. Bien au contraire, la plupart de ses détracteurs actuels seront plutôt de l’avis que c’est du passé, dû notamment à l’arrivée de technologies comme Flutter ou les PWA. Nous n’en sommes pas convaincus à Agaetis et nous allons vous expliquer pourquoi dans cet article. La principale raison est évidente : il n’y a pas de solution universelle qui réponde à tous les use-cases de la meilleure façon possible.

Rappel des intérêts de React Native

Avant d’entrer dans les détails, faisons un petit rappel des avantages de cette technologie par rapport à du développement natif (sous Kotlin et Swift). On distingue 3 points principaux :

  • L’avantage principal est bien évidemment le partage de code entre les deux plateformes : mêmes équipes de développement, mêmes tests et généralement moins de coûts !
  • React Native profite par ailleurs de la popularité de JavaScript : une communauté plus développée que Kotlin et Swift, donc plus de facilités pour recruter, faire monter en compétences, etc… Il profite également de la puissance de React pour créer des interfaces, après tout, SwiftUI en est inspiré ce n’est sûrement pas un hasard ! 
  • Enfin l’environnement de développement est plus “puissant” grâce au caractère interprété du JS face à ces 2 langages compilés, à travers notamment le hot reloading (donc encore des gains de productivité à la clé !).

Évidemment le tout est au prix d’une baisse de performances face à du développement natif, mais cela reste préférable à ce niveau, que des applications web hybrides ou des PWA. React Native a d’ailleurs un autre avantage face à ce type d’applications web : l’utilisation de composants natifs à l’affichage. L’utilisateur a l’impression d’utiliser une application native, en échange d’un démarrage un peu plus lent (on en reparle plus bas).

Représentation schématique du fonctionnement de cette technologie jusqu’à maintenant. A gauche le thread JS qui exécute le code de l’application. A droite en orange le thread “natif” classique (pour l’UI), vers lequel sont transpilés les composants graphiques au lancement de l’application. Le “Bridge” React Native relie le tout pour que l’ensemble fonctionne (par l’échange de messages asynchrones). Enfin on trouve “Yoga”, le moteur de calcul pour l’agencement des composants à l’écran.

Les trois facteurs déterminants pour le futur de React Native : Expo, Hermes  et “JSI”

En quelques années, Expo est passé d’un petit framework sur-couche de React Native, à un must have pour la plupart des projets. Dans le même temps, l’équipe de ce dernier travaille à la mise en place du nouveau moteur Hermès qui promet des temps de démarrage bien meilleurs (2x plus rapides !).

Expo

Expo permet à l’origine de répondre au problème principale de React Native pour les développeurs : la dépendance au code natif. En effet, l’abstraction n’est pas complète et il faut toujours y toucher un peu lorsque l’on souhaite accéder à une API hardware (principalement lorsqu’on ajoute la dépendance). Et par ailleurs seuls les développeurs sous Mac peuvent développer et vérifier que l’application fonctionne sur iOS. Ce n’est plus le cas avec Expo, ce framework a indéniablement participé à l’émancipation de React Native.

A l’heure actuelle, le framework continue de se développer et va plus loin, notamment avec un système de mises à jour automatiques sans passer par les stores, à la manière des PWA (pas besoin de gérer de la rétrocompatibilité avec le backend !).

Evidemment Expo étant encore plus récent que React Native, son utilisation ne se fait pas sans contreparties : le support du Bluetooth, par exemple, n’est pas encore disponible. Mais à noter qu’il est possible à tout moment dans la vie d’un projet sous Expo de revenir à du React Native pur.

Hermès

La première fois qu’une application React Native est démarrée, elle va compiler ses composants graphiques en composants natifs (comme vu plus haut). Cette compilation n’est évidemment pas économe en temps et cela peut se faire ressentir ! Mais ce ne sera plus qu’un mauvais souvenir avec le moteur Hermès. Ce dernier va simplement permettre de faire cette étape de compilation au “build” de l’application, lorsqu’on souhaite la déployer sur un store.

Voici deux schémas pour illustrer :

L’équipe de React Native a indiqué que ce moteur allait réduire les temps de lancement de moitié : l’application hybride démarrerais ainsi presque aussi rapidement qu’une application native ! Il y a aussi des améliorations au niveau de l’utilisation de la mémoire ou de la taille du package. Ce moteur est pour l’instant expérimental et disponible seulement sur Android, encore un peu de patience !

JSI

Ce dernier point est bien plus technique. Pour faire simple, le “Bridge” que l’on a vu précédemment va être modifié et amélioré dans une prochaine version de React Native. Cette nouvelle version est appelée “JSI” (pour JavaScript Interface).

Ce Bridge a en effet quelques problèmes liés à son fonctionnement asynchrone. Par exemple, lorsqu’un événement natif comme une demande de scroll est envoyée au code JavaScript, ce dernier va recevoir l’information avec un décalage. Or l’environnement natif n’attendra pas que ce dernier prenne la main pour commencer le scroll, parce qu’il ne peut pas savoir lorsque cela aura lieu. Le natif n’a pas “conscience” de l’existence de la partie JavaScript. Ce délai peut être senti ou visible par l’utilisateur pour d’importantes listes d’éléments.

Le JSI va améliorer cette communication en réduisant la latence et en permettant l’interopérabilité entre les deux univers. Pour faire simple : cela ira plus vite ! Dans un second temps, cette nouvelle interface va permettre de s’affranchir de JavaScriptCore, le moteur JS de Safari. Ainsi, sur Android il sera possible d’utiliser V8 (avec de nouveaux gains de performances à la clé).

Plus d’informations techniques dans cet article sur Medium (où c’était annoncé pour 2020), et sur ce ticket Github pour suivre où ils en sont, car ils ont pris un peu de retard.

Vous pouvez constater les différences avec le schéma plus haut : Yoga sera accessible directement depuis le JSI (gains de perfs) et ce dernier est à cheval entre les deux “mondes”

Conclusion

React Native est donc toujours un très bon choix pour réaliser une application mobile, lorsque les performances ne sont pas un réel critère ou en tout cas non prioritaire. Nous verrons d’ici quelques années les impacts des améliorations en cours, mais d’ici là, si c’est important pour vous, privilégiez plutôt une application native ou Flutter (sujet d’un prochain article). Cette technologie est toujours un bon choix car l’équipe de Facebook reste dans une optique d’amélioration continue sur le sujet. Ce qui reste certain, c’est que le projet avance dans la bonne direction !

Enfin pour ne pas oublier un fait méconnu, il est possible d’intégrer des écrans React Native dans une application native déjà existante. Pratique, si vous avez un gros historique et ne souhaitez pas tout réécrire de zéro, ou si vous souhaitez partager entre les deux OS mobiles une partie seulement d’un nouveau développement. Après tout Facebook l’utilisent eux mêmes avec l’application du même nom, l’onglet Marketplace apparu il y a quelques années est en effet codé en React Native ! Si vous jetez un œil, vous constaterez… que la différence est invisible. Magique !

Un sujet vous intéresse ? Une question ? Contactez-nous !

FacebookLinkedInTwitter
Logo Agaetis
Nos adresses
Clermont-Ferrand
9, allée Evariste Galois
63170 Aubière
Tél. 04 73 35 47 51
Paris
21, rue de la banque
75002 Paris
Tél. 01 44 63 53 13
Lyon
52, Quai Rambaud
69002 Lyon
© 2021 Agaetis - Tous droits réservés

Ce site utilise des cookies à des fins de mesures d'audience, ainsi que pour améliorer votre expérience de navigation