Native et PWA : des choix, pas des challengers !

Il est difficile de dire exactement où le fossé entre « natif » et « Web » a vraiment commencé. J'ai l'impression que c'est l'une de ces choses qui tournaient juste sous la surface depuis les premiers jours de Flash, pour éclater plus récemment avec la montée des plates-formes mobiles. Quoi qu'il en soit, les développeurs se sont affrontés à travers ce «grand gouffre», se lançant des insultes les uns contre les autres dans le but de renforcer leur propre camp.

Je n'ai aucun intérêt dans ce combat. Bien sûr, je suis un « web guy », mais cela ne veut pas dire que je ne vois pas l'attrait du développement natif ; Je suis également développeur de logiciels. Mais je suis avant tout un pragmatique. Je réalise que chaque projet est différent et que notre approche pour chacun doit être adaptée aux besoins et aux objectifs du projet.

Avec les applications Web progressives (PWA) qui empiètent sur le territoire du développement natif, j'ai pensé que le moment était peut-être venu de prendre du recul et de faire le point sur ces deux approches de la création de produits. J'espère que nous repartirons tous avec la capacité de voir clairement les points forts de chaque approche dans l'espoir de trouver la bonne solution pour les produits que nous créons.

Une comparaison rapide

Depuis à peu près le début, les expériences basées sur le Web ont été comparées à tout, des logiciels de bureau (les "applications natives" originales) aux CD-ROM interactifs en passant par Flash et, plus récemment, aux applications mobiles. Bien qu'il ait été déclaré mort à de nombreuses reprises, le Web a persisté. Dans de nombreux cas, il a même survécu à ses tueurs présumés (RIP Flash).

L'une des principales forces du web à cet égard est sa capacité d'adaptation. Il a été capable d'aller à peu près partout où il y a une connexion Internet et continue d'acquérir de nouvelles capacités. Tous les langages de programmation évoluent, ce n'est donc pas inattendu, mais au fil du temps, les frontières croissantes du Web ont continué d'empiéter sur le territoire des logiciels traditionnels.

Cependant, un domaine dans lequel le Web a toujours échoué est celui de la performance. Les logiciels installés sont capables de se connecter au système d'exploitation sous-jacent d'une manière que le Web ne peut tout simplement pas. Ils sont écrits dans la lingua franca de leur hébergeur, avec un accès direct au matériel ou « plus près du métal » comme on dit souvent. Le Web, qui exploite presque toujours une ou plusieurs couches d'abstraction au-dessus, a du mal à rivaliser en termes de performances. Bien que l'écart de performances se soit réduit au fil du temps, le code natif continuera probablement à fonctionner plus rapidement que le code Web, au moins jusqu'à ce que le Web devienne capable d'interpréter les signaux directement à partir des broches du matériel.

Parallèlement à l'avantage des performances, le développement natif offre un accès beaucoup plus large (et plus précoce) aux fonctionnalités de l'appareil telles que NFC, Bluetooth, les capteurs de proximité et de lumière ambiante, etc. Le Web accède également régulièrement à ces fonctionnalités, mais il sera toujours à la traîne par rapport au natif, car les API natives doivent être développées avant que le Web ne puisse les exploiter et la normalisation dans le paysage du navigateur prend du temps.

De plus, le code natif peut se connecter à des fonctionnalités au niveau du système d'exploitation telles que le carnet d'adresses et les calendriers. Les notifications push étaient un autre élément important, mais les Service Workers permettent désormais au Web de tirer également parti de cette fonctionnalité. Le traitement des paiements s'est également amélioré récemment sur le Web. Peut-être que l'accès au carnet d'adresses et au calendrier arrivera également sur le Web.

Revenant un instant aux Service Workers, cet ajout récent à la boîte à outils du développeur Web a également un certain nombre d'autres astuces dans sa manche. Tout d'abord, il offre un système de mise en cache beaucoup plus robuste que le Web n'avait auparavant avec AppCache. Vous pouvez utiliser Service Workers pour gérer les demandes hors ligne, mettre en cache des ressources spécifiques, synchroniser des données avec un serveur distant lorsque l'utilisateur n'a même pas ouvert le site, et bien plus encore. Peut-être plus que toute autre technologie, les Service Workers ont permis au Web d'offrir une expérience plus proche de celle d'une application.

Les Service Workers sont l'un des trois piliers techniques des PWA. Un autre est le manifeste d'application Web. Bien que cela puisse sembler un peu ennuyeux, un manifeste d'application Web est en fait un outil incroyablement puissant dans la mesure où il permet à un site Web de se présenter comme une application. Ce format de fichier JSON relativement simple fournit une mine d'informations sur le site Web qu'il décrit et permet aux navigateurs et aux systèmes d'exploitation compatibles PWA d'installer le site comme s'il s'agissait d'un logiciel natif.

