search

cnumr / best-practices

115 Web Ecodesign Best Practices
Other
411 stars 58 forks source link

Modification BP 4019# #520

Open FannyDemey opened 10 months ago

FannyDemey commented 10 months ago

Discussion: [lien de discussion]

Tâches:

Les éléments suivants sont facultatifs:

Bonjour Merci pour ce guide de bonnes pratiques open source. J'aimerai rediscuter la description de la pratique suivante : "Préférer une PWA à une application mobile native similaire au site web". Je trouve en effet que dans sa description, d'une part elle s'éloigne du problème que cherche à résoudre ce guide, d'autre part énonce des vérités qui ne sont pas juste. Je reprend précisement ci-dessous les éléments qui me font dire cela :

Je reste disponible pour échanger à ce sujet

Bien cordialement

Fanny Demey

tbroyer commented 10 months ago

Disclaimer: je n'ai pas rédigé cette BP mais j'avais (de mémoire) participé aux discussions. Je réponds ici à quelques questions mais ça ne signifie pas qu'il ne faudrait pas faire évoluer le texte. Je ne tente donc pas du tout de clore la discussion, bien au contraire.

  • "une PWA (Progressive Web App) est une solution évitant des doubles, voire des triples développements et maintenances qu'occasionnerait le développement d'une application mobile native ou hybride" => on parle de coût financier ici ou d'impact environnemental ? Si on parle bien d'impact, de quoi parle-t-on concrêtemment ? le fait d'avoir des développeurs et développeuses qui vont coder pendant plusieurs jours, et donc l'usage de leurs terminaux pour développer ? l'hébergement du code applicatif correspondant ? Cela me semble dérisoire non ? Enfin, doubler les développements, oui, "tripler", en tant qu'experte du domaine, cela me semble exagéré et me donne l'impression que ce guide est biaisé.

