4 façons de créer des applications cross-plateformes à l’aide des technologies Web

Dans cet article, nous allons passer en revue quatre façons majeures d’utiliser les technologies Web pour créer des applications cross-plateformes. L’idée est de vous aider à décider quand et comment réutiliser vos compétences web pour avoir la plus grande portée possible, à décider du niveau de richesse de l’interface utilisateur dont vous avez besoin et à essayer de partager autant que possible votre code JavaScript.

Traduit de l’anglais avec la permission de David Rousset. Retrouver l’article original.
Cet article est bien sûr non-exhaustif. David Rousset parle de 4 manières que lui a identifiées, et il exprime ici son avis personnel.

Il existe de très nombreux langages de programmation et de frameworks. Il est impossible de les connaître tous, il n’existe pas non plus de combinaisons spécifiques pour les gouverner tous. Le choix se fait en fonction de vos préférences, de vos besoins et des exigences du projet ainsi que des compétences présente chez les membres de votre équipe.
Commençons tout d’abord avec la plus évidente des solutions, celle à laquelle vous devriez penser en premier si vous vous lancez dans un projet de création d’application cross-plateformes à l’aide de technologie du web : PWA, Progressive Web app.

Progressive Web App (PWA)

En résumé, une PWA est une application web utilisant les dernières fonctionnalités disponibles pour ressembler le plus possible à une application native. Par exemple, elle peut aussi bien être installée sur un ordinateur de bureau que sur mobile. Elle fonctionnera parfaitement hors ligne et devra utiliser une approche d’interface utilisateur moderne. Basée sur des standards, elle fonctionne sur plusieurs plateformes (Windows, Mac, Android et iOS) et il peut même s’exécuter dans n’importe quel navigateur web de votre Smart TV, par exemple.

Le minimum viable que vous devez implémenter pour dire que vous construisez une PWA est le suivant :

• HTTPS. Une PWA doit être servie sur un canal sécurisé.
• Un Manifest. Un petit morceau de JSON décrivant le comportement de votre PWA ou son installation.
• Service Worker. La partie essentielle de votre PWA permet un véritable scénario hors ligne et améliore les performances de votre application Web.

Grâce au manifeste de l’application web, vous pouvez être sûr que votre application utilise directement la bonne orientation. Pour les applications de jeux par exemple, le gameplay est souvent optimisé pour fonctionner en mode paysage.

Le Service Worker est un bon de code JavaScript se comportant comme un proxy client entre votre page web et le serveur. Vous devez d’abord l’enregistrer et une fois installé, il sera capable de récupérer toutes les requêtes envoyées par votre page web au réseau.

Selon la logique de votre application et l’expérience ciblée, vous avez plusieurs stratégies possibles pour gérer le cache du Service Worker. PWA Builder fournit divers agents de service prêts à être utilisés. Vous devrez probablement adapter leur code pour répondre parfaitement à vos besoins, mais c’est un bon point de départ.

Il est possible de coupler un Service Worker avec IndexedDB. Ce qui fournit une expérience hors ligne qui devrait être disponible juste après le premier chargement complet de la page web. Comme une application native normale.

Nous venons de décrire certains des principaux avantages fournis par les PWA. Cependant, même si la plateforme web a fait des progrès impressionnants en termes de fonctionnalités, il subsiste certaines limitations par rapport aux applications natives.

Alors quels sont les avantages et les inconvénients des PWA lorsque vous souhaitez créer une application :

• • C’est une simple page web 
    • Mises à jour facile sur le serveur web
    • Même code partout
    • Utiliser votre framework préféré (Angular, Vue, React) ou votre langage préféré (TypeScript, JavaScript)
• Marche sur n’importe quel appareil
• Indexable

Les inconvénients :

• Même UI/UX sur toutes les plateformes
• N’a pas (toujours) un accès complet à la plateforme

