Best Of Web 2018

Cette année Sedona était présent au Best Of Web qui s’est déroulé le 8 Juin à la grande crypte à Paris.

L’accueil était bon, la vérification des billets se fait rapidement et après avoir récupéré votre badge et vos goodies un petit déjeuner nous attendait.

Après un café et quelques viennoiseries, c’est partie pour le premier talk.

Nous n’allons pas faire ici un résumé détaillé de chaque session mais essayer de ressortir les idées principales en vous donnant un aperçu et pourquoi pas vous donner envie d’y aller l’année prochaine. Une chose nous a frappé, cela a beaucoup parlé de sujets innovants voir « futuristes ».

Tame your Service Worker before your Progressive Web App go into the wild

Pour bien commencer cette journée, attaquons sur un des sujets en vogue du moment, les PWA. C’est Maxim Salnikow, PWA evangelist, le speaker.

Bien évidemment Maxim va nous rappeler que les services worker sont le moteur des PWA, et nous parler des worklets qui remplacent/font l’interface de certaines fonctionnalités des navigateurs qui ne sont pas présentes sur tout les device :

• Cache Api à la place du local Storage
• Client Api a la place du DOM

Après nous avoir défini les PWA, Maxime nous a donné un top 10 des points d’attentions sur les services workers.

1. Connaitre son API / outillage

Beaucoup d’API mises à disposition pour réaliser des PWA :

• Service Worker API
• Cache API
• IndexedDB
• Fetch
• Clients API
• Broadcast Channel API
• Push API
• Notification API

2. Amélioration progressive

Les PWA doivent s’adapter en fonction du device.
Toujours vérifier l’existence d’un SW avant de l’utiliser car ils ne sont pas tous dispo sur toutes les plateformes,
et toujours faire de la feature détection, afin de savoir si le device propose l’API que l’on souhaite utiliser.
Possibilité de prévoir un fallback pour ne pas gâcher l’expérience utilisateur.
Par exemple : sur Chrome, la Notification API propose des boutons d’actions supplémentaires. Ces boutons n’existe pas sur les autres navigateur.
Il ne faut donc pas implémenter des fonctionnalités uniquement disponible via ces boutons.

3. S’enregistrer au bon moment 

Une règle : Le plus tard est le mieux.
Il faut d’abord proposer le site le plus vite possible à l’utilisateur, et ensuite charger son service worker qui utilisera la bande passante de l’utilisateur afin de mettre en offline des pages.
Ne pas détruire l’expérience utilisateur si quelque chose se passe mal lors de l’initialisation du service worker.

4. En cas d’urgence

Implémenter un kill switch.
Lorsque le service worker est installé et que les pages sont en cache, c’est cette version de l’application qui sera chargée. Si le service worker est buggé, le site qui sera servi via ce service worker sera affiché comme inaccessible.
Ajouter du versionning sur le script du service worker.
Déployer une nouvelle version du service worker patché ou qui ne fait rien.
Ne pas utiliser le cache HTTP (c’est le service worker qui réalisera le cache)
Possibilité de proposer à l’utilisateur un bouton de dé-enregistrement du service worker.

5. Pré-caching

Ne pas mettre de gros fichiers dans le cache.
Il existe une API pour estimer la taille du cache.

6. Cache depuis une autre origine

Attention aux CORS.
Possibilité de configurer une requête en mode « no-cors », cependant celle-ci sera valide uniquement pour les réponses de type 2xx.

7. Redirection

Attention, les requêtes faites depuis le service worker sont en mode no-redirect. Attentions aux 301 => Contenu corrompu.
Possibilité de lever cette contrainte en ajoutant un attribut redirected sur la Fetch API.

8. Utiliser les bons outils

Mettre en place son propre algorithme de caching pour le service worker peut être fastidieux.

Il existe des outils qui peuvent simplifier le travail :

• Framework: angular-cli, vue-cli, polymer-cli…
• Générateurs : sw-precache, workbox, offline-plugin de Webpack

9. Les notifications push

