Retour sur la DotJs 2015 - Constat sur le Web mobile

Cette fois-ci j'aimerai faire un retour sur une des conférences que j'ai pu assister lors de la dotJs 2015 qui a eu lieu à Paris le 7 décembre 2015.

Pour cet article, je voudrai parler d'Henrik Jorenberg, dont le sujet est "Pocket-Sized JS", mais qui peut se résumer à l'état actuel du Web mobile et vers quoi devrions-nous aller.

Henrik commence à expliquer que nous sommes dans une période où être un développeur JavaScript est opportun. En effet, nous avons dorénavant une tonne d'outils pour nous aider, nous déportons de plus en plus la logique d'interface voir applicative du côté du navigateur. Et également, nous développons de plus en plus nos serveurs ou nous outils en NodeJs.

Néanmoins, un point noire obscurcit tout ça, c'est le Web mobile. Il y a eu depuis 2010 une effervescence à l'élaboration d'applications Web mobiles pures, ou d'applications dites hybrides ( nous utilisons une coquille native où une Webview fait tourner l'application Web). Cela est intéressant, car nous pouvons ainsi cibler un grand nombre de plateformes mobiles à faible coût (sans avoir à écrire une application mobile native pour chaque plateforme visée).

Toutefois, un essoufflement se fait sentir, et cela malgré des solutions comme Ionic, ou des solutions par forcément native comme Angular, ReactJs, ...

En fait, l'explication s'avère simple (et dites-cit Henrik): nous savons faire du JavaScript dans le navigateur, nous savons faire du JavaScript côté serveur ... du moment que nous avons une connexion internet rapide et que l'interpréteur JavaScript l'est tout autant. Ce qui n'est pas le cas dans le monde de la mobilité, où la lenteur (et coupure) réseau est monnaie courante, mais aussi tout le monde n'a pas le dernier smartphone à la mode afin d'exécuter les milliers de lignes JavaScript de notre application.

De plus, un utilisateur sur un mobile veut et souhaite une interactivité riche, avec animations fluides, sans aire ralentir le mobile. Ainsi, quand nous touchons un endroit de notre écran, nous souhaitons naïvement que nous ayons un retour écran immédiat. Et non pas ce fameux temps de latence que nous voyons souvent sur les applications mobiles (car souvent, c'est l'événement "click" qui est attendu. Et sur les mobiles, il y un temps de latence allant de 500ms à 2 secondes).

Ainsi, réaliser une application Web mobile à haute performance est compliqué. Pas impossible, mais compliqué ! Car nous ne pouvons pas préjuger que:

• Nous aurons une connexion Internet rapide
• Nous n'aurons pas de coupure réseau
• Tout s'exécutera rapidement

Et pour ce dernier point, nous pouvons faire un constant simple: en 2015 (pas l'année dernière, à l'heure où je vous parle), une application Web mobile sur Android a un résultat pauvre, avec une grosse lenteur.

Et cela malgré l'aide que pourrait nous amener des frameworks comme AngularJs, ReactJs, EmberJs. Mais là encore, il y a un effet pervers. En effet, nous utilisons un framework, avec l'espoir:

• Que ce soit optimisé
• Que nous n'ayons pas de fuites mémoires
• Que ce soit orienté mobile
• etc ...

Malheureusement, en allant sur les différents Github des frameworks cités précédemment, nous aurons beaucoup de tickets ouverts par rapport aux exigences vues juste au dessus.

Henrik nous sort alors une phrase choque: nous devons faire plus avec moins !

En effet, les frameworks comme AngularJs, ReactJs, EmberJs, même compressés font souvent plusieurs centaines de ko. Et si nous souhaitons orienter notre application vers du "mobile first", il est souhaitable de respecter certaines recettes de cuisines. Par exemple, un expert dans le domaine, Luke Wroblewski, nous devons respecter la règles des "5 6". A savoir:

• Que nous ayons moins de 60 Ko de CSS à charger
• Que nous ayons moins de 60 Ko de HTML à charger
• Que nous ayons moins de 60 Ko de JavaScript à charger
• Que les animations respectent les 60 fps
• Que nous ayons moins de 0.6 secondes de latences pour les actions

Voyons alors les différents moyens pour y arriver.

Premièrement, ne faites pas une application "desktop" qui va ensuite tourner en tant qu'application mobile ! Car tout simplement, l'application ne tournera aussi bien sur son desktop que sur mobile. Le constat est alors simple: nous seulement nous ne faisons pas du "mobile first", mais en plus, nous avons tendance à ne pas tester sur des mobiles (sans parler du fait que nous ne testons pas un large panel de smartphones).

Et pour cela est important, car nous estimons que plus de 6 milliards de smartphones seront en circulation d'ici 2020. Ainsi, le nombre de personnes qui n'auront jamais utilisé un navigateur desktop sera de plus en plus important ! Et ce constant est déjà le cas aux Etats-Unis.

Deuxièmement, au lieu de charger des templates HTML, il vaut mieux parfois les générer via JavaScript (avec JSX par exemple: https://facebook.github.io/jsx/ ). Mais aussi de charger moins de frameworks, de codes. Et si nous voulons respecter la recette de Luke Wroblewski, un grand nombre de frameworks sont éliminés automatiquement. De plus, posons-nous les questions suivantes:

• Avons-nous vraiment besoin d'un moteur de template ? Car JSX nous permet d'écrire du JavaScript qui devriendra de l'HTML
• Avons-nous besoin du data-binding ? Car après tout, l'état de notre application peut être représenté par un object, nous pouvons avoir des fonctions qui modifient cet état en fonction d'action et qui en plus régénère l'HTML
• Avons-nous besoin d'un routeur ? Car une URL représente un état. Et qui peut être simplement gérer via l'api History d'HTML5
• Devons-nous forcément utiliser ReactJs ? Alors que des solutions alternatives et moins lourdes comme VirtualDom fonctionne aussi bien.

Enfin, le point le plus important: faisons le moins de choses sur le thread de rendering. Car nous l'oublions rapidement: JavaScript est mono-threadé. Ainsi, nous avons tendance à faire trop de choses sur un thread qui doit à la fois mettre à jour l'interface et résoudre la logique applicative. Sur des moteurs JavaScripts rapide, cela ne pose pas (trop) de problèmes. Mais sur un mobile, c'est plus délicat.

Henrik nous suggère alors d'utiliser les WebWorker. C'est un thread que nous créons mais qui n'a pas le droit de modifier le DOM. Néanmoins, des apis comme JSX ou VirtualDom peuvent être utilisés. Du coup, nous pouvons libérer le thread principal pour mettre à jour l'interface et un WebWorker pour:

• Gérer le changement d'état de l'URL
• Faire des appels Ajax / WebSocket
• Faire des traitements lourds
• Générer de l'HTML
• Définir les services métiers
• Manipuler les données (dans le localStorage, IndexedDB, ...)
• ...

Bref, nous pouvons si le souhaitons vraiment faire tourner toute notre logique applicative dans un WebWorker !

A ne pas oublier les Service Worker qui permet de faire du vrai offline ! Contrairement à l'api Cache d'HTML5, nous avons à faire à une api bas niveau, où nous pouvons finement déclarer un proxy de caching et ainsi réduire les temps de chargements.

Henrik nous à fournir un "Proof of concept" afin d'illustrer ces propos.

Voilà, j'espère que cela vous a plu.