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
Je ne sais pas ce que tu entends par PWA (et par lent) du coup et je veux bien un exemple. Parce qu’il n’y a structurellement aucun raison. Après il peut y avoir des sites lents ou mal développés, PWA ou pas (et l’intégration dans l’OS peut jouer, notamment sous iOS pour le moment). Comme on le détaille dans l’article, les PWA ce sont surtout les SW qui n’introduisent pas de lenteur, simplement une meilleure réactivité via la mise en cache.
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.
3 commentaires
La révolution des applications web progressives (PWA)
24/08/2020
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 :
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.