En effet, même si vous soumettez votre application sur le Windows Store, les mises à jour seront effectuées sur le serveur web hébergeant votre PWA et seront immédiatement répercutées sur le périphérique de l’utilisateur. Bien sûr, vous devrez passer par le processus de validation la première fois. Mais les futures mises à jour seront beaucoup plus rapides à installer sur le périphérique qu’une mise à jour d’une application native classique, dans laquelle un nouveau package doit être forcé à chaque fois.

Si vous ne publiez pas depuis un store, cela reste un site web. Le web offre de loin la plus grande portée possible aujourd’hui, chaque appareil étant doté d’un navigateur web. Il est également facile d’être indexé par les moteurs de recherche. Les deep linking font partie du web, alors que cela peut être difficile à implémenter dans une application native.

Bien sûr, tout n’est pas parfait avec une approche PWA. Vous aurez la même UI et UX sur toutes les plateformes. Si vous devez différencier l’UX sur une plateforme spécifique pour adopter son langage de conception spécifique, ce n’est pas chose facile. En outre, comme indiqué précédemment, vous n’avez pas toujours un accès complet à la plateforme. Si votre application doit par exemple échanger avec un périphérique USB, cela pourra poser un problème.

Quelles sont les options pour résoudre ces inconvénients ?

Electron

Vous avez probablement déjà utilisé une application Electron sans le savoir. Visual Studio Code, Microsoft Teams, Slack, Skype ou Discord sont tous basés sur Electron, pour en nommer quelques-uns. Electron peut créer un package pour votre application web existante, qui peut être une PWA, et l’étendre sur le bureau pour supprimer les obstacles évoqués dans la section précédente. Il cible uniquement les ordinateurs de bureau : Windows, MacOS et Linux. Electron ne peut pas cibler les appareils iOS ou Android.

Electron package votre application web avec les fichiers binaires Chromium et Node.js. Cela signifie que chaque fois que vous installez une application Electron, celle-ci installe une copie complète de Chromium et de Node.js.

Il existait un important delta entre la version de Chromium livrée avec le projet Electron et la version officielle de Chrome. Cela a récemment été réduit. Par exemple, la version stable Electron 3.0 a été livrée en septembre 2018 avec Chromium 66. Vous pouvez trouver des versions plus récentes de la version Electron livrée avec Chromium 68 ou 69. Néanmoins, Electron a généralement deux mois de retard sur les dernières versions publiques de Chrome / Chromium. Cela signifie que vous ne pourrez pas coder en utilisant les toutes dernières fonctionnalités livrées avec Chrome dans une application Electron. Garder cela à l’esprit. Mais vous devrez simplement attendre quelques semaines avant que la version Chromium livrée dans la branche Electron soit disponible.

Une application Electron peut mieux intégrer l’environnement de bureau. Comme expliqué dans leur documentation, vous pouvez définir les documents récents, gérer les notifications ou glisser/déposer des fichiers hors de l’application par exemple. Vous pouvez également avoir accès au système de fichiers via Node.js comme expliqué dans ce document : Electron Application Architecture.

Comme le montre le schéma ci-dessus, Electron fournit une couche d’abstraction via un ensemble d’API. Vous pouvez alors avoir un code JavaScript commun ciblant plusieurs plates-formes, le lien étant réalisé par ces API. Mais vous pouvez également utiliser ou écrire un plug-in natif Node.js pour passer des appels spécifiques à la plate-forme si nécessaire.

Encore une fois, pour vous aider à décider si Electron pourrait être un bon choix pour vous, voici les avantages et inconvénients :

• Utilisez votre pile web préféré (front + node.js)
• Contrôle du moteur de navigation
• Peut interagir avec le système via des appels natifs
• Linux/MacOS/Windows facilement ciblé

Inconvénients :

• • Intégration complète de node.js et Chromium 
    • Taille
    • Mise à jour sécurité de Chrome
• Uniquement sur le bureau
• Interface Utilisateur

Vous pouvez utiliser un site web ou une PWA existant pour l’intégrer à une application Electron. Il n’est pas nécessaire d’apprendre quoi que ce soit du côté du développement, car elle s’appuie sur une pile très commune que toutes les développeurs web connaissent et adorent. Avec l’intégration de Chromium, vous avez la garantie de disposer d’un moteur de rendu et d’une VM JavaScript unique pour la validation de votre code. Par rapport à une PWA standard, vous pouvez aller encore plus loin en effectuant des appels d’API natifs via la couche Node.js.

