Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

Chrome Dev Summit 2017 : un web toujours plus axé sur les services de Google

La simplification ou le choix
Logiciel 7 min
Chrome Dev Summit 2017 : un web toujours plus axé sur les services de Google
Crédits : _ultraforma_/iStock

Google organisait cette semaine son Chrome Dev Summit pour réunir les développeurs intéressés par le futur du navigateur et la manière dont la société considère le web. Le cru 2017 consacrait Chrome comme moteur de rendu, Google voulant manifestement en faire un point de chute pour les développeurs d’applications.

Si l’on en croit Google, les raisons de se réjouir sont nombreuses. L’entreprise semble particulièrement satisfaite de la progression du HTTPS sur un an. La firme rappelait en fait ici quelques chiffres donnés en fin de semaine dernière. Par exemple, 64 % du trafic transitant par Chrome sur Android est protégé, contre 42 % il y a un an.

Autre facteur de satisfaction, les Progressive Web Apps (PWA). Ces dernières sont pour rappel toujours des applications web, mais avec des interfaces et fonctionnalités pratiquement égales à celles des applications natives. Les performances doivent donc être alignées sur ces dernières, l’interface doit s’adapter à l’écran, les API Notification et Push doivent être gérées, HTTPS est obligatoire et on peut l’installer sur l’écran d’accueil via son icône.

Le Service Worker en approche chez Apple et Microsoft

Ce qui réjouit tant Google, c’est que le support du Service Worker (SW) progresse chez Apple et Microsoft. Il s'agit d'un script chargé en parallèle de ceux spécifiques à la page web qui devient en quelque sorte un proxy pour l’application web via l’API postMessage. Il gère les requêtes depuis et vers l’application et peut y répondre en puisant dans une base de données locales. Il permet ainsi le mode hors ligne, obligatoire pour une PWA.

Qu’il s’agisse des moteurs Webkit ou EdgeHTML, ce support est « en cours de développement ». Cet élément essentiel sera donc bien présent dans Safari et Edge, mais on ne sait pas quand. Autre élément important pour les PWA, le Web Application Manifest est en considération chez Apple, et en développement chez Microsoft.

Trusted Web Activity, encore un mix de contenus web et locaux

Google tient décidément à ce que les développeurs utilisent autant que possible les technologies du web pour leurs applications, quelles qu’elles soient. Et pour cause : plus ils les utiliseront, plus ils auront des chances de pousser encore Chrome en avant. Un mouvement à l'inverse d'Apple par exemple, qui pousse vers Swift et le développement natif.

Si les développeurs doivent manipuler des ressources web dans leurs applications natives, pourquoi dès lors ne pas leur proposer Chrome comme moteur de rendu ? C’est justement l’objectif de la Trusted Web Activity (TWA).

Le contenu TWA vient donc du web, du même éditeur que l’application native servant de base (d’où le terme « confiance »). Leur rendu est effectué par Chrome pour le compte de l’application, de la même manière que si le navigateur s’en chargeait lui-même. À ceci près que le contenu est affiché en plein écran, donc sans aucun élément de contrôle autres que ceux prévus par les développeurs.

Plusieurs avantages selon Google. D’abord le développeur n’a pas à se soucier d’intégrer quoi que ce soit pour le rendu web. Le moteur étant celui de Chrome, il est déjà présent sur Android, soulageant éventuellement le poids total de l’application. De plus, la TWA limite les risques en coupant tout accès direct aux ressources web depuis l’application native. Une communication peut néanmoins se faire via des paramètres dans des URL. Enfin, que les écrans proposés soit de type web ou natif, tout est question d’activités et les deux peuvent s’enchainer.

Pour l’instant, Chrome n’est pas capable d’effectuer ce rendu. La fonctionnalité vient tout juste d’arriver dans le canal de développement Canary sous forme d’une API. Notez que si pour une raison ou une autre la fonction est inexploitable en cas d’appel, Chrome fournira à la place un Custom Tab.

Cette nouvelle interface pour développeurs risque cependant de renforcer la position de Chrome sur Android. En poussant toujours plus son navigateur comme un élément de rendu pour les applications web et mixtes, Google s’assure une belle place au soleil.

De navigateur, Chrome devient trousse à outils

En tant que navigateur, Chrome est assis sur une immense source de données diverses. Google veut en faire profiter les développeurs en leur fournissant des indications techniques capables d’améliorer l’expérience utilisateur. 

Arrive donc le Chrome User Experience Report, un dépôt public d’informations diverses sur la manière dont les sites sont utilisés. Seules les données des utilisateurs ayant activé la synchronisation de l’historique, n’ont pas configuré de phrase de passe et participent volontairement aux données statistiques sont présentes.

