React Native vs Full Native pour le développement mobile – Fabio Ferreira

Les applications mobiles sont traditionnellement écrites dans les langues natives. Dernièrement, cependant, les cadres hybrides multiplateformes ont gagné des parts de marché. La récente vague de popularité de React Native a soulevé la question: les développeurs devraient-ils utiliser React Native pour le développement mobile au lieu de la pleine nativité?

Au cours des 4 dernières années, React Native est devenu une communauté dont la moyenne est établie jusqu’à npm. Certains dans le monde ont adopté React Native, notamment Facebook, Pinterest, Skype, Uber et Brex. Son adoption généralisée est principalement motivée par la commodité de sa nature multiplateforme et l’approche technologique unique utilisée pour y parvenir.

Malgré le succès de React Native, de nombreuses personnes soutiennent que les applications mobiles natives traditionnelles sont toujours le chemin à parcourir. Les partisans du natif citent principalement ses avantages de performance et sa robustesse par rapport aux alternatives hybrides. Des compromis existent entre les deux options, et un examen attentif est nécessaire lors du choix entre les deux technologies. Cet article va peser sur la question en explorant ce qui rend React Native si populaire et en explorant comment cela fonctionne sous le capot. Nous examinerons également les avantages, les inconvénients et les impacts commerciaux de chaque option, en vous donnant les faits à connaître avant de faire un choix d’une manière ou d’une autre.

React Native est écrit principalement avec JavaScript et classé comme un framework «hybride», ce qui signifie qu’il est indépendant de la plateforme. Cela le sépare des applications traditionnelles écrites dans des langues natives telles que Java ou Kotlin pour Android, et Swift ou Objective-C pour Apple. Au lieu de cela, les applications hybrides ont une base de code unique qui produit une application qui s’exécutera sur les appareils Android et iOS. L’avantage est évident: moins de code et de logistique connexe par rapport à l’écriture d’une paire d’applications natives utilisant différentes langues. Les inconvénients des hybrides sont qu’ils ne sont pas aussi performants que leurs équivalents natifs et qu’ils n’ont parfois pas la capacité de tirer pleinement parti des ressources d’un appareil.

La plupart des frameworks hybrides que vous connaissez peut-être, comme Ionic, Cordova et Phonegap, s’appuient sur ce que l’on appelle un pour accomplir leurs capacités multiplateformes. Essentiellement, ils intègrent une page Web dans une application native et s’y connectent pour s’intégrer à l’appareil sous-jacent. Le problème est que les WebViews, en particulier lors de l’hébergement d’applications complexes, rencontrent des problèmes de performances et présentent d’autres limitations.

React Native fait les choses un peu différemment. Il n’utilise pas WebViews, mais plutôt un système qui lui permet de restituer des composants natifs (d’où le nom) à partir de son code JavaScript de base. Il existe une idée fausse répandue selon laquelle React Native compile JavaScript dans des langues natives telles que Swift ou Java, mais ce n’est pas le cas. Pour mieux comprendre, comparons la structure sous-jacente d’une application «Hello World» comportant un bouton étiqueté écrit en React Native à sa version iOS native équivalente:

IOS natif:

React Native:

Il est maintenant évident que la version iOS native semble « plus propre », mais ce n’est pas vraiment un problème ici. Ce qui est important, c’est que nous voyons qu’il n’y a pas de WebViews en cours d’utilisation, à la place, nous avons un ensemble de composants natifs. La pile de vues dans l’exemple React Native forme simplement la disposition réactive de base de l’application, étant donné que React Native utilise. L’impact sur les performances est essentiellement nominal et en vaut la peine, étant donné que le besoin de WebViews a été supprimé.

Cependant, il y a encore des problèmes de performances à noter lors de l’analyse de la façon dont React Native réalise cet exploit.

Dans une application React Native, sa logique JavaScript s’exécute dans un thread dédié, tandis que le reste de l’application s’exécute dans ce que nous appellerons «le domaine natif». JavaScript gère la logique métier de l’application, tandis que le domaine natif rend l’interface utilisateur et gère les interactions entre les appareils. Ces deux domaines s’appuient sur quelque chose appelé «le pont» pour communiquer.

Le thread JavaScript et le domaine natif ne peuvent pas avoir de conversation directe. Ils ne peuvent pas écouter, répondre ou annuler les événements et les opérations qui se produisent du côté opposé. Au lieu de cela, ils transmettent des messages sérialisés dans les deux sens via des files d’attente de messages asynchrones. Ce système «comble» l’écart.

Par exemple, React Native peut envoyer un message au domaine natif disant «rendre ce bouton», auquel, à la réception (c’est-à-dire la prochaine fois qu’il vérifie la file d’attente des messages), le natif le fait. Plus tard, lorsque l’utilisateur clique sur ce bouton, le natif envoie un message au thread JavaScript l’informant de l’action, déclenchant une logique d’application associée, qui se traduira alors par une mise à jour de l’interface utilisateur repoussée dans la file d’attente pour le natif … et ainsi sur.