Cependant, il y a évidemment des inconvénients. Tout d’abord, la taille de votre package d’installation. En effet, vous n’utiliserez pas le navigateur déjà installé sur la plateforme, car vous installez le vôtre dans votre package. Cela signifie également que vous serez responsable de la mise à jour du navigateur intégré. Si un problème de sécurité est découvert dans la version de Chromium packagée, votre application peut constituer une violation de la sécurité du système de l’utilisateur. Vous devez faire attention, alors qu’avec une PWA classique, il incombe au fournisseur du navigateur de mettre à jour et de maintenir le produit sur lequel vous travaillez.

Enfin, Electron ne cible pas les plates-formes mobiles iOS et Android. Pourtant, rien ne vous empêche de déployer votre application en tant que PWA pour ordinateurs de bureau et mobiles et de la packager en tant qu’application Electron pour offrir une version plus avancée pour les ordinateurs de bureau. Enfin, la plupart du temps, vous implémenterez la même interface web UI / UX qu’une application web classique, même s’il est démontré plus haut que rien ne vous empêche d’adopter le langage de conception de plateforme.

Hybrid web app

Une autre façon de contourner les obstacles liés aux PWA consiste à utiliser une approche hybride. Hybride signifie que vous allez créer une «application native » avec un composant WebView qui hébergera votre application web. Ensuite, vous utiliserez une interface entre ce composant WebView et l’application native pour effectuer des appels natifs vers la plate-forme à partir de votre code JavaScript. WebView peut utiliser 100% de la mise en page de votre application ou une partie de celle-ci.

Dans les deux cas, votre application sera considérée comme hybride. Vous pouvez par exemple n’utiliser qu’une petite partie de la mise en page de votre application pour intégrer un service de carte web. Dans notre cas, nous ne parlerons que de la mise en page complète WebView, nous ne parlerons pas des composants natifs dans cette section.

Il existe 2 options pour créer une application hybride :

• Apache Cordova
• Votre propre application native avec WebView à l’intérieur 
  • XAML / C # ou C++
  • Swift / Objective C
  • Java, etc

Mais si vous utilisez la deuxième option, vous devrez gérer vous-même la communication entre la WebView et son code JS avec le code natif. C’est pourquoi le choix le plus évident à considérer est Cordova.

Cordova vous propose un cadre qui simplifiera la communication entre votre code JS résidant dans la WebView et la plateforme native via des plugins. Ces plugins exposent des API JS que vous pouvez appeler à partir de votre code, puis ce dernier effectue des appels d’API natifs pour vous.

Un certain nombre de plugins disponibles par défaut dans Cordova fournissent divers services tels que l’état de la batterie, l’accès aux fichiers, les vibrations, etc. Ces fonctionnalités ne sont souvent pas disponibles dans les navigateurs. Vous pouvez également rechercher des plugins existants ou écrire les vôtres. Le plugin doit être écrit dans le langage natif de chaque plate-forme ciblée : Objective C ou Swift pour iOS, Java pour Android, C # / C ++ pour Windows, etc. L’écriture d’un plugin nécessite donc des compétences spécifiques.

Le code de votre application web (HTML / CSS / JS), comme Electron, peut être directement intégré au package de l’application ou hébergé sur votre serveur web.

Cordova vous aide ensuite à accéder aux API de la plateforme à partir de JavaScript. Mais qu’en est-il de l’UX et de l’UI que vous allez construire ?

Vous avez 2 choix pour l’interface utilisateur :

• Offrir la même interface utilisateur sur toutes les plates-formes qu’une application web standard ou un PWA
• Adopter l’interface utilisateur de la plateforme ciblée

Si votre application s’exécute dans une WebView, se servir de l’expérience utilisateur du portable en utilisant uniquement du CSS / HTML et JS n’est pas chose simple. Même un simple curseur iOS ou Android peut nécessiter beaucoup de travail pour être construit avec HTML / CSS et imiter le plus près possible le contrôle natif.