Le premier lot de données provient de 10 000 sites et se base sur une petite dizaine de métriques. On retrouve ainsi First Paint (premier élément rendu de la page), DOMContentLoaded (document HTML lu et parsé), Effective Connection Type (nécessite l’API Network Information présente dans Chrome 62), Device Type ou encore onload (temps de chargement pour la page et de ses ressources).

L’idée de Google est d’encourager les développeurs à comparer ces valeurs avec celles constatées pour leurs propres pages. Le fait que les données proviennent « d’utilisateurs réelles » peut ainsi représenter une ressource complémentaire, permettant de sortir des tests locaux et autres simulations.

L’intérêt pour Google est évident : impliquer toujours plus Chrome dans le développement web. Car si les données sont recueillies via des API tout à fait standard, c’est bien le nom de Chrome qui est associé au stock d’informations.

Simplifier la création de compte, toujours en passant par Google

Cette prévalence de Google est également très visible dans deux nouveaux mécanismes présentes aux développeurs : One tap sign-up et Automatic sign-in.

Le concept consiste à simplifier au maximum l’étape de création du compte sur un service, qu’il s’agisse d’une application ou d’une simple page web (ou un mélange des deux évidemment). Partant du principe qu’il y a de fortes chances que l’utilisateur se soit déjà connecté à un compte Google depuis Chrome, pourquoi ne pas réutiliser ces informations ?

One tap sign-up propose donc d’utiliser ce compte pour créer un jeton de sécurité faisant office de lien avec le service tiers. Avantage pour l’utilisateur, le processus est réduit à sa plus simple expression puisqu’il n’y a même pas besoin de mot de passe. Google met en avant une friction minimale, apte à faire progresser les inscriptions, souvent rebutantes pour les internautes.

Automatic sign-in assure pour sa part la reconnexion automatique au service tiers, si le jeton de sécurité a expiré entre temps. Cette reconnexion intervient même si l’utilisateur se connecte depuis un autre appareil. Dans le cas d’un compte avec mot de passe, celui-ci ne sera pas exigé s’il a été auparavant enregistré dans Chrome ou Smart Lock for Passwords.

Et les avantages pour Google ? Évidents : pousser toujours davantage le compte maison, tout autant que Chrome. Les éditeurs tiers peuvent effectivement compter sur une hausse des inscriptions, mais le compte qui en résulte reste basé sur celui de Google. Il s’agit d’une version simplifiée à l’extrême de Google Sign-In, déjà en place depuis quelques années.

Pour utiliser cette fonctionnalité, les développeurs intéressés devront en premier obtenir un Google API client ID, puis ouvrir la page Credentials de la console. Notez que One tap sign-up et Automatic sign-in disposent d’une intégration à l’API Credential Management.

La simplification ou la diversité

L’équation proposée par Google est on ne peut plus simple et rappelle d’autres aspects de la concentration, notamment pour les données personnelles : si les développeurs veulent utiliser ces nouvelles capacités, il faut passer par ses services. 

D’un côté, le constat n’est pas étonnant : il s’agit après tout de nouveautés annoncées dans le cadre d’un Chrome Dev Summit. De l’autre, certains développeurs se méfieront sans doute d’un web trop accroché au géant de Mountain View, car la simplification dans ce domaine (comme dans bien d’autres) a un prix. Comme toujours lorsque l'on met tous ses œufs dans le même panier.

Signalons qu’il s’agit des nouveautés les plus visibles annoncées par Google. La firme a effectué de nombreuses présentations, toutes rassemblées sur cette page de YouTube. La plupart sont des cas pratiques de technologies proposées par l’éditeur, ou d’exploitation de standards existants à travers les outils de Chrome.

22 commentaires
Avatar de boogieplayer Abonné
Avatar de boogieplayerboogieplayer- 25/10/17 à 20:54:37

Quand on pourra faire autant avant un navigateur qu'avec un application mobile, ça sera un très grand pas de fait en avant et on s'affranchira enfin de ces stores à la noix, et ces technos enfermantes.

Qu'on puisse utiliser un simple FF sur son mobile pour TOUT faire, la webapp mieux qu'une appli. C'est mon souhait depuis 20 ans que j'utilise un navigateur.

Pour ceux que ça branche :https://whatwebcando.today/

Avatar de MoonRa Abonné
Avatar de MoonRaMoonRa- 25/10/17 à 21:03:52

Safari est maintenant notre nouvel IE6, j'exagère mais c'est drôle de penser que dans le #turfu dans lequel on est, on a toujours un problème avec un navigateur.

Avatar de Ghimo Abonné
Avatar de GhimoGhimo- 25/10/17 à 21:58:06

C’est quoi le problème avec Safari ?

Avatar de boogieplayer Abonné
Avatar de boogieplayerboogieplayer- 26/10/17 à 05:43:18

Ghimo a écrit :

C’est quoi le problème avec Safari ?

Regarde des éléments HTML modernes et tu veras que souvent safari ne les supporte pas =>https://caniuse.com/