Certains magasins d'applications commencent même à indexer les PWA, en utilisant leur manifeste pour remplir leurs entrées associées. Du point de vue de l'utilisateur, les PWA dans les magasins d'applications ne sont pas différentes des applications natives qui les entourent. Ils sont installables, désinstallables et peuvent même exposer leurs paramètres à l'outil de gestion des applications du système d'exploitation sous-jacent. Il convient également de noter que les PWA n'ont pas réellement besoin d'un utilisateur pour les installer explicitement afin de les utiliser car, eh bien, elles vivent sur le Web.

Être à la fois sur et hors du Web signifie également que les PWA sont toujours à jour. Les utilisateurs n'auront pas besoin de télécharger activement quoi que ce soit de nouveau pour accéder à de nouvelles fonctionnalités. Et même lorsque de nouveaux contenus et fonctionnalités sont déployés, il est très peu probable qu'un utilisateur ait besoin de retélécharger l'intégralité de votre PWA comme il le ferait dans le cas de la plupart des applications natives. Si quoi que ce soit, ils peuvent obtenir quelques nouveaux actifs et du nouveau HTML, et cela se produirait assez instantanément, aucune boutique d'applications n'est requise. Bien sûr, vous avez toujours l'option de découverte et de distribution fournie par les magasins d'applications, donc c'est vraiment le meilleur des deux mondes.

Être dans les magasins d'applications place les PWA sur un pied d'égalité avec les applications natives en termes de découverte, de distribution et de monétisation. En fait, il peut même remplacer le Web par natif, car les PWA sont également détectables via les moteurs de recherche et sont infiniment plus partageables que les applications car elles existent sur une URL. Lorsqu'elles sont bien construites, les PWA sont également interopérables entre les navigateurs, les plates-formes et les appareils. Les PWA fonctionnent même dans les navigateurs qui ne prennent pas en charge des fonctionnalités telles que Service Workers, car les fonctionnalités PWA sont des améliorations progressives.

Le Web offre également un support d'accessibilité très mature, ce qui permet de s'assurer que vos projets sont utilisables par le plus grand nombre d'utilisateurs. Les interfaces complexes nécessitent un peu plus de diligence en matière de programmation, mais les avantages d'accessibilité offerts par le HTML sémantique gèrent l'accessibilité de base avec aplomb, en particulier lorsqu'il s'agit de produits à base de texte, d'informations ou de formulaires simples. En revanche, vous devez presque toujours connaître et intégrer les API d'accessibilité dans votre code natif.

En ce qui concerne le développement, je ne pense pas qu'il y ait un gagnant clair en matière d'expérience de développement. Chaque langue a ses fans, et il en va de même pour les outils de développement. Vous aimez ce que vous aimez et vous avez tendance à être plus efficace avec les outils et les langages que vous connaissez et qui vous passionnent. Ni le web ni le développement natif n'ont d'avantages distincts là-bas.

Cependant, là où le développement natif brille, c'est lorsqu'il s'agit d'assurer un niveau de qualité constant pour les interfaces utilisateur, construites à l'aide de leurs SDK (Software Development Kits). La plupart des SDK natifs offrent des outils pour tester les performances, la conception, les fonctionnalités, etc. Ils incluent également du code passe-partout, des systèmes de conception et d'autres outils qui contribuent à élever la barre globale des offres logicielles natives. Bien sûr, il existe des outils similaires pour le Web, mais ils sont dispersés sur le Web et ne sont pas universels dans tous les différents environnements de développement que les gens utilisent pour créer des sites Web. Il n'existe pas d'entité unique définissant des expériences Web de qualité et fournissant les outils pour les créer (bien que beaucoup aient essayé).

Lorsqu'il s'agit de doter en personnel le développement d'un produit, il est certainement plus facile d'embaucher des personnes qui savent comment créer pour le Web. Au moment où je tape, l'index des langages de programmation classe actuellement JavaScript comme le langage le plus populaire, avec Java juste derrière. C # est à la 5e place, HTML à la 7e, CSS à la 9e et Swift arrive à la 15e. Cet index fait référence aux balises Stack Overflow avec des lignes modifiées dans les référentiels publics sur GitHub, il doit donc être pris avec un grain de sel, mais il fournit une indication assez claire que de nombreuses personnes connaissent (et utilisent) les technologies Web. D'un autre côté, il peut souvent être difficile de trouver et d'embaucher des développeurs natifs talentueux, car ils sont moins nombreux et très demandés.

La rareté des talents signifie que vous finirez probablement par payer plus pour le développement natif. Chaque projet est évidemment différent et a des caractéristiques et des exigences différentes, mais il peut être illustratif de comparer les coûts de développement moyens. Comentum suggère que la création d'une application Web de taille moyenne varie entre moins de 10 000 USD et 150 000 USD. Du côté natif, Appster estime que la construction de projets d'applications mobiles de taille moyenne coûte entre 110 000 et 305 000 USD. Il est probablement prudent de supposer que les projets natifs coûteront probablement environ deux fois plus cher à développer qu'un projet Web. Et c'est par plateforme. Les applications natives prennent généralement plus de temps à se développer.

