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 p oints principaux :
É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).
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 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.
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 !
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.
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 !
Merci de nous avoir contactés.
Nous reviendrons vers vous dès que possible.
Oups ! Une erreur s'est produite lors de l'envoi de votre message.
Veuillez réessayer plus tard.