La comparaison avec IE6 est dure, mais c'est la bonne idée. Peu d'évolution, pas d’extensions, pas d'accès au sources, peu de features utiles Force est de constater de chrome et FF sont les meilleurs avec le plus de possibilité pour les dev et donc pour les utilisateurs.

Edit : typo

Édité par boogieplayer le 26/10/2017 à 05:43
Avatar de Leum Abonné
Avatar de LeumLeum- 26/10/17 à 08:27:24

Sauf que Safari ne domine pas. Il est obligatoirement présent sur iOS mais Chrome domine le web en étant présent partout.

Avatar de graphseb Abonné
Avatar de graphsebgraphseb- 26/10/17 à 08:34:17

MoonRa a écrit :

Safari est maintenant notre nouvel IE6, j'exagère mais c'est drôle de penser que dans le #turfu dans lequel on est, on a toujours un problème avec un navigateur.

Oui, tu exagères pas mal… Tu n'as pas connu ou bien tu as oublié (la galère MSIE 6 | 7 | 8) ?

Avatar de jpaul Abonné
Avatar de jpauljpaul- 26/10/17 à 08:54:20

boogieplayer a écrit :

La comparaison avec IE6 est dure, mais c'est la bonne idée. Peu d'évolution, pas d’extensions, pas d'accès au sources, peu de features utiles Force est de constater de chrome et FF sont les meilleurs avec le plus de possibilité pour les dev et donc pour les utilisateurs.

Edit : typo

Bof, je suis dev web et à la maison j'utilise Safari. Les perfs sont vraiment excellentes, la synchro avec iOS est juste au top, l'accès aux sources ... heu, je comprend pas ta remarque, les extensions il y en a (il y a toutes celles que j'utilise).

Avatar de jpaul Abonné
Avatar de jpauljpaul- 26/10/17 à 08:59:43

boogieplayer a écrit :

Quand on pourra faire autant avant un navigateur qu'avec un application mobile, ça sera un très grand pas de fait en avant et on s'affranchira enfin de ces stores à la noix, et ces technos enfermantes.

Qu'on puisse utiliser un simple FF sur son mobile pour TOUT faire, la webapp mieux qu'une appli. C'est mon souhait depuis 20 ans que j'utilise un navigateur.

Pour ceux que ça branche :https://whatwebcando.today/

Ben c'est marrant mais je pense tout l'inverse. Oui je pense qu'il faut trouver comment unifier le dev mobile au maximum mais selon moi le web est très loin d'être la solution (mais la solution, je ne l'ai pas :) ). En tant qu'utilisateur, je veux des apps natives et intégrées au maximum avec mon OS. Les apps mobiles web deviennent très rapidement des catastrophes à maintenir dans le temps (le JS est juste une plaie à maintenir dans le temps si t'as pas embauché les devs les plus expérimentés de ta région), ont leur propre look and feel, doivent ré implémenter des comportements / interfaces / animations / ... qui sont pourtant intégrés nativement aux OS mobiles ... Tout ça avec des technos qui ont été inventées pour écrire des documents (HTML / CSS / JS).

Avatar de versgui Abonné
Avatar de versguiversgui- 26/10/17 à 10:09:40

Certaines API ne verront probablement jamais le jour pour des raisons de sécurité (je pense notamment à l'API Battery Status ou l'API Contacts).

Mais en terme de performance, l'horizon d'un web aussi performant que du natif commence à se rapprocher sérieusement, notamment grâce à des outils offerts aux développeurs (j'ai découvert récemment la propriété CSS will-change, c'est juste magique).

Édité par versgui le 26/10/2017 à 10:09
Avatar de versgui Abonné
Avatar de versguiversgui- 26/10/17 à 10:17:30

Pour le JS, si tu en reste au JS d'il y a 5 ans, effectivement, c'est une plaie.

Mais aujourd'hui il y a une myriade d'outils permettant de faire du code front propre, avec du typage, du vrai objet, des tests unitaires, etc. On est encore loin du natif, notamment à cause des performances en terme d'animation et de réactivité, mais ça vient doucement mais surement. Des librairies permettant de simuler des composants systèmes commencent à arriver (Google a créé un framework JS/CSS pour Material Design). Personnellement, je serais prêt à parier que Google va finir par laisser tomber Java pour Ecmascript, au profit d'une réimplémentation maison des technos web pour du natif (un peu ce qu'à voulu faire Mozilla avec FirefoxOS mais beaucoup trop tôt). Chrome deviendrait alors un lecteur/émulateur universel.

En revanche, comme le souligne l'article à juste titre, je ne pense pas que ça soit la voie souhaitée par Apple qui a d'avantage intérêt à garder captifs ses utilisateurs dans on écosystème fermé.

Édité par versgui le 26/10/2017 à 10:22
Il n'est plus possible de commenter cette actualité.
Page 1 / 3