En raison de la nature déconnectée et asynchrone de ce moyen de communication, certains problèmes de performances peuvent survenir. Les files d’attente peuvent s’enliser, par exemple si l’utilisateur fait défiler rapidement une liste longue et compliquée – de nombreuses mises à jour «l’utilisateur a fait défiler» et «dessiner cette nouvelle interface utilisateur» volent dans les deux sens. Pour une raison similaire, les animations peuvent également être un sujet de préoccupation. En réalité, la plupart du temps, ces types de déficits de performance sont négligeables pour l’utilisateur; cependant, les développeurs doivent toujours en être conscients afin de pouvoir les concevoir.

La bonne nouvelle est que des initiatives telles que (l’interface JavaScript) sont en cours de développement pour remplacer le pont par quelque chose de mieux. Les développeurs peuvent également utiliser pour compléter leur application avec du code vraiment natif afin de tirer parti des fonctionnalités spécifiques à l’appareil ou de résoudre les problèmes de performances. Cela signifie qu’avoir des développeurs familiers avec le natif dans votre équipe React Native peut être très bénéfique.

React Native continue d’évoluer, compte tenu de sa popularité et de sa communauté de soutien. Il reste un premier choix pour les développeurs et mérite d’être pris en compte pour ceux qui envisagent de créer une application.

Les deux approches du développement mobile ont des compromis notables. Il est important de prendre en compte les forces et les faiblesses de chaque option en ce qui concerne le cas d’utilisation d’une application et la structure de votre organisation:

AVANTAGES

1. Performance: C’est le facteur déterminant par rapport aux solutions hybrides, le natif l’emportera toujours. Bien que React Native ait des performances suffisantes pour la plupart des cas d’utilisation, le natif complet est mieux adapté aux applications gourmandes en ressources telles que celles utilisant la technologie 3D / AR / VR, ainsi qu’aux applications gourmandes en données ou en animations.
2. Intégration d’appareils: Native accède à toutes les capacités du périphérique sous-jacent. Cela signifie que toutes les capacités du matériel, des capteurs, des SDK et des fonctionnalités spécifiques à la plate-forme sont en jeu. Pour être concis, cela donne plus de pouvoir aux développeurs pour faire un meilleur produit.
3. Accès à de nouvelles fonctionnalités: Lorsqu’une plate-forme telle qu’Android ou iOS introduit une nouvelle fonctionnalité, les développeurs y auront accès immédiatement, souvent même avant qu’elle ne fasse son entrée dans une version publique. Cela peut s’avérer avantageux et même fournir un avantage dans les cas où la nouvelle fonctionnalité contribue à améliorer l’attrait de votre application.

LES INCONVÉNIENTS

Les inconvénients de Full Native peuvent se résumer en un mot: la logistique. En supposant que vous ciblez à la fois Android et iOS, vous devez faire la plupart des choses deux fois. Deux équipes de développement, deux bases de code, des pipelines de test et de déploiement séparés, etc. Non seulement la plupart des travaux ont doublé, mais les deux volets doivent être synchronisés, ce qui nécessite une surveillance et une planification supplémentaires. Les nouvelles fonctionnalités et les changements doivent être coordonnés et synchronisés ensemble, et des problèmes surviennent rapidement si un côté prend du retard ou diverge de l’autre. Un ensemble solide de processus est nécessaire pour assurer le bon fonctionnement des choses.

L’essentiel est que plus de temps, d’efforts et d’argent doivent être dépensés par rapport aux alternatives hybrides telles que React Native.

AVANTAGES:

1. Multiplateforme prête à l’emploi: React Native s’exécute sur Android et iOS, vous permettant de cibler les deux plates-formes à partir de la sortie d’une seule équipe de développement et d’une base de code. Cela signifie que la logistique associée à la planification, au développement, aux tests et au déploiement est plus facile. Cela se traduit généralement par un coût et un délai de mise sur le marché inférieurs à ceux du natif, ce qui en fait le principal avantage de la technologie.
2. Modules natifs: Pour aider à résoudre les problèmes de performances ou fournir une prise en charge de fonctionnalités spécifiques à la plate-forme, des modules natifs peuvent être utilisés pour compléter une application React Native. Cela donne aux développeurs la possibilité de tirer parti (au moins d’une partie) du meilleur des deux mondes.
3. Rechargement à chaud: React Native prend en charge les deux, ce qui signifie que les développeurs sont en mesure de voir et de tester rapidement les modifications au fur et à mesure qu’elles sont apportées. La possibilité de le faire sans avoir à recharger manuellement une application et à perdre son état actuel est une grande amélioration de la productivité pendant le développement. L’implémentation du rechargement à chaud de React offre un net avantage sur le flux de travail de développement et de débogage souvent plus lourd des IDE natifs.