Il convient de noter qu'il existe des options pour créer des logiciels natifs à l'aide de technologies Web sans créer de PWA. Des frameworks tels que React Native, PhoneGap, Ionic et Appcelerator Titanium vous permettent de générer du code natif à partir de HTML, CSS et JavaScript. L'utilisation de l'un de ces outils pourrait réduire vos coûts de personnel et de développement par rapport à l'embauche d'une équipe de développeurs natifs, mais en termes d'accès aux fonctionnalités de l'appareil, votre projet sera limité à celles que le framework a implémentées. Planifiez en conséquence.

Une fois l'application développée, vous devez également tenir compte des coûts de maintenance continus de ladite ou desdites applications. En réponse à une enquête menée par Clutch, Dom & Tom recommande de budgétiser 50 % du prix initial du produit la première année, 25 % la deuxième année et entre 15 et 25 % pour chaque année suivante.

Une fois que vous avez une bonne compréhension de la façon dont le développement Web et natif se comparent et s'opposent, vous pouvez commencer à évaluer les forces et les faiblesses pertinentes pour votre projet. Vous devrez probablement faire des compromis, et c'est normal. Il n'y a pas de solution unique. Et s'il y en avait, ça ne conviendrait à personne.

Passons en revue quelques projets hypothétiques pour mettre plus clairement en évidence les distinctions entre le développement pour les natifs et les PWA.

Projet n° 1 : une application native existante

Supposons que vous ayez déjà suivi le processus de création d'une application native. Si tout va bien, il n'y a aucune raison de changer de cap. Ne jetez pas tout votre travail existant pour passer à une PWA, sauf si vous avez une très bonne raison de le faire. Je ne peux vraiment penser qu'à un seul scénario qui pourrait justifier d'envisager un passage à PWA : apporter la prise en charge d'un nouveau système d'exploitation dans le mix. Et même dans ce cas, cela n'a vraiment de sens que si les besoins de votre application peuvent être satisfaits uniquement par le Web.

Si vous ajoutez la prise en charge d'une nouvelle plate-forme à un produit, cela crée l'occasion idéale d'évaluer les besoins et les objectifs du projet en ce qui concerne le coût de la satisfaction de ces besoins. Si le Web n'est pas à la hauteur de la tâche, restez avec le natif. Si c'est le cas, cependant, faites une pause et considérez ceci : l'ajout de la prise en charge de la nouvelle plate-forme à l'aide d'une PWA vous permettrait de prendre en charge des plates-formes supplémentaires (y compris le Web) sur la route et pourrait même vous permettre de remplacer votre application native existante une fois que la PWA a été minutieusement testé.

Si remplacer une application native existante par une PWA vous semble impensable, considérez ceci : Starbucks et Twitter explorent déjà cette idée.

S'il existe des raisons spécifiques pour lesquelles vous devez conserver vos applications natives, il peut toujours être utile d'envisager d'externaliser certaines fonctionnalités de l'application sur le Web. Il y a quelques années, je travaillais sur un projet pour une grande entreprise de services financiers, et ils ont choisi de déplacer le flux de connexion de leurs applications natives vers le Web afin de leur permettre de déployer des fonctionnalités de sécurité plus rapidement que la boutique d'applications typique. processus d'approbation leur a permis d'atteindre. Peut-être que votre projet a des besoins similaires auxquels le Web pourrait permettre à votre application native de répondre.

Projet n° 2 : une application multiplateforme existante

Si vous avez une application existante qui fonctionne sur plusieurs plates-formes, vous déboursez probablement beaucoup d'argent pour le développement et la maintenance continus de cette application. Vous constatez également probablement des divergences dans les fonctionnalités de l'application, car chaque plate-forme native a tendance à avoir son propre calendrier de développement. L'application du détaillant Target, par exemple, permet actuellement aux utilisateurs de gérer une liste de courses sur iOS, mais la version Android n'a pas cette fonctionnalité. À bien des égards, cela ressemble à la divergence que nous voyons parfois entre les versions « de bureau » et « mobile » d'un site Web.

Si le Web fait déjà partie de votre mix multiplateforme, c'est une bonne occasion de doubler vos investissements et d'envisager de remplacer vos applications natives par des PWA. Des outils tels que sonar et Lighthouse peuvent vous donner un aperçu de la préparation de votre site existant pour la PWA-ification et ils peuvent également vous dire sur quoi vous devez travailler. À partir de là, transformer votre site Web en PWA est relativement simple. Il existe même des outils gratuits qui peuvent vous aider à mettre à niveau votre site vers une PWA en quelques minutes. Si ce n'est pas le cas, cependant, il n'y a vraiment pas beaucoup d'incitation à faire ce mouvement à moins que la divergence des fonctionnalités entre les plates-formes ne devienne vraiment flagrante ou que vous envisagiez d'ajouter encore une autre plate-forme native (ou le Web) dans le mélange.

