Bonjour à tous ! Je m’appelle Hubert SABLONNIÈRE, je suis développeur Web et je bosse pour OpenDevise. Aujourd’hui j’ai envie de vous parler de mes vacances au ski. Ça fait plusieurs années que je pars avec le même groupe, et l’organisation est plutôt bien rodée. En fait, chaque année,
début septembre, deux de mes potes se lancent dans la recherche d’une station sympa et du chalet qui répondra à tous nos critères. Il faut un truc qui puisse accueillir une douzaine de personnes pour bouffer,
pour dormir, il nous faut des portes bien épaisses pour les couples, que ce soit pas trop cher mais un peu quand même pour avoir un sauna.
Une fois qu’ils ont trouvé la perle rare, ils s’attèlent au mail de lancement !! Il y a un peu de bla-bla à rédiger, il faut aussi ajouter les bons liens vers le chalet et la station, du coup en général, pour des raisons de confort, ils préfèrent utiliser le site Desktop. Une fois le mail envoyé,
Ils attendent, les gens répondent à leur rythme… Cette année, j’étais dans mon canap quand j’ai eu la notification push via l’application Gmail sur mon téléphone. Du coup j’ai ouvert le mail sur mon téléphone pour voir les détails et je commence à cliquer sur les liens. Ahh, cool, ils ont trouvé un chalet sur le bon coin. Bon par contre, fin d’année dernière, le site était pas du tout adapté pour les mobile, et puis même si depuis le mois de mars,
ils ont enfin un site responsive, je préfère passer sur mon PC. Ça me permet de faire mon choix en voyant les photos en grand.
Hum pas mal le chalet ! Je valide !!
Jusqu’ici rien d’extraordinaire,
ils ont partagé un lien doodle pour recenser les gens motivés. J’utilise le site Desktop parce que j’étais déjà sur mon ordi. Je valide mon inscription et c’est parti. Alors, une fois que tout le monde a répondu et que le chalet est confirmé on peut enfin passer à l’étape 2 le pognon ! Bah oui, il faut rembourser le pote qui a payé l’accompte. Il accepte pas encore les bitcoins, du coup, il nous envoie son IBAN et là c’est le festival des mecs qui font répondre à tous juste pour dire "c’est bon, j’ai payé".
La plupart du temps, pour un virement, j’utilise l’appli native de ma banque. Quand j’ai déjà mon pote dans mes bénéficiares, ça va vraiment super vite.
Etape 3 : le train J’ai un pote qui propose tjs de se lever à 6h du mat' pour choper les meilleurs tarifs pour les autres sur voyage-sncf. Moi en général, je préfère prendre mes billets moi-même sur Captain Train. Pour commander, je préfère utiliser le site Desktop, par contre avant et pendant le trajet, j’utilise l’application native. Au moins je suis certain de pouvoir choisir ma place,
et d’être installé tranquillement.
Dernière étape : la semaine de ski A douze, ça devient vite pratique d’avoir un chat de groupe pour se retrouver et se synchroniser. En général, on utilise Facebook Messenger sur nos mobiles. Au niveau des comptes, c’est souvent moi qui m’en occupe.
J’utilise Tricount. Je peux saisir les dépenses au fur et à mesure sur l’appli native et à la fin de la semaine, je partage un lien hypertexte avec le bilan de qui doit combien à qui. On termine par un dernier festival d’envois d’IBAN et de remboursements et tout est bien qui fini bien.
Alors normalement vous n’êtes pas venus ici pour savoir si je suis goofy ou regular. Du coup on va plutôt s’intéresser aux différents services que j’ai utilisés avant et pendant ma semaine de vacances. Le premier point intéressant, c’est que j’ai parfois utilisé mon ordi et parfois mon téléphone. La plupart du temps, l’utilisation d’un device donné n’est pas volontaire,
c’est le contexte qui l’impose. En fonction du lieu et des différents moments de la journée, j’utilise des devices différents. L’usage a aussi une influence sur le device utilisé.
Si je regarde un chalet pour une semaine de ski, que le site soit adapté aux mobiles,
ou pas, je vais préférer utiliser un écran plus grand pour regarder les photos.
La deuxième question intéressante, c’est pourquoi nos utilisateurs installent des applications natives et pourquoi ils naviguent sur des sites Web. Déjà sur Desktop, y a pas photo. Le Web a transformé les usages, on installe de moins en moins de logiciels et nos navigateurs sont carrément devenus des OS applicatifs. Par contre sur mobile l’application native est reine. Le slogan de l’iPhone "il y a une application pour tout" y est pour beaucoup. Les utilisateurs veulent un bouton sur l’écran d’accueil, et ils se sont habitués à un certain niveau d’interactions et d’animations riches.
Je peux saisir une dépense même sans connexion,
je peux recevoir des notifications push,
je peux partager ma position GPS,
et surtout, si je tape un message dans le funiculaire,
il sera envoyé tout seul dès que ma connexion est de retour.
Du côté du Web c’est un peu moins glorieux. Les utilisateurs boudent un Web mobile qui a longtemps eu un gros retard technologique. Les sites mobiles et responsives qui sortent du lot sont rares.
La plupart du temps, on a une bonne page qui "donne le choix" à l’utilisateur. [magie] Installe mon application!!! Ou alors poursuit à tes risques et périls sur une version non optimisée.
En gros ça veut dire site Desktop, t’as pas le droit de dézoomer et les menus se dévoilent au hover de la souris que tu n’as pas. Bon pour une banque, on est dans un usage récurrent, du coup ça a du sens d’installer une appli dans la durée.
Mais quand je clique sur un lien, je suis dans l’éphémère, j’ai pas envie d’installer une application. J’ai juste envie de répondre au sondage et de me barrer alors avec la moitié de l’écran qui est réservé à des bannières pourries, c’est un peu compliqué.
Si on en est arrivé là c’est parce que pour une marque, une startup ou une DSI, pour nous qui développons des services, le choix est difficile.
On a en tête que sur mobile, un développement natif est préférable à un développement Web. On argumente en parlant de mode hors-ligne, de push et de notifications, d’intégration avec l’OS et bien entendu de performances.
On termine de s’auto-convaincre en regardant les stats. "Whouaa, mais en fait les utilisateurs ils passent tout leur temps sur des applications natives." C’est là qu’on revient à l’étape 2 le pognon ! Et on se dit que si on fait du natif, ça va couter 2 fois plus cher!
Bon bah "3 fois plus cher alors!"
Du coup, on a inventé les applications hybrides en pensant qu’on avait trouvé la solution. On fait du Web mais on a tous les avantages du natif.
Bon ok, on fait pas du Web, on utilise des technos Web. Je chipote mais la grosse différence entre natif et Web, et je range tout ce qui est hybride dans la catégorie natif, à savoir PhoneGap, React Native, etc…
la grosse différence, c’est les liens hypertextes. C’est la plus grande force du Web depuis qu’il existe.
C’est grâce au liens hypertextes que sur le Web, on peut se construire une audience bien plus large. Parce que oui, les utilisateurs passent beaucoup de temps sur les applications natives (ou hybrides),
mais en moyenne par mois, 65% d’entre eux n’installent aucune application.
En fait si on regarde de plus près,
25% des applications sont abandonnées après la première utilisation,
42% du temps est passé sur l’app la plus utilisée,
et 3/4 du temps est passé sur les 4 apps les plus utilisées.
Non ce qu’il faudrait c’est qu’on puisse avoir vraiment le meilleur des deux mondes. Avec tous les avantages et sans les inconvénients. C’est a peu près ce que Google, Mozilla et Opera,
nous promettent avec les Progressive Web Apps. Wouaah, nouveau buzzword !! D’abord, c’est pas une techno, c’est un terme marketing pour décrire un site Web moderne qui a pris les bonnes vitamines. Les termes marketing, dans le monde du dev, on en a besoin. Le seul impératif, c’est que ça veuille dire quelque chose. On veut éviter les clients qui demandent des sites développés en Web 2.0.
En 2005, alors que l’XMLHttpRequest existe en spécifique dans IE depuis quelques années, Jesse James Garett décrit l’AJAX, une nouvelle manière de concevoir un site Web en faisant des mises à jour partielles de la page avec des XMLHttpRequest.
On a vécu la même chose récemment. En 2010, Ethan Marcotte nous décrit le Responsive Web Design. Il vient poser les bases de l’utilisation de grilles fluides et surtout des media queries.
Ces termes se basent toujours sur un standard du Web établi ou en devenir. De la même manière, les Progressive Web Apps se basent principalement sur les Service Workers.
Dans un article de juin 2015, Alex Russel nous décrit une nouvelle génération de sites Web qui commencent leur vie comme les autres, dans un onglet de navigateur et qui terminent sur l’écran d’accueil avec la même expérience utilisateur qu’une application native. Son article énumère 10 attributs qui caractérisent ces sites Web.
Progressive. Ces sites doivent s’adapter aux capacités du navigateur. L’amélioration progressive est à la base du concept. On part de l’expérience de base, on la développe avec les technos les plus basiques, et ensuite on améliore avec du CSS, du JavaScript et les capacités modernes des navigateurs.
Ça permet également de mieux gérer les erreurs. A l’inverse d’un ascenceur, quand un escalator tombe en panne, ça re-devient un escalier.
Responsive. Ces sites doivent s’adapter à n’importe quel taille d’écran,
Un peu comme l’eau, nos contenus doivent prendre la forme du contenant.
Connectivity independent. L’idée c’est d’éviter ce que j’appelle l’effet Jurassic Park. C’est toujours là où il y en a un qui me dit mais on est tous connecté, on a la 4G, la fibre tout ça. Ces gens là font complètement abstraction de la loi de Murphy et dans notre métier ça peut couter cher.
Il faut penser offline-first.
Flipkart, un des plus gros sites de e-commerce indien est en ce moment un des exemples de Progressive Web App les plus abouti.
Quand on passe en mode hors-ligne, le site fonctionne toujours et au niveau UX, ils ont choisi de passer l’interface en noir et blanc. Si j’ai déjà la page produit dans mon cache,
Je peux naviguer dessus.
App-like interactions. Toujours dans un soucis de performances, on va pousser…
l’architecture "Application Shell". On a d’un côté la coquille composée des éléments statiques du site : menu, barres d’outils etc… qu’on va pouvoir mettre en cache et d’un autre côté les contenus dynamiques.
Du coup, une fois que la coquille est cachée, l’utilisateur ne fait plus face à une page blanche en attendant que la page se charge comlètement.
Fresh. Ces sites sont toujours à jour et de manière transparente pour l’utilisateur. C’est un peu le même paradigme que les mises à jour automatiques de Chrome ou Firefox. Quand vous démarrez la version 47, il télécharge la version 48 et vous l’aurez au prochain démarrage.
Safe. Ces sites sont sécurisés avec HTTPS.
J’en profite au passage pour dire qu’en utilisant une application native, je n’ai aucune garantie que les échanges avec le serveur soit sécurisés.
Alors qu’avec un site Web en HTTPS, le cadenas me garantie la validité du certificat. Je peux même me rendre compte que ma banque n’utilise pas le dernier cri en matière de chiffrement.
Discoverable. Ces sites possèdent un manifeste qui décrit différent éléments : titre, icone, lien d’origine, couleur de theme etc…
Si aujourd’hui Google référence les applications native dans son moteur de recherche, On peut attendre à l’avenir que l’ensemble des moteurs de recherches mettent en avant les Progressive Web Apps.
Re-engageable. Un des points qui manquait le plus au Web avec le hors-ligne : la possibilité d’envoyer des notifications pour ré-engager l’utilisateur avec de nouveaux contenus et de nouveaux produits. Ici vous pouvez voir une notif qui vient de Emojoy,
une Progressive Web App de demo qui déchire, en gros c’est un chat mais qui n’envoie que des emojis. Bon OK, c’est useless par contre quand facebook s’y met, là ça envoi. A tel point que sur mon nouveau téléphone, je n’ai toujours pas réinstallé l’application Facebook.
Installable. Les utilisateurs veulent des icônes sur l’écran d’accueil.
Le problème c’est qu’une fois sur un site,
il faut aller dans un menu sur lequel nos utilisateurs ne cliquent quasiment jamais, et trouver le bouton qui se trouve tout en bas.
TODO
Il faut trouver un moyen, une nouvelle expérience utilisateur pour que les gens s’habitue à ajouter des site à l’écran d’accueil. La proposition de Google, c’est cette banière. Si l’utilisateur revient plusieurs fois sur votre site, il se voir proposer une "installation".
Ça une icône sur l’écran d’accueil et ça permet ensuite de lancer l’application sans barres de navigateurs, un peu comme une application native. C’est exactement avec ce genre d’idée qu’on va pouvoir démocratiser ce concept.
Linkable. Parce que les liens hypertextes sont la principale force du Web. Avec un lien, j’accède instantanément à une information, à un service. Je ne dépends pas d’un magasin d’application donné.
Je n’ai pas besoin de télécharger 6mo pour répondre à un sondage.
600 ko bannières pourries comprises ça suffit amplement.
Si le Web peut arriver à proposer des fonctionnalités, c’est grâce à plusieurs nouveaux standards W3C en préparation, et il y en a un en particulier sans qui les Progressive Web Apps ne seraient rien,
les Service Workers !!
La spec décrit une API bas niveau pour répondre aux problématiques de hors-ligne et de mauvaise connexion et permet également d’ouvrir la porte à d’autres idées pour réduire l’écart avec le monde natif. C’est une spec sur laquelle travaille entre autre Mozilla, Google, Samsung, Microsoft…
En gros un Service Worker, faut voir ça comme un proxy programmable dans le navigateur, qui intercepte toutes les requêtes, entre vos pages, et votre serveur et, qui a son propre cache.
Je répète, vous prenez vos pages,
elles sont récupérées de votre serveur via le réseau,
Vous rajoutez un proxy,
qui se trouve bien côté client,
et que vous avez programmé en JavaScript,
Grâce à ça vous interceptez toutes les requêtes des pages (styles, scripts, images, polices, AJAX…), Vous pouvez répondre depuis le serveur, créer vos propres réponses,
ou même répondre depuis un cache dédié que vous manipulez vous même, c’est vous codez le comportement.
Ça ne fonctionne qu’en HTTPS !!! Et oui, vous controllez toutes les pages de votre origine (même sous-domaine, même domaine et même port), et vous pouvez intercepter toutes les requêtes faites depuis ces pages, que la cible soit votre origine ou un CDN, vous avez le contrôle. Du coup, il faut absolument éviter les attaques "Man in the middle" qui viendrait remplacer le script utilisé dans le Service Worker. Les injections sur les pages non sécurisées deviennent assez courantes sur les WiFis d’hôtel, café… Il y a des boites dont c’est le business. Avant HTTPS ça faisait peur, mais ça c’était avant Let’s Encrypt. C’est une nouvelle autorité de certifications qui vient de sortir de beta et qui propose des certificats valides, gratuit et de manière automatisée.
C’est clairement pas un truc de hippie. C’est sponsorisé par des gros du Web et…
depuis l’ouverture de la beta publique début décembre ça dépote pas mal.
Ils ont généré la mois dernier leur millionième certificat.
Bref, alors comment ça marche les Service Worker? D’abord, dans un script de votre page Web, vous vérifiez que l’API est dispo. Ensuite vous appelez register(), c’est comme ça que vous dites au navigateur : instancie moi un Service Worker à partir de ce fichier sw.js. Du coup il va bien exécuter ce script dans un thread indépendant de la page et qui n’a pas accès au DOM. Cette méthode est asynchrone et retourne une promise. Si ça se passe bien, on récupère l’objet registration dans le then(), Sinon on attrape l’erreur dans le catch().
Si vous n’êtes pas familier avec les promises JavaScript, c’est le moment de s’y mettre. Ça facilite pas mal les appels asynchrones, ça permet de les composer etc… C’est maintenant un standard qui fait partie du langage et qui est supporté nativement sur les navigateurs modernes la derière version de Node.JS. Pas besoin de librairies. En plus vous allez voir, quand on utilise les SW, il y en a partout.
Côté Service Worker… Donc là on est bien dans un thread indépendant de la page et qui n’a pas accès au DOM.
L’objet global window dont nous avons tous l’habitude n’existe pas.
Par contre avec self, on peut accéder à l’objet global et on peut l’utiliser pour ajouter un event listener qui va écouter les événements "fetch".
Avec ça je vais voir passer toutes les requêtes de ma page…
Et je vais pouvoir répondre ce que je veux Je peux construire des réponses HTTP de toute pièce. Imaginez la puissance du bazar. Je vous l’accorde, c’est pas utile tous les jours.
C’est qui est vraiment pratique c’est d’utiliser la nouvelle API de stockage qui s’appelle LE CACHE ça fait partie de la spec des Service Workers.
C’est en gros une Map qui fait correspondre des requêtes à des réponses. Ça n’a rien à voir avec les ressources que le navigateur garde dans le cache HTTP, mais la correspondance suit a peu près les mêmes règles concernant les headers etc…
Du coup quand j’intercepte une requête, si j’ai une réponse qui correspond dans un de mes caches, je peux répondre avec caches.match(). Pas besoin du réseau, pas besoin de demander au serveur. C’est programmatique, du coup, je peux définir des conditions et dire que pour toutes les requêtes qui vont vers l’API REST je réponds avec le serveur et pour toutes les autres, je réponds avec le cache.
Pour répondre depuis le réseau, on ne va pas pouvoir utiliser d’XHR. Bah non parceque déjà c’est un nom tout pourri. Il y a aucune logique entre les majuscules et les minuscules, Ça fait mille ans qu’on récupère du JSON et pas de l’XML, et on peut l’utiliser avec d’autres protocoles que HTTP.
La vraie raison c’est que malgré le Asynchronous de AJAX avec une URL et une XHR, on peut faire des appels synchrones, et dans un Service Worker il ne peut pas y avoir d’appels bloquants comme ça. En plus, merci l’API boilerplate oldschool : il faut préciser le type, des callbacks quand tout va bien et quand tout va mal, et enfin on peut envoyer la requête.
C’est pour ça qu’on a une nouvelle API pour faire des requêtes.
L’API fetch() !!! Elle est disponible côté Service Worker mais aussi côté Page. Réutilisabilité du code : +1.
Son fonctionnement est défini dans une spec dédiée. C’est aussi dans cette spec qu’on retrouve les interfaces Request et Response qu’on utilise partout dans les Service Workers et avec le Cache.
Si je reprends mon exemple de tout à l’heure, par défaut, c’est bcp plus simple. La fonction prend une URL sous forme de string ou un objet Request et retourne une promise, quand la promise se résoud, j’ai mon objet réponse sur lequel je peux demander le contenu JSON et là encore je récupère une promise qui quand elle se résoud me fournit la donnée, s’il y a des erreurs, je les attrape avec un catch. L’API fait par défaut un GET mais on peut passer un objet de config pour faire un POST ou autre et préciser pas mal d’autres options comme les headers etc…
Maintenant que j’ai mon API fetch(), je peux répondre avec le serveur depuis mon Service Worker.
Niveau support on est plutôt pas mal. Chrome et opera supporte une partie de la spec depuis presque un an. Les devtools sont plutôt avancés avec du debug pas à pas. Firefox a sorti sa première implémentation stable en début d’année. Côté Microsoft, on a un support de fetch dans la preview de Edge et ils ont annoncé récemment qu’ils commencaient à prototyper et expérimenter sur les Service Workers. Safari, ils travaillent sur l’API fetch et les SW sont identifiés à Under Consideration.
Alors, je ne rentre volontairement pas dans les détails de comment on install et comment on met à jour un Service Worker. Ça reste des API bas niveau. Mon conseil, prenez le temps de les manipuler à la main et de les découvrir et ensuite intéréssez vous aux deux helpers proposés par Google.
La première, c’est sw-precache. C’est un outil Node qui va très bien avec votre task runner préféré. Son rôle, c’est de générer un Service Worker prêt à l’emploi qui à l’installation mettra en cache, votre shell, les fichiers statiques de votre application.
Ensuite, on a aussi sw-toolbox. C’est la librairie utilisé sur le site du Google I/O l’année dernière, sur le site du Chrome Dev Summit et l’application e-commerce flipkart dont je vous ais parlé tout à l’heure.
Ce qu’il y a de bien avec les Service Workers c’est que les fondations sont solides. On a un thread indépendant des onglets ouverts et qui peut recevoir et envoyer des événements. Qui dit thread indépendant dit cycle de vie différent. Du coup, il arrivera que le navigateur endorme le thread quand il ne fait rien. Et si vous quittez le site en fermant tous les onglets, différents types d’événements vont pouvoir réveiller le thread et potentiellement amener l’utilisateur à revenir sur le site. Ce modèle ouvre beaucoup de possibilités intéressantes. Je vous propose donc de découvrir des exemples de code qui ont été développés par Google, Firefox et différents bidouilleur par ci, par là.
…l’API postMessage. Sur l’objet registration, vous pouvez communiquer avec le Service Worker actif et lui envoyer un objet avec ce que vous voulez dedans. Vous pouvez par exemple demander une mise à jour forcée du cache à partir du serveur.
Côté Service Worker, j’écoute tous les messages et je peux donc décider de mettre à jour mon cache.
Je peux aussi me servir de postMessage dans l’autre sens. Quand je vois passer une déconnexion, je préviens tous les onglets ouverts que l’utilisateur se déconnecte.
…je liste toutes les fenêtres/onglets ouverts avec matchAll et je j’itère et je leur balance à chacun un message.
Dans les pages, j’écoute les messages et j’agis en fonction…
Je suis pas obligé d’avoir du JavaScript sur mes pages, je peux tout simplement leur dire naviguez vers la page de login.
Voilà, tout ça, c’est que le début. Il faut continuer les expérimentations farfelues. Petit à petit, on va identifier les bonnes pratiques et les anti-patterns.
Il reste encore beaucoup de défis à relever pour ceux qui travaillent sur la spec et sur des navigateurs.
-
Donner plus de contrôle aux utilisateurs
-
par rapport à la mémoire utilisée par le cache
-
leur permettre de gérer les PWA installées
-
-
Être vraiment au même niveau que les applications natives dans l’OS
-
Partager l’URL courante une fois qu’on est installé en plein écran
-
L’expérience utilisateur en général en matière de hors-ligne et de offline first
Je sais pas vous mais moi j’ai hâte d’être dans le futur, J’ai hâte de voir comment les Progressive Web Apps et les Service Workers vont impacter notre manière de développer sur le Web. J’ai hâte de vous raconter ma semaine de ski en 2020 et de vous dire quels services on utilise avec mes potes et comment nos habitudes ont évoluées. Est-ce qu’on aura toujours besoin d’installer des trucs depuis un magasin d’applications propriétaire ? Ou est-ce que le Web suffira à la plupart de nos usages de tous les jours comme c’est le cas sur Desktop ?
Le futur du Web est là, il est entre vos mains. A votre tour de le répartir un peu plus équitablement…
Merci bcp.
…