Dans cet article que MozFr a traduit pour vous ci-dessous, Brendan Eich qui est le créateur du JavaScript et l’un des fondateurs de Mozilla fait le point sur le succès qui accompagne le lancement de Firefox OS et sur l’intérêt des nombreuses API pour mobiles que Mozilla propose à la standardisation, de quoi satisfaire les développeurs Web pour mobile…

La dernière semaine de février a été marquée par le lancement en fanfare de Firefox OS au Mobile World Congress 2013. À Barcelone, lors d’une conférence de presse au succès retentissant nous avons annoncé que Firefox OS était soutenu par dix-huit opérateurs, quatre fabricants de téléphones et l’un des principaux fondeurs de puces (Qualcomm).

Fondateurs et dirigeants

L’équipe de Mozilla qui a aidé à la conférence de presse (d’autres étaient à Barcelone faisant un travail pré-MWC aussi important) :

…et notre stand extraordinaire, qui a été très fréquenté, dans le Hall 8 (« App Planet »)

Deux jours plus tard, l’excitation a encore grandi avec l’annonce de la participation d’un cinquième fabricant, Sony.

Si nous avons réussi à gagner le soutien de tous ces partenaires, c’est en partie parce que nous avons su innover et standardiser les API nécessaires pour créer uniquement avec des standards Web toutes les applications utiles sur un téléphone. Ces API faisaient jusque-là défaut. J’avais déjà parlé de ces API dans un billet lors du MWC 2012, voici un nouveau point qui détaille les progrès de la standardisation de ces API au cours de l’année écoulée.

Je veux non seulement pointer le bon travail en cours, mais aussi réaffirmer que :

  • nous créons ces API de manière collaborative pour combler de véritables manques dans les standards ;
  • nous travaillons activement pour en faire des standards sur tous les systèmes d’exploitation et tous les navigateurs, comme c’est la mission de Mozilla ;
  • nous avons accompli d’énormes progrès cette année grâce à Firefox OS, et plusieurs des API que nous avons créées fonctionnent aussi dans Firefox pour Android ;
  • la coopétition a déjà amené Samsung à modifier WebKit pour qu’il implémente certaines de ces API ;
  • nous continuerons à mettre à jour les spécification et le code des API à mesure que de nouveaux terminaux et capteurs arriveront sur le marché.

Les API qui manquent doivent être ajoutées à la plate-forme Web pour permettre aux milliards de nouveaux utilisateurs mobiles qui vont se connecter dans les prochaines années d’avoir pour un prix abordable des téléphones, des tablettes et des applications basés sur le Web. Les consommateurs des marchés émergents et les développeurs ne peuvent en général pas se payer les téléphones de plus en plus haut de gamme et qui privilégient les applications natives des deux grands du marché.

Historiquement, la principale raison pour laquelle beaucoup de développeurs se sont tournés vers les applications natives spécifiques à chaque plate-forme, c’est qu’elles étaient le seul moyen d’utiliser les composants matériels et les fonctionnalités propriétaires (comme le niveau de la batterie, le téléphone, les SMS, les systèmes de paiement) présents sur les téléphones. Les développeurs qui essayaient courageusement d’utiliser le HTML5 étaient obligés de compiler leur code pour le transformer en application native, par exemple avec Phonegap.

Les propriétaires des OS n’avaient aucune raison technique de pénaliser la pile Web, d’enfermer les développeurs dans leur pile propriétaire ou de faire de leur boutique un passage obligé. Et pourtant, les forces en présence tiraient le Web en arrière en masquant les API nécessaires.

Tout comme les premiers créateurs de navigateurs ont ajouté des boîtes de dialogue pour sélectionner des fichiers ou afficher des alert aux utilisateurs, en communiquant avec l’OS, nous sommes enfin en train de mettre à jour la plate-forme Web en créant les API qui manquaient pour les téléphones. Ça met le Web au même niveau que les applications natives. Et en nous conformant à nos habituelles bonnes pratiques, en travaillant au vu et au su de tous et en soumettant tout ce que nous faisons aux processus de standardisation, nous sommes confiants, les fonctionnalités manquantes finiront par devenir disponibles sur toutes les plates-formes.

Lorsque ces API seront disponibles dans tous les moteurs de rendu — même sur les ordinateurs de bureau et les portables lorsque ça a du sens — les développeurs pourront être sûrs que leur code sera interopérable et s’exécutera partout, quel que soit le système d’exploitation. La fragmentation, s’il y en a une, sera due à l’OS, par exemple s’il ne met pas à jour son moteur de rendu (comme c’est arrivé avec Android 2.3).

À l’exception de problèmes de mise à jour spécifique à certains OS, les développeurs peuvent être confiants parce qu’ils accèdent à un marché unique pour tous les systèmes d’exploitation et tous les navigateurs. Dans le marché aujourd’hui compétitif des navigateurs, les développeurs Web font la loi ; les fabricants de navigateurs et de moteurs de rendu leur font la cour. Les développeurs ne vont pas se soucier de systèmes d’exploitation à venir qui s’écarteront de plus d’un pouième des standards.

L’exemple de nos amis de Samsung qui ont modifié Webkit en se basant sur les nouvelles spécifications valide notre approche. Cela signifie que si les terminaux sous Tizen ont du succès, il est très probable que les applications qui fonctionneront sur Firefox OS fonctionneront également sur Tizen.

De même, nous travaillons avec Microsoft sur les évènements de type pointeur, car les applications conçues pour des interfaces tactiles ont besoin d’unifier les évènements tactiles et ceux de la souris. Les précédents travaux du W3C concernant le multi-touch ont échoué à cause de problèmes liés à des brevets.