C’est pourquoi vous pouvez utiliser un autre framework, sur Cordova, pour vous aider dans cette partie, Ionic est très populaire.

Il propose un ensemble de contrôles qui modifieront leur apparence et leur comportement en fonction de la plate-forme sur laquelle ils s’exécutent. Il utilise une approche de composant Web moderne via Stencil.js. Même si l’UX et l’UI proposée par Ionic sont impressionnantes, elle n’est pas encore tout à fait identique aux contrôles natifs.

Les applications hybrides constituent alors une autre approche intéressante à prendre en compte, mais quels sont leurs avantages et inconvénients ?

• S’intègre mieux au hardware et aux plateformes via des plugins qu’une PWA
• Peut avoir une apparence très similaire aux commandes natives grâce à Ionic

Inconvénients :

• Pas encore une pure expérience native 
  • Performance
  • UX

Cordova est souvent utilisé pour cibler les plateformes mobiles, même s’il est parfaitement adapté aux ordinateurs de bureau. Par rapport à Electron, il n’est pas livré avec un moteur de navigation unique (Chromium) mais repose sur la WebView de la plateforme déjà installée (Safari basé sur iOS, Chrome sur Android, Edge sur Windows, etc.). Il peut également faire des appels vers la plateforme native et briser certaines des barrières d’une PWA normal. En ce qui concerne l’UX, vous pouvez offrir à vos utilisateurs une interface de type natif grâce à Ionic.

Ce n’est pas encore une véritable expérience native. Les performances varient en fonction du moteur de rendu et du moteur JavaScript de la plateforme cible. Un périphérique lent peut clairement montrer certaines différences par rapport aux contrôles de l’UI native. Enfin, même si le travail réalisé par Ionic est impressionnant, l’UX ne sera jamais parfaitement à la hauteur de l’UX natif.

Néanmoins, grâce à cette approche, nous pouvons parfaitement imaginer avoir une PWA partagé et étendu sur plusieurs plateformes. Une grande partie du code, sinon tout, sera partagé. Avoir une UX mobile non parfaite pourrait tout à fait avoir du sens pour vos utilisateurs ciblés.

JavaScript – driven Native

Jusqu’à présent, nous avions trouvé différentes façons de passer des appels aux API de la plateforme (PWA Windows 10, Electron ou Cordova), mais nous n’avons jamais réussi à trouver une solution parfaite pour la partie interface utilisateur. Néanmoins, ces solutions pourraient être utilisées pour partager presque 100% du code JS ainsi que du code HTML / CSS de l’interface utilisateur.

JavaScript driven Native utilise les contrôles natifs des plateformes et propose cette solution d’interface utilisateur parfaite que vous pourriez rechercher. Son approche consiste à ne conserver que le code JavaScript en commun avec d’autres plateformes (qu’il s’agisse d’Electron ou de PWA) et de ne cibler que les plates-formes mobiles. Vous devrez réécrire les vues pour utiliser un nouveau langage ciblant simultanément les contrôles natifs iOS et Android. Ces vues, ainsi que la couche métier, seront gérées par JavaScript.

Aujourd’hui, deux frameworks utilisent cette approche : Telerik NativeScript et Facebook React Native. Les deux sont très similaires dans leur approche. Le choix entre l’un d’eux dépendra de vos compétences existantes. Vous utilisez déjà Angular ou Vue ? NativeScript sera probablement un chemin naturel. Vous êtes un maître de React.js ? React Native est la voie à suivre. Mais encore une fois, il n’y a pas de choix absolu. Avant de prendre votre décision finale, vous devez évaluer en profondeur cette approche ainsi que les deux cadres de mise en œuvre.

NativeScript Telerik :

NativeScript fournit non seulement une déclaration d’UI basée sur XML pour générer des contrôles natifs pour chaque plate-forme, il se connecte également aux API de la plate-forme via un SDK JavaScript.

