D’après Andreas Gal
traduction MozFr : Alice, Maxime, Goofy
C’est le 25 juillet 2011 que Chris Jones et moi-même, avec l’aide de Mike Shaver et Brendan Eich, avons pour la première fois rendu publique notre vision d’un smartphone basé sur les technologies du Web. Cette annonce ne venait pas de nulle part, et ne s’est pas faite en vase clos. Chris et moi avions travaillé ensemble pour Mozilla pendant quelques années, mais n’avions pas eu l’occasion de discuter de façon approfondie car Chris ne travaillait pas dans les mêmes bureaux que moi. Au cours d’un voyage en Asie pour la campagne de lancement de Firefox 4, nous avons pu en profiter pour nous rattraper en discutant de façon sérieuse sur ce qui allait être la question directrice et la ligne de conduite de l’équipe de recherche de Mozilla :
On ne peut PAS le faire sur le Web ? — Et pourquoi pas ?
Nous avons identifié quelques cas d’utilisation pour lesquels le Web est délibérément laissé de côté aujourd’hui. Nous sommes tous les deux des ingénieurs passionnés par le développement de plateformes. Nous gagnons notre vie en nous battant avec les octets et les bits, les cycles de CPU et GPU, et nous comprenons plutôt bien comment marche la plateforme web et son implémentation (dans le cas de Mozilla, avec Gecko). Eh bien nous pouvons vous jurer sur notre tête que nous n’arrivions pas à comprendre pourquoi dans quelques domaines-clés le Web n’avait pas progressé autant qu’ailleurs. Nous avons ciblé deux secteurs particuliers : les plugins et les mobiles.
Les plugins
Si vous avez déjà travaillé sur un moteur de rendu, vous haïssez probablement les plugins autant que nous. Les plugins sont une épine dans le pied du Web. Ils sont difficiles à afficher efficacement. Ils nécessitent du code spécifique côté navigateur pour assurer la compatibilité des binaires, ce qui implique du code très moche et difficile à maintenir. Ils entraînent des fuites mémoire et sont la cause de multiples failles de sécurité. Dans l’ensemble, les plugins freinent le développement des possibilités natives du Web.
Le Flash est un bon exemple : le Web s’est appuyé sur Flash pour les vidéos pendant plus de dix ans. Résultat, l’élément VIDEO n’a réellement pris son envol que tout récemment, et des fonctionnalités basiques comme la régulation du flux vidéo manquent toujours au Web. Chris et moi nous avons travaillé sur le code pour que Firefox prenne en charge ce plugin, et nous sommes bien d’accord, notre vœu le plus cher serait de pouvoir SUPPRIMER ce code pour le plus grand bien du Web.
Il existe un grand nombre de plugins en circulation, mais soyons réalistes, seuls comptent quelques-uns d’entre eux, parmi lesquels le Flash, Acrobat Reader pour les PDF et peut-être Silverlight (nous avions inclus Silverlight dans la liste mais maintenant que Microsoft l’a complètement laissé tomber, je pense que nous pouvons en faire autant). Nous nous sommes demandé pourquoi le Flash et Acrobat Reader sont implémentés sous forme de plugins en code natif, et pourquoi on ne pourrait pas créer la même fonctionnalité en HTML5 avec du CSS et du JavaScript. Et comme nous n’avions pas de réponse à cette question, nous avons décidé de le faire et de voir ce que ça donnait.
Du Canvas et des pointillés
Une partie peu connue de l’histoire du projet PDF.js est que le Web n’était PAS à même d’afficher des fichiers PDF lorsque nous avons commencé. Nous utilisons l’élément CANVAS pour afficher des documents PDF. Nous avons été confrontés à des faiblesses et des fonctions manquantes. Un peu piteusement, nous avons découvert assez rapidement que l’élément CANVAS ne pouvait pas afficher de lignes de pointillés. Il semble que les auteurs de la spécification de cet élément n’aient pas pensé à inclure cette possibilité. Nous avons eu ce problème seulement 4 jours après avoir commencé PDF.js car le premier document que nous avions choisi comportait des lignes de pointillés. Chris et moi avions tous deux la possibilité de modifier le code source officiel de Mozilla, donc Chris sortit rapidement un prototype de Firefox avec cette implémentation, et nous avons proposé une spécification sur la liste de diffusion du W3C. Deux semaines plus tard, la dernière version de développement de Firefox (une « nightly ») incluait la possibilité d’afficher des lignes de pointillés dans l’élément CANVAS, et peu de temps après, un rapport de bug fut rédigé pour que WebKit implémente le même support (WebKit est utilisé entre autres par Safari et Chrome). Cette approche illustre la troisième mission de notre groupe de recherche : trouver ce que le Web ne peut faire, comprendre pourquoi et y REMÉDIER.
Les standards contre les prototypes
Si le Web est si puissant c’est parce qu’il n’est pas gouverné par des comités et organismes de standardisation. Au contraire, les comités de standardisation comme le W3C se contentent d’aider le Web à éviter la fragmentation en donnant à ceux qui font des navigateurs un forum qui leur permet de se coordonner pour travailler ensemble au développement de technologies. pour ajouter le support des lignes en pointillés, nous n’avions pas à convaincre une institution de standardisation. il nous a suffi d’ajouter à Firefox une implémentation expérimentale avec un préfixe, et après quelques mois à peine des centaines de millions d’utilisateurs de Firefox pouvaient commencer à utiliser cette fonctionnalité. c’est aussi pour cette raison que WebKit a très vite décidé d’implémenter le support des lignes en pointillés : sous la pression de la concurrence. Firefox pouvait faire quelque chose mais pas les navigateurs basés sur WebKit. Et voilà comment le Web progresse.
Quelqu’un trouve qu’il manque une fonctionnalité, et implémente un prototype pour. Et si c’est une fonctionnalité intéressante, les autres navigateurs ont peu d’autres choix que de l’implémenter aussi. Le rôle du W3C est d’aider ceux qui créent/développent/font des navigateurs à implémenter la fonctionnalité de manière à ce qu’elle soit compatible sur tous les moteurs de rendus. Au résultat, cela donne une vitesse d’innovation comparable à nulle autre dans l’histoire de la technologie. Des centaines de millions d’utilisateurs ont pu accéder à une fonctionnalité quelques mois après que des ingénieurs ont réalisé qu’elle manquait, et le reste du Web a adopté cette fonctionnalité quelques mois plus tard. Ceci est à comparer à l’approche traditionnelle par comités comme le Java Community Process ou le C++ standards committee dont la vitesse de progression se mesure en décennies.
Au-delà de l’ordi
Le deuxième secteur qui nous intéressait, c’est celui des mobiles. Comment se fait-il que le Web est si omniprésent sur l’ordinateur de bureau, tandis que les contenus pour mobiles (les applications) sont implémentés avec des technologies propriétaires natives telles que Java/Dalvik (pour Android) et ObjectiveC/Cocoa (pour iOS) ? Comme pour les plugins, nous n’avions aucune justification technique, et comme pour les plugins, nous avons trouvé une réponse : en créant ce qui manquait.
À l’époque de notre premier article sur Boot 2 Gecko, qui allait devenir Firefox OS, Mozilla avait déjà réalisé une application pour les mobiles : Firefox pour Android. Cette version n’était pas spécialement populaire parce qu’elle était peu réactive et assez gourmande en mémoire. Nous avons proposé quelques changement structurels dans Firefox pour Android, en particulier en abandonnant notre toolkit en XUL pour l’interface utilisateur au profit d’une interface native Android. L’équipe mobile de Mozilla a fait des efforts héroïques pour transformer le prototype que nous avions réalisé en un produit fini, en six mois seulement. Aujourd’hui, Firefox pour Android est un des navigateurs de tierce partie les plus populaires sous Android, il est plus rapide et consomme moins de mémoire que le navigateur par défaut sur la plupart des appareils. Par opposition avec l’expérience de navigation souvent minable que donne le navigateur intégré, Firefox pour Android offre véritablement une façon plutôt correcte de naviguer sur le Web avec un mobile. Et pourtant beaucoup de gens passent encore un temps fou avec des applications natives. Pourquoi ?
Le mobile, ce vilain petit canard
Si vous voulez comprendre pourquoi le Web n’est pas aussi populaire sur mobile qu’il l’est sur le PC, essayez donc de naviguer sur le Web avec un smartphone : le Web est complètement dévasté sur votre mobile ! Presque aucune des capacités des smartphones modernes n’était disponible sur le Web vers l’époque où nous avons commencé à discuter de Boot 2 Gecko : passer un coup de téléphone, un SMS, le bluetooth, le NFC, les capteurs de proximité, l’accès à la vidéo en streaming, etc. Il n’y a pas si longtemps, un bon nombre de fonctionnalités des appareils mobiles n’existaient pas pour le Web. Ceux qui font des navigateurs ont négligé de faire progresser le Web sur mobile avec la même énergie que nous avions fait progresser l’ordinateur de bureau. Pas étonnant que les créateurs de contenus aient choisi de puissantes API natives, plutôt que d’écrire des applications en HTML5 !
La solution est parfaitement simple et évidente : il faut le faire. Mozilla a commencé sa campagne WebAPI comme premier pas du projet Boot 2 Gecko. Nous avons ajouté une dizaine de nouvelles API au HTML5 pour prendre en charge les possibilités des appareils mobiles et un grand nombre de ces API ont déjà été proposées pour devenir de nouveaux standards W3C à divers stades, depuis les spécifications expérimentales jusqu’à celles qui sont abouties et implémentées sur de multiples navigateurs.
Chez Mozilla, c’est notre affaire
Notre base d’utilisateurs de plusieurs centaines de millions donne à Mozilla une énorme influence sur les technologies du Web, et cette base d’utilisateurs est ce qui nous permet de promouvoir de nouvelles technologies et API. Pour chaque nouvelle fonctionnalité que nous ajoutons, nous nous efforçons de l’implémenter sur tous les navigateurs, depuis les appareils sous Firefox OS (pas encore sur le marché), la version Firefox pour Android (qui a des utilisateurs par milliers) jusqu’à Firefox pour PC (qu’utilisent un tiers des gens connectés à Internet dans le monde). Cela nous donne une voix prépondérante dans les comités de standardisation, et nous en profitons pour hausser le ton et repousser les limites de ce qu’on peut faire avec le Web. Aujourd’hui, le HTML5 est aussi puissant que les API natives, et il ne nous a fallu qu’un an pour combler l’essentiel du fossé entre le Web et les applications natives en ce qui concerne les fonctionnalités des appareils mobiles.
Le rôle de Mozilla pour permettre au Web d’avoir du succès sur le mobile est primordial, car nous avons des motivations très différentes des 3 autres plus importants fournisseurs de navigateurs : Google, Apple et Microsoft. Mozilla est une organisation à but non lucratif. Notre but est de promouvoir l’innovation et le choix sur Internet. Nous ne sommes pas motivés par le profit, et n’avons ni service, ni produit à vendre. Nous voulons des utilisateurs qui utilisent nos produits car ils sont meilleurs que ceux de nos concurrents. Et nous voulons que ce choix incite les autres fournisseurs à améliorer leurs navigateurs et nous faire concurrence. Nous restons intègres et les technologies du Web continuent de s’améliorer.
Pourquoi c’est le Web qui va gagner sur les mobiles
Aujourd’hui, Firefox pour Android est un navigateur web et un environnement d’exécution puissant pour les applications sur mobiles. Le Marketplace de Firefox pour Android donne aux créateurs de contenus un moyen de livrer des applications HTML5 sur un « magasin » facilement accessible d’applications qu’il suffit aux utilisateurs de télécharger.
En 2013, avec nos partenaires, nous allons mettre sur le marché les premiers appareils sous Firefox OS. Il sont conçus entièrement avec les technologies du Web, et comme Chris et moi le supposions il y a un an et demi, il n’existe aucune raison technique valable pour que les technologies natives règnent sans partage sur les mobiles. En fait, Firefox OS et les applications en HTML5 sont vraiment beaucoup plus efficaces en termes de CPU et consommation mémoire que les solutions propriétaires telles qu’Android et iOS. Nous comptons bien en tirer avantage et visons particulièrement les marchés émergents tels que le Brésil avec la première série d’appareils sous Firefox OS. Le Web apportera des smartphones à des régions du monde où les gens ne peuvent pas se permettre d’acheter les modèles haut de gamme et hors de prix dont Google, Apple et Microsoft se disputent le marché.
Une seule question demeure à ce point : est ce que le Web va vraiment décoller sur mobile ? Je pense que la meilleure façon de répondre est la suivante : imaginez que vous êtes un dirigeant d’entreprise comme Facebook et que quelqu’un vous propose un produit nouveau pour vous : Facebook pour Windows, un produit conçu pour que les utilisateurs accèdent à Facebook à partir de postes de travail sous Windows. Selon toute vraisemblance, vous jetteriez dehors ce petit génie en hurlant de rire. Évidemment, le Web est le moyen par lequel les utilisateurs accèdent à des contenus comme Facebook depuis leur ordinateur de bureau. La seule idée d’utiliser une application native à cet effet semble surréaliste et absurde. Maintenant, remplacez le mot « Windows » par « iOS », et soudain tout est différent. Évidemment, il existe une application native Facebook pour iOS.
En réalité, dans un monde où le Web mobile est aussi puissant que le Web pour l’ordinateur de bureau, Facebook pour iOS est tout aussi surréaliste et absurde que le serait Facebook pour un PC sous Windows. Mozilla a travaillé sans relâche pour que ce monde émerge, et je pense que nous en sommes assez proches. Une fois que nous y serons, on oubliera complètement les applications natives pour les mobiles, comme on oublie les applications Win32 en voie d’extinction aujourd’hui.