L’augmentation des performances JavaScript dans tous les moteurs a été sensationnelle ces dernières années. Cette amélioration met fin à un autre avantage des applications natives sur les applications Web. Sans compter l’arrivée prochaine d’asm.js — j’en parlerai dans un prochain billet.

Parmi les autres améliorations de performance, le travail en cours sur le processus d’affichage, avec le déport du rendu hors du thread principal et les GL layers. Oui, c’est vrai, le modèle moderne de rendu web focalisé sur les mobiles inclut une utilisation implicite des threads sous la forme du thread de composition et de l’architecture hautement parallèle des GPU.

Comme toujours, les standards en cours de rédaction peuvent changer, mais ils ont besoin d’implémentation prototypes et de tests par les utilisateurs (à la fois des développeurs et des consommateurs). Mozilla est bien décidée à jouer le jeu honnêtement en ne créant pas de standards de fait à partir de prototypes, mais plutôt en faisant des propositions et en choisissant ce qui sera standardisé (c’est pour cela que nous préfixons les plus incertaines de nos nouvelles API — mais je pense que le but devrait être de supprimer les préfixes le plus rapidement possible dès que nous verrons émerger un consensus entre tous ceux qui implémentent)

Voici ce que nous avons fait au cours de l’année et ce sur quoi nous travaillons :

  • l’API donnant l’état de la batterie est à présent candidate à la recommandation (CR) au W3C, et il y a eu récemment des discussions pour en faire une recommandation proposée (c’est la dernière étape avant de devenir une recommandation officielle du W3C, qui indique qu’elle peut être largement déployée) ;
  • la téléphonie. Ben Turner, Jonas Sicking, Philipp von Weitershausen de Mozilla y participent. L’API de téléphonie est développée par des gens d’Intel et de Telefonica au sein du groupe de travail SysApps du W3C ;
  • l’API SMS est développée dans le même groupe de travail. Y participent pour Mozilla Mounir Lamouri et Jonas Sicking ;
  • le verrouillage de pointeur. Cette API est stable et implémentée dans plusieurs navigateurs. Mozilla participe au groupe de travail Pointer Events du W3C aux côtés de Microsoft, Google, Opera, jQuery et d’autres. Matt Brubeck de Mozilla et Jacob Rossi de Microsoft sont en charge de cette API ;
  • la proposition d’applications Web ouvertes() a été soumise au W3C. On dirait que le consensus a été atteint pour utiliser la proposition de Mozilla comme premier brouillon de travail au sein du groupe de travail SysApps, Samsung étant le coéditeur de la spécification ;
  • l’API alarmes est à présent un brouillon au W3C. Intel participe à son édition, c’est un bon exemple de collaboration ;
  • l’API Web Activities, est une version simplifiée des Web Intents. Nous nous sommes concentrés sur un sous-ensemble plus simple de Web Intents, ce qui s’est avéré une bonne idée. Les fonctionnalités incluses dans Web Activities fonctionnent bien, alors que la proposition Web Intents est en cours de refonte ;
  • les notifications en push. Cette API n’en est qu’à ses balbutiements. Nous avons quelques prototypes mais pas encore de code. Faire cela de la bonne manière est difficile étant donné que nous voulons créer quelque chose de sûr, capable de monter en charge et de proposer une haute disponibilité ;
  • l’API WebFM. Nous avons un premier brouillon, mais le groupe de travail SysApps du W3C a décidé de se concentrer en priorité sur un petit ensemble de spécifications, afin de bâtir un socle commun. Cette API est peu prioritaire et devra donc attendre un peu avant de pouvoir être standardisée ;
  • les paiements Web ont été implémentés par Fernando Jimenez Moreno de Telefonica. Il y a un groupe communautaire du W3C sur le paiement et une Task Force vient d’être créée. Nous allons travailler au sein de ces groupes pour créer une API flexible pour la gestion des paiements sur le Web ;
  • Doug Turner de Mozilla est éditeur de l’API de gestion des capteurs de lumière ambiante ; il participe également à l’API de gestion des capteurs de proximité.

Les développeurs intéressés par une meilleure connaissance des nouvelles API devraient se pencher sur ce billet de Mozilla Hacks de Robert Nyman, qui donne des conseils sur la façon de les utiliser avec des exemples de code.

Ainsi, Mozilla mène l’effort pour compléter la plate-forme Web sur les appareils mobiles. Notre travail porte ses fruits comme en témoigne le soutien de l’industrie à Firefox OS et les efforts du W3C pour standardiser les nouvelles API. Même Andy Rubin a eu des mots gentils pour nous (merci Andy !).

La principale récompense pour moi reste l’image du sourire des « développeurs Web mobiles » (lire : « développeurs Web ») que j’ai pu voir à deux pas d’ici. Au vu de notre expérience au MWC de cette année, le Web est en bonne position pour remporter cette récompense.

/be

Bonus :

Dans les commentaires, en réponse à une question sur le portage de Firefox OS sur les télévisions connectées, Brendan apporte la précision suivante :

Les télévisions sont sur notre écran radar, mais avec une priorité basse. Tout d’abord, c’est un environnement difficile à cibler et où il est également difficile de trouver des partenaires. Tout d’abord, beaucoup de fabricants utilisent une version bridée d’Android. Ensuite, les consommateurs sont moins intéressés par des applications sur grand écran. Enfin, les producteurs de contenu et les DRM sont apparus sur notre radar avant que nous ayons suffisamment d’influence pour promouvoir un modèle de DRM à la sauce Mozilla, centré sur l’utilisateur.

Nous y arriverons, mais les téléphones restent notre premier objectif, ensuite les tablettes, puis (peut-être en même temps que les tablettes, ou alors après) les télévisions et les grands écrans.