Le 25/08/2020 à 22h 28

Outil non en ligne, mais qui se gère en gestion de conf, et avec un plugin vs code (qui est une app électron, donc web en passant, je suis pas chauvin): plantUML :) et notamment le modèle C4 de conception “pragmatique” pour tout ce qui est documentation d’architecture. Je vous laisse Googler !

Le 25/08/2020 à 11h 41

Le message initial n’était pas de moi ;) simplement placé d’un point de vue expérience utilisateur globale, et en partant du principe qu’on a des développeurs de compétence équivalente sur les 2 plateformes, il y a un overhead que le web a que le natif n’a pas, d’où le fait qu’il y a structurellement une différence qui peut être sensible pour un utilisateur final en terme de temps d’affichage.

Et je suis d’accord que le choix technologique reste du cas par cas et un trade off par rapport au but recherché vs moyens engagés (ça fait partie de mon travail que de conseiller spécifiquement sur ces choix de techno mobile).

Le 25/08/2020 à 09h 10

Structurellement :

• les service workers n’ont pas accès au DOM, comprendre donc que pour tout ce qui est affichage pur et dur, on reste sur du JS single threadé classique


• une PWA reste donc du langage JS interprété qui va s’exécuter en quasi totalité dans un environnement single threadé. Le temps d’interprétation du JS (et ca peut être long si on utilise des frameworks lourds type angular, qui auront eux même un temps de “boot” derrière) et son exécution single thread rendent une app web quelle qu’elle soit nécessairement et visiblement plus lente au démarrage qu’une application compilée nativement

En terme d’empreinte réseau, une PWA utilise les mêmes systèmes de cache que ce qu’on pouvait avoir avec du web classique, on a en revanche un meilleur contrôle. C’est équivalent à du natif, qui a là aussi un controle total (heureusement..!). Une app native ne va généralement venir tirer que du contenu “data”, et très peu/pas d’éléments d’interface. Faire transiter quelques kb de data, ca permet de faire des apps qui ont des temps de réponse correct même sur une connexion edge (a noter que si le caching fonctionne correctement, on peut arriver au même résultat avec du web).

En terme d’empreinte CPU/RAM, un site web est toujours plus gourmand qu’une app native : c’est logique vu qu’on ajoute de l’abstraction (on a un site, qui tourne dans un navigateur, qui tourne sur le système vs une app qui tourne sur le système, et on ajoute de l’abstraction graphique avec un DOM interprété, et logique avec du code JS là aussi interprété). Bref, ca ne peut pas battre une app compilée en terme de performance, et de sobriété.

Le grand avantage des PWA, c’est la réduction des coûts de développement pour avoir quelque chose qui s’apparente à une app mobile, en comparaison du développement de 2 apps natives (je caricature, il y a des solutions hybrides ou cross platform, mais qui sont d’expérience plus destinées à du prototypage rapide): on ne développe qu’une fois le site (il y a un overhead de tests sur différents devices, et problématiques a prendre en compte comme l’ouverture du clavier qui pourrait cacher les champs d’edition), on a une complexité de déploiement et de gestion des correctifs grandement simplifiée en comparaison d’apps mobiles qui nécessiteront plus de travail de conception et d’opération.