On parle bien du développement (le fait que ce soit dérisoire ou non va probablement dépendre du nombre d'utilisateurs finals et de la fréquence d'utilisation, parce que des systèmes informatiques qui ne sont utilisés que 3 fois par an par un ou deux utilisateurs, ça existe :shrug: même si dans l'ensemble je vous rejoins) double => web + crossplatform (Kotlin MP, React Native, Flutter) triple => web + natif Android + natif iOS

  • "permet de réduire le risque d'obsolescence du terminal mobile et une utilisation moindre de la bande passante" => en quoi faire des appels réseau depuis une PWA par rapport à depuis une application native change quelque chose concernant la bande passante ? Je trouve que ce point n'est pas justifié. Un appel réseau est un appel réseau, qu'il soit effectué depuis un navigateur en Javascript ou depuis une application native en Kotlin, Swift ou autre.

On parle ici du téléchargement de l'application, pas de son utilisation. Une PWA sera mise à jour (la plupart du temps) lorsqu'on l'utilise, et pas automatiquement par le système. Une application peu utilisée pourra être mise à jour (téléchargée) plusieurs fois "pour rien". Et pour une application qui n'est pas destinée à être utilisée hors ligne, la PWA pourra télécharger des portions de code réellement à la demande (plutôt qu'avoir à tout télécharger en amont pour une utilisation hors ligne; ou dans de nombreux cas, même si c'est moins vrai il me semble, en un seul bloc pour une application native). Je ne sais pas si c'est possible pour une application native, mais il est désormais également possible (sans trop de difficulté) de faire des mises à jour "partielles" des applications web SPA/CSR, où seules les parties de code réellement modifiées sont mise à jour, le reste pouvant être pris depuis le cache.

  • "réduire le risque d'obsolescence du terminal mobile" => Ce point me semble peu justifié. On peut très bien développer une application mobile compatible avec une large gamme de téléphone tout comme on peut inversement développer une PWA qui ne fonctionne pas sur tous les appareils.

Sauf erreur, il s'agit là essentiellement de la taille de l'application sur le système. Plus une application est grosse, plus on va remplir rapidement l'espace de stockage du terminal client, et donc inciter à son renouvellement pour un modèle avec un espace de stockage plus important. Une PWA sera vraisemblablement bien plus légère. (pour avoir vécu personnellement en tant qu'utilisateur final ce phénomène de "remplissage" à cause d'applications natives qui grossissent avec le temps –je ne connais pas la raison–, la bascule vers une PWA quand c'était possible m'avait permis de gagner du temps –et je parle de nombreux mois ici– avant de renouveler mon téléphone) Un des principaux leviers d'action pour réduire l'impact du numérique est d'allonger la durée de vie des appareils, et pour les services numériques ça signifie éviter d'inciter les utilisateurs à changer "prématurément" un matériel tout à fait fonctionnel. On parle donc ici de performance ressentie, d'espace de stockage, et d'utilisation de la batterie essentiellement, et donc sur ce point précis "natif vs PWA" de l'espace de stockage.

La PWA n'est pas un gage de qualité à ce sujet. Bien au contraire, en développant une application mobile, il est indispensable de définir la version minimale supportée par l'application, et suite à ce choix, tout au long du développement, le développeur ou la développeuse est forcé de rendre son application compatible (pour chaque API utilisé dans le code et qui n'est pas compatible avec cette version minimale, un warning apparait à la compilation. Forçant ainsi à toujours penser à ce genre de chose. Je n'ai pas connaissance sur le web de telle fonctionnalité).

Rien d'obligatoire, mais il existe des outils pour garantir qu'on utilise uniquement des APIs compatibles avec les versions de navigateurs ciblées (browserslist, eslint-plugin-compat, babel/preset-env, etc.) Mais sauf erreur ce n'était pas le sujet ici.

FannyDemey commented 10 months ago

Bonjour @tbroyer et merci pour ton retour et ton introduction qui place vraiment cet échange dans une dynamique constructive.

Je rebondis sur certains points afin de faire évoluer la reflexion, car je pense qu'effectivement que cette bonne pratique dans son contenu devrait être reformulé pour être plus factuelle.

(le fait que ce soit dérisoire ou non va probablement dépendre du nombre d'utilisateurs finals et de la fréquence d'utilisation, parce que des systèmes informatiques qui ne sont utilisés que 3 fois par an par un ou deux utilisateurs, ça existe 🤷 même si dans l'ensemble je vous rejoins) double => web + crossplatform (Kotlin MP, React Native, Flutter) triple => web + natif Android + natif iOS

Je pense qu'il faudrait reformuler un tout petit peu la phrase dans ce cas pour éviter la confusion.

Une PWA sera mise à jour (la plupart du temps) lorsqu'on l'utilise, et pas automatiquement par le système. Une application peu utilisée pourra être mise à jour (téléchargée) plusieurs fois "pour rien".

J'entend bien ton argument et bien que je le trouve valable, je trouve qu'il décrit une situation parmi tant d'autres, un "si", sur laquelle une bonne pratique générale ne peut pas se reposer. Un contre-argument valable également, c'est qu'une application une fois téléchargée, ne nécessite plus à chaque ouverture de télécharger les ressources visuelles liées à l'application, mais uniquement l'API (évidemment dans ce scénario je me base sur une situation où il n'y a pas de stratégie de mise en cache du site web. Oui c'est également un "si")

Une PWA sera mise à jour (la plupart du temps) lorsqu'on l'utilise, et pas automatiquement par le système. C'est un argument très interessant. Ca serait bien de le lister dans cette fiche comme argument.

Une application peu utilisée pourra être mise à jour (téléchargée) plusieurs fois "pour rien".

Effectivement, mais je suis pas sûre que ça soit un argument que l'on peut généraliser. Une application fréquemment utilisée, mais peu mise à jour utilisera au contraire moins la bande passante qu'une PWA sans cache (car PWA ne veut pas forcément dire stratégie de cache, juste un service worker qui peut ne rien faire. Oui je caricature bien sûr, mais simplement pour illustrer que PWA n'est pas un gage à limiter l'usage de la bande passante).

il s'agit là essentiellement de la taille de l'application sur le système. Plus une application est grosse, plus on va remplir rapidement l'espace de stockage du terminal client, et donc inciter à son renouvellement pour un modèle avec un espace de stockage plus important. Une PWA sera vraisemblablement bien plus légère. (pour avoir vécu personnellement en tant qu'utilisateur final ce phénomène de "remplissage" à cause d'applications natives qui grossissent avec le temps –je ne connais pas la raison–, la bascule vers une PWA quand c'était possible m'avait permis de gagner du temps –et je parle de nombreux mois ici– avant de renouveler mon téléphone)

Je suis pas d'accord avec ce point. Tout comme pour une PWA, une application mobile bien conçue ne fait pas grossir inutilement l'espace de stockage sur l'appareil. Justement, pour venir contre argumenter ce propos, j'ai ouvert mon application Chrome sur mon téléphone. Elle utilise sur mon téléphone 3,06 Go. Ce qui est cool c'est que l'on peut voir le détail. Et par exemple "êtreparents.com" qui est un site où je vais parfois lire des articles occupe 1,0 Go. Ryanair : 800 Mo (que je dois consulter une fois par an), Geo.fr : 500Mo. etc. J'y trouve de nombreux site que j'utilise à peine et qui occupe un espace considérable sur mon téléphone.

Est ce que tu penses que l'on pourrait retravailler la formulation de cette bonne pratique ? Je peux essayer faire un draft suite à nos échanges et ceux qui viendront potentiellement.

martinbonnin commented 10 months ago

Pour rajouter un point là dessus:

Je ne sais pas si c'est possible pour une application native, mais il est désormais également possible (sans trop de difficulté) de faire des mises à jour "partielles" des applications web SPA/CSR, où seules les parties de code réellement modifiées sont mise à jour, le reste pouvant être pris depuis le cache.

C'est possible sur Android. Par défaut, les mises à jour sont incrementales et seuls les changements sont téléchargés (source)

De manière générale, il me semble compliqué de faire une recommendation générale sur le sujet "PWA vs natif" étant donné le nombre de paramètres d'entrée. Par ex, une application qui n'est que très rarement mise à jour (ça existe et ça pourrait être une bonne pratique?) consommera surement moins en natif. Java/Swift/Rust sont généralement considérés plus économes que JavaScript. Mais peut être que cela change avec WebAssembly, etc.., etc...