Ne pas directement demander tout le temps à l’utilisateur d’autoriser les notifications push.
Possibilité d’intégrer dans la navigation, ou via un panneau de configuration dans le site une option d’autorisation.
Pas fait pour du broadcast de message, doit être utilisé pour un message individuel à l’utilisateur.
Attendre le bon moment pour demander à l’utilisateur d’activer une autorisation (par exemple, pas pendant la saisie d’un formulaire).

10. Les fonctionnalités à venir

• Navigation preload: Possibilité de charger en simultané le site et le service worker
• Synchro périodique: Possibilité de demander au navigateur de lancer une action périodiquement (sans laisser en vie le service worker en permanence, gestion de la batterie, …)

Open questions

• Installer l’application sans passer par le site Web
• Mise à jour de l’app

Rejoindre la communauté

aller sur le slack de la communauté PWA

How To distinguish PWA’s UX from WEB app’s UX ( je me souviens plus du vrai titre)

Par Caroline Besnard, Héloïse Bonan

Cette conférence est un ensemble de recommandations UX pour des WPA.

Approche Mobile First :

• partir en priorité de l’UX mobile pour la décliner sur les différentes plateformes car c’est le mobile qui a l’écran le plus petit, donc avec le plus de contraintes.

Forms :

• Limiter la longueur des forms sur une page ( qui à avoir plusieurs étapes ou onglets)
• Limiter les textes libres ( car non pratique sur mobile)
• Le bouton de validation du formulaire doit être tout le temps accessible ( penser au clavier qui peut cacher la moitié de l’écran lorsqu’il est déplié)
• Mémoriser les champs pour éviter une secondes saisies lorsque l’utilisateur revient en arrière ou se trompe.

Navigation :

• Simplifier la navigation au maximum -> les fonctionnalités principales doivent être accessible en un clic
• 1 action par page/écran
• Faire des transitions animés simples entre les écrans ( zoom, slide,…)
• Eviter les temps de chargement ( précaching ?)
• éviter les scroll au maximum : Ne pas hésiter à enlever les informations inutile ou peu pertinente afin d’alléger la page : l’utilisateur doit comprendre la fonctionnalité en moins de 3 sec.
• Utiliser les fonctionnalités natives ( GPS, appareil photo, scaner,…)
• Ecrire en 14 pt minimum (sinon trop petit sur mobile)
• Reprendre les conventions UI Mobiles
• Zone de clic suffisamment grande ( 40 pts).

Houdini CSS

Par Jean-François Garreau

Houdini CSS est un projet regroupant plusieurs API dont le but est de donner accès au développeur à la quasi totalité du moteur de rendu des navigateurs.

Moteur de rendu CSS avant HoudiniCSS :

 

 

Moteur de rendu CSS avec  HoudiniCSS

Les différentes API :

TypedOM

• utiliser des objets plutôt que des strings pour les propriétés CSS
• Gain de temps de processing ( on bypass le parsing des valeurs)
• Facilite les conversions entre les différentes unité ( px vers em par exemple)

Custom properties :

• possibilité de créer ses propres variables CSS, ces variables peuvent ensuite être surchargées en css ou bien modifiées directement en js.

Paint API :

• Permet au développeur de modifier la façon dont sont « paint » les box (couleur du fond, image,…)

Animation API :

• Worklet Animator ( pour gérer l’animation dans le temps)
• Worklet Animation ( pour définir une animation)

Layout API :

Pour créer ses propre layout et définir comment seront disposer le box enfants ( on peut facilement imaginer un « display: mosaic » par exemple)

Parser API :

Api pas encore définie, mais devrait permettre aux développeurs d’étendre le parseur CSS comme ajouter par exemple de nouvelle media rules, ou des pseudos classes.

Font Metrics :

Cette Api n’est pas encore définie non plus mais elle devrait  permettre aux développeurs d’accéder aux données des fonts. Cela devrait permettre de mieux gérer le placement des caractères pour des affichages complexes comme des formules mathématiques par exemple.