Projet #3 : Un nouveau produit multiplateforme

Si vous lancez un nouveau projet destiné à plusieurs plates-formes, sa création et sa maintenance au même endroit en tant que PWA doivent absolument être sur la table. En fonction de votre budget et de votre personnel, il est probable que votre budget soit le plus étiré. Cela dit, si votre produit nécessite une connexion directe au matériel ou au système d'exploitation sous-jacent, vous devrez peut-être toujours passer au natif. Mais avant de vous engager dans cette voie, dressez une liste de toutes vos exigences, puis vérifiez ce que le Web peut faire (et ce qu'il ne peut pas). Assurez-vous également de vérifier la prise en charge de plusieurs navigateurs.

Projet #4 : Un nouveau produit hyper ciblé

Si vous construisez un nouveau produit et qu'une partie de l'objectif de ce produit est sa connexion profonde à une plate-forme particulière, par tous les moyens, construisez pour cette plate-forme. Par exemple, si votre produit s'appuie sur la plate-forme Messages d'Apple ou sur l'intégration avec HomeKit, par tous les moyens, créez pour iOS et/ou macOS dans Swift. Si votre produit répond le mieux aux besoins des utilisateurs via un widget ou si vous créez un lanceur personnalisé, vous feriez mieux de créer Android et vous devrez utiliser Java.

Cependant, toutes les caractéristiques indigènes ne sont pas des jardins clos. Alors qu'Alexa d'Amazon, Siri d'Apple et l'assistant Google nécessitent tous un code natif (ou une API JSON) pour s'intégrer à votre application, il est intéressant de noter que Cortana de Microsoft activera votre PWA en utilisant uniquement un fichier XML lié à l'en- head de votre code HTML. Peut-être que d'autres suivront leur exemple.

PWA ou natif ? Le choix t'appartient

Le web et le natif ont chacun beaucoup à offrir. Si vous me demandiez ce qui est le mieux, je répondrais simplement "Ça dépend" parce que c'est le cas. Je ne suis pas évasif ou évasif ; déterminer ce qui convient le mieux à votre projet dépend entièrement des besoins spécifiques de votre projet. Cela nécessite de prendre en considération ce que vous construisez, la composition de l'équipe existante chargée de le construire ou de l'équipe que vous devrez embaucher pour le faire, et le budget avec lequel vous devez travailler. Dans de nombreux cas, le Web offre probablement tout ce dont vous avez besoin pour atteindre les objectifs de votre projet, mais il y a toujours des exceptions. Si vous souhaitez explorer les possibilités offertes par le Web, j'ai inclus quelques ressources à la fin de cet article.

La chose la plus importante que vous puissiez faire lorsque vous pesez différentes approches du développement logiciel - ou différents frameworks, bibliothèques, langages, systèmes de conception, etc. - est de considérer vos options par rapport au projet en cours. Faites vos recherches et pesez vos options. Et ne vous laissez pas influencer d'une manière ou d'une autre par un marketing intelligent, des démos sexy ou des fanboys enragés. Y compris celui-ci.

Ressources liées aux PWA

• Constructeur PWA
  Un outil de création de site Web à PWA en 3 étapes avec des recommandations et des recettes utiles. Il vous permet également de transformer votre PWA en applications natives installables pour Windows, Android et iOS.
• Une feuille de route progressive pour votre application Web progressive
  Jason Grigsby explique comment son équipe a commencé à intégrer des aspects des PWA dans son site Web au cours de plusieurs mois, démontrant bien comment les différentes fonctionnalités peuvent être ajoutées un peu à la fois.
• Oui, ce projet Web devrait être un PWA
  Un aperçu des opportunités (et des risques) UX des PWA, rédigé par votre serviteur.
• Applications Web progressives sur MDN
  Un hub pour tous les éléments techniques que vous devez savoir sur ce qui caractérise une PWA de qualité.
• Ce que le Web peut faire aujourd'hui
  Jetez un œil aux API prises en charge par votre appareil, votre système d'exploitation et votre navigateur. Ce que vous découvrirez pourrait vous surprendre.
• Puis-je utiliser
  La base de données définitive des API et des fonctionnalités disponibles dans tous les principaux navigateurs et de la manière dont cette prise en charge est à la hauteur des navigateurs que les utilisateurs utilisent réellement. Cela peut également vous donner une excellente vue dans le temps pour voir à quel point certaines fonctionnalités sont rétrocompatibles.