La mise en page est décrite en utilisant un langage XML que vous devrez apprendre. Mais c’est plus évident si vous avez déjà construit des applications natives (XAML ou Android utilisent des approches XML). Les contrôles (Label, StackLayout ou GridLayout affichés dans la vidéo) sont mappés sur leurs contrôles natifs correspondants sur iOS / Android. La structure du projet ressemble celle d’un projet Angular avec des fichiers .HTML, .CSS et .TS. Le style des contrôles natifs peut être réalisé via CSS.

React Native :

React Native est très similaire à NativeScript, offrant le même ensemble d’outils pour tester ou déboguer à distance, par exemple. L’idée est de décrire votre logique métier et vos vues en JavaScript et de supprimer le besoin d’une expertise en UI native. La logique métier sera partagée sur toutes les plateformes en JavaScript : iOS, Android, Web et MacOS. La philosophie de Facebook est “Learn Once, Write Anywhere”. React n’est pas quelque chose de facile à apprendre. Mais une fois que vous comprenez comment cela fonctionne, c’est une belle approche.

Les composants de React Native sont également écrits en JSX. Mais cette fois, les propriétés et les états sont liés aux vues natives. Cela signifie que vous pourrez réutiliser vos compétences dans React.js, mais vous devrez évidemment réécrire vos vues pour que React Native utilise le langage approprié pour les composants natifs.

JavaScript Native est-il la solution ultime ? Bien sûr que non, mais il y a de très bons points positifs :

• Riche Native UI & intégration parfaite de la plateforme
• Réutilisez votre couche métier écrite en JavaScript
• Ciblez iOS et Android avec un code d’UI unique.

Les inconvénients :

• Besoin d’apprendre la syntaxe des controls natifs
• Le débogage peut être beaucoup plus complexe que juste frapper F12
• Moins de portée que les PWA

Cette approche est actuellement très populaire et présente de grands avantages. Mais elle est encore relativement récente et les réactions des équipes qui l’utilisent doivent être lues avant de prendre cette direction.

JavaScript Native est très prometteur et offre une solution parfaite pour atteindre une UX native en utilisant les technologies Web. Mais cela a un coût : une complexité ajoutée par les couches requises en plus de votre code JS pour gérer la communication avec la plateforme. Cela signifie que vous devrez probablement parfois étendre le framework choisi pour créer votre propre composant natif. Ou vous allez vous battre avec des problèmes de débogage.

Néanmoins, il semble tenir ses promesses la plupart du temps : ciblant les 2 plateformes mobiles, grâce à un code d’interface utilisateur unique, il utilise les contrôles UX et UI natifs de chacune, alimentés par un code de couche métier JS unique partagée sur toutes les plateformes.

Pour conclure, si vous décidez de vous lancer dans la création d’une application multi-plateformes avec l’aide des technologies du web, une PWA devrait être la première solution que vous examinez. Elle a la plus grande portée, la plus grande portabilité et la technologie est maintenant assez mature pour être utilisée en production sans problème. Son support est disponible partout, et sa partie progressive la rendra de toute façon compatible avec les navigateurs plus anciens. Microsoft compte d’ailleurs beaucoup investir dans les PWA dans les années à venir.

Ce n’est bien entendu pas la solution parfaite. Les PWA connaissent deux limitations majeures : il n’y a pas d’UX native et vous n’aurez pas un accès complet à la plateforme (sauf sous Windows 10). Si cet élément vous dérange trop ou que vous êtes un développeur Angular, Vue ou React il existe des combinaisons qui pourront vous intéresser. En voici quelques exemples :

PWA + JavaScript Native pour les mobiles

PWA + Electron pour le bureau

PWA + Electron + JavaScript Native

N’oubliez pas qu’il n’y a pas de réponse absolue. Il faut avant tout penser à l’UX que vous souhaitez offrir à vos utilisateurs, au niveau de portabilité dont vous pouvez avoir besoin et aux besoins d’intégration natif nécessaire. Enfin, il faut prendre en compte les compétences existantes des équipes en place, et de la courbe d’apprentissage potentielle associée à l’introduction d’une nouvelle technologie.

Questions Fréquentes