Etat du Web Mobile

Qui suis-je ?

{
  "firstName": "Julien",
  "lastName": "Roche",
  "age": 33,
  "works@": "Viseo Technologies",
  "tags": [
    "JavaScript", "NodeJs", "Angular", "Backbone",
    "Grunt", "Gulp", "Bower", "Jspm", "Karma", "Mocha / Chai / Sinon",
    "HTML5", "CSS3", "Less", "Stylus",
    "Java", "Spring", "Hibernate", "JPA",
    "..."
  ]
}

Le JavaScript en générale

Tout va bien

Web mobile

plus constrasté

• Malgré une effervescence depuis 2009 / 2010
  • Pléthores de solutions
  • De nombreuses ressources pour nous aider
• Néanmoins le ressenti des utilisateurs et des développeurs est mitigé
  • car constatent des temps de chargement long
  • Car constatent des soucis de performances
  • Car constatent des soucis d'animations
  • Car constatent que c'est plus compliqué que ça en a l'air

Les raisons

Nous développons pour du mobile ! Par du serveur

• Nous sommes habitués à écrire du code serveur ou du code navigateur
• Donc nous n'avons pas (ou presque jamais)
  • De coupure réseau
  • De connexion lente
  • De lenteur d'interprétation ou d'exécution

Android n'est pas gentil

• C'est la plateforme la plus répandue
• Mais c'est celle qui amène le plus de soucis
  • De lenteur de chargement
  • De lenteur d'interprétation
• https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889

Trop de confiance dans nos frameworks

• Nous utilisons Angular, React, Ember, ...
• Nous pensons que ces frameworks
  • sont adaptés / pensés pour les mobiles
  • sont performants
  • sont peu buggés

N'allez pas voir les issues sur Github -_-'

Pas assez de tests sur mobile

Nous avons trop tendance à développer sur le navigateur de notre desktop et en dernier recours, sur UN smartphone qui n'est pas en générale représentatif du marché (taille d'écran, performance, ...)

Pas assez mobile first

• Tendance à faire l'application pour desktop
  • Puis ensuite d'ajouter des simples règles CSS pour du responsive design
    • Voir du JS pour gérer deux / trois cas

C'est déjà le cas aux Etats-Unis, mais la tendance nous amène à avoir de plus en plus d'utilisateurs qui n'auront jamais utilisés de navigateurs desktop !

Les règles à respecter

Les règles des 5 6 

De Luke Wroblewski (papa du mobile first)

En somme

Faire plus en utilisant le moins de JS

(c'est possible, ça prend plus de temps)

Notre checklist

• Avons-nous besoin de data-binding ?
  • Utiliser Redux
• Avons-nous besoin d'un routeur complexe ?
  • L'API HTML5 est suffisant
• Avons-nous besoin d'un framework IHM ?
  • VDOM
• Avons-nous besoin de frameworks externe ?
  • De jQuery
  • De BootStrap ?
• ...

Devenir du Web Mobile

Utiliser un vrai système de cache (pour faire du offline)

Service Worker

Principe: fournir un API de haut niveau afin de mieux gérer le cache (sorte de proxy écrit en JavaScript pour gérer les requêtes)

• Vidéo, cookbook & démo
  • ​http://www.infoq.com/fr/presentations/web-hors-ligne-services-workers
  • https://jakearchibald.com/2014/offline-cookbook/
  • https://serviceworke.rs/

Libérer le thread !

Rappel: JavaScript est mono-threadé !

WebWorker

But: créer un thread additionnel qui n'a pas accès au DOM.

Le principe ici est de déporter toute la logique fonctionnelle, métier, de navigation, d'appels Ajax, de traitements lourds dans un (ou plusieurs) WebWorkers

Et que le thread principal soit libéré pour les interactions utilisateurs et les mises à jours IHM

Merci à

Henrik Joreteg (@HenrikJoreteg) pour son talk à la dtoJS 2015

Ce talk fût très inspirant

Quelques liens

• Son talk:
  • https://www.youtube.com/watch?v=okk0BGV9oY0
• Ses slides:
  • https://slides.joreteg.com/dotjs/
• Son appli de démo: 
  • 8.5 Ko !
  • https://github.com/henrikjoreteg/feather-app