LES INCONVÉNIENTS:

1. Performance: Comme nous l’avons vu, React Native n’est pas le meilleur choix pour les applications ayant des exigences de performances élevées – en particulier celles avec des charges de travail graphiques ou gourmandes en données. Bien que des mesures d’atténuation (comme les modules natifs ou le JSI) existent ou soient à l’horizon, cela restera toujours la principale préoccupation.
2. Sensibilisation des développeurs: Bien que souvent présenté comme une alternative à l’embauche de développeurs natifs, React Native n’existe pas en vase clos. La connaissance du pont par rapport aux plates-formes sous-jacentes est nécessaire pour éviter les pièges de performances et développer des modules natifs. React Native ne résume pas non plus le processus de soumission, d’examen et de déploiement des magasins Google et Apple associés, il est donc nécessaire d’avoir du personnel expérimenté avec cette procédure. Des ensembles de compétences mobiles robustes peuvent être nécessaires lors du choix de cette voie, sapant certains des avantages supposés de la simplicité du cadre.
3. Dépendance envers les mainteneurs: Les développeurs doivent attendre les responsables de React Native pour résoudre les problèmes et prendre en charge les nouvelles fonctionnalités. Par exemple, il existe actuellement (au début de 2020) un problème continu avec l’enregistrement audio dans certaines circonstances – cela pourrait s’avérer problématique pour les applications s’appuyant sur une telle fonctionnalité.

Compte tenu de ces mises en garde, il convient d’examiner les différentes situations où il est logique de choisir une approche plutôt que l’autre.

1. Vous avez besoin des performances que seul le natif fournit. En particulier si vous créez un jeu (et que vous n’utilisez pas quelque chose comme Unity), utilisez les capacités 3D / AR / VR d’un appareil, ou si vous créez une application autrement complexe.
2. Vous disposez des ressources et des processus nécessaires pour répondre aux exigences logistiques liées à l’exécution de deux flux de développement mobile et à leur synchronisation.
3. Vous ciblez une seule plate-forme pour votre application – Android ou iOS uniquement, et vous ne vous attendez pas à ce que cela change.
4. Vous avez besoin d’un accès direct aux capacités de l’appareil que seul le natif peut fournir.

1. Vous souhaitez créer une application multiplateforme avec un cas d’utilisation assez simple.
2. Vous souhaitez réaliser rapidement un prototype ou MVP. Même si vous envisagez d’utiliser le natif complet lors de la mise sur le marché d’un produit, React Native est idéal pour assembler rapidement quelque chose. Cela peut s’avérer être un test précieux de la viabilité du cadre pour votre cas d’utilisation donné – peut-être que le natif complet ne sera pas nécessaire après tout.
3. Vous souhaitez bénéficier des avantages logistiques d’un framework hybride: une base de code unique et un processus de développement de support, dont découle généralement une réduction des coûts.

Une application mobile n’est pas seulement un tas de lignes de code, c’est une entreprise. À ce titre, la décision de choisir un chemin plutôt qu’un autre n’est pas purement technique. La vue d’ensemble et les implications associées doivent être prises en compte pour décider si React Native ou Native Native doit être utilisé comme fondation à l’avenir.

Sur le papier, il semble logique de se développer nativement plutôt que via un cadre abstrait qui se trouve au-dessus du domaine natif. Native offre des performances supérieures et donne aux développeurs un accès complet aux capacités de chaque appareil. Il est vrai que certains cas d’utilisation nécessitent ce niveau de contrôle. Cependant, ces avantages ont un coût – au sens littéral. La duplication du travail et les efforts logistiques associés peuvent être pénalisants pour une entreprise qui n’est pas en mesure de le supporter. Dans cet esprit, il se peut qu’une approche alternative soit plus adaptée à votre situation.

Avec React Native, dans la plupart des cas, vous obtenez le meilleur des deux mondes: des efforts et des coûts et des délais de commercialisation associés réduits, tout en produisant une application robuste et performante qui résiste à sa concurrence native. React Native est souvent le choix évident pour le prototypage rapide et la production de MVP – un processus qui peut servir à évaluer si la technologie répond ou non aux exigences à long terme de votre projet. Ces avantages font de React Native une option solide pour de nombreuses organisations. Pourtant, si vous avez besoin de chevaux-vapeur purs ou si vous avez un cas d’utilisation qui l’exige, le natif peut parfois rester le chemin à parcourir.

En fin de compte, il n’y a pas de solution miracle. Une attention particulière est requise lors de la prise d’une décision aussi fondamentale. Passez en revue les avantages et les limites des choix devant vous, et n’ayez pas peur de consulter les experts lorsque vous avez besoin d’aide pour choisir un chemin ou que vous êtes prêt à commencer.