Comme on peut le voir ici, ces APIs sont encore en phase de spécifications et sont loin d’être implémentées dans les navigateurs actuels. Cela dit elles sont très prometteuses et devraient permettre de développer des polyfills performants.

Comprendre la Stratégie de Google avec le WPA

Par Cédric Ravalec

Google se concentre sur les pays émergents car c’est dans ces pays que la croissance est la plus forte sur le marché des téléphone portable. Cette croissance ne fera qu’augmenté au cours des prochaines années.

Dans ces pays émergents, les téléphones sont en majorités des téléphone de faible puissance. Le réseau est également très faible.

Les applis PWA sont les plus adaptées à ces conditions.  C’est pourquoi Google pousse énormément les PWA.

Selon Cédrice Ravalec, l’OS est voué a disparaitre : Google voulant le remplacer par ChromeOS qui gère mieux les PWA.

Toujours selon l’orateur, la transition se fera cependant sur plusieurs années, pour que ca soit le plus smooth possible

Sécurité sur npm

Par Thomas Crevoisier

Thomas nous a présenté quelques tricks avec npm, qui peuvent potentiellement être des failles de sécurités.

• Pas de sandbox pour npm (il est possible de tout faire avec l’API node)
• Pas de demande d’authentification avant de publier un package npm

Exemple: Lors d’un npm install sur le poste d’un développeur de package npm, possibilité de corrompre son package, et de le republier sur le repo npm.

HTTP 2

Par Alexis Hassler

Les nouveautés de http 2 

• Multiplexed -> plusieurs requêtes en parallèles dans la meme connexion
• Protocole binaire: Compresse beaucoup les tailles des requêtes
• Compression des headers : DRY sur les entêtes HTTP
• Réponses push: Possibilité d’émettre
• Multiplexage : possibilité de plusieurs requêtes au travers d’une seule connexion TCP

Outils en ligne de commande

• nghttpd: Serveur HTTP en ligne de commande
• nghttp: client http ayant le support HTTP/2
• curl: support du HTTP/2 via la lib libnghttp2

2 modes pour servir du HTTP 2

• h2: Basé sur TLS (négociation du protocole via ALPN, Application Layout Protocol Network)
• h2c: Peut être initié par une requête HTTP/1 (en pratique pas supporté par les navigateurs)

Tous les navigateurs récents supportent http2 (h2) mais en TLS uniquement, les navigateurs ne supporte pas de connexion http 2 en clair (h2c).

Http2 est supporté par de nombreux languages et framework 

• En Java, il est supporter nativement en version 9 avec ALPN.
• Java EE 8 avec le publish builder
• Spring boot avec Undertow
• Express 5
• Node > 8.3 (experimental encore)
• Il est également supporter en java 8 en utilisant la lib OpenSSL.

Attention

• Avec  le Push. Le serveur est proactif est envoie des ressources en avance, avant même que le client le demande. Cela permet de gagner un peu de temps mais cependant cette fonctionnalité doit être utilisé avec précaution :
  • dans ce mode le serveur enverra les ressources systématiquement, même si le client les à déjà en cache.
• A l’utilisation de Apache, car comme le serveur peut recevoir plein de requête simultanément et que Apache gère un Thread par requête, il faut bien « tuner » son serveur.

Transformer votre animal en Tamagochi

Par Michel Parreno

On terminera cette journée sur une conférence très sympa, développer une application pour prendre soin de son animal domestique à distance. Cela mélange du développement, de l’électronique et surtout de l’ingéniosité avec un peu d’huile de coude. Cela met en exergue le fait que développer relève aussi du plaisir et qu’il ne faut pas oublier de le faire pour soi-même.

Voici l’architecture mise en place :

Une caméra,  rasberry-P, du python, un serveur apache, une boxe internet, une adresse web, une application React native et quelques éléments électroniques et beaucoup d’huile de coude 🙂

Au final, on peut donner à manger à distance à son animal, gérer la lumière, le visualiser via une caméra et partager cela avec sa famille.

 

---

 

Mathieu Broutin & Vincent Coubray & Edouard Lamotte & Guillaume Meot