Connexion
Abonnez-vous

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

La simplification ou le choix

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

Le 25 octobre 2017 à 16h06

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.

Le 25 octobre 2017 à 16h06

Commentaires (22)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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/

votre avatar

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.

votre avatar

C’est quoi le problème avec Safari ?

votre avatar







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


votre avatar

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

votre avatar







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) ?


votre avatar







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).


votre avatar







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).


votre avatar

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).

votre avatar

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é.

votre avatar

Battery Status est déjà gérée par qq browsers je crois



Celle des contacts pose pas plus de soucis que pour des apps au final, dans tous les cas faut que l’autorisation soit demandée à l’utilisateur, sinon y’a un souci.

votre avatar

https://html5test.com/results/desktop.html

C’est plus pratique que caniuse pour comparer rapidement

votre avatar

Seul Chrome la supporte, elle a été retirée de Firefox et de Safari.



Le problème des contacts est le même que celui de la Battery API : elle donne accès à un niveau de données tellement précises au niveau du système que les webapp peuvent faire du fingerprinting ultra fiable. En gros, n’importe quel éditeur pourra te tracker via ses app natives et ses sites web - quel que soit le navigateur - de manière 100% fiable sur un même device. Même plus besoin des cookies, il n’y a plus aucune barrière entre domaines, navigateur et apps et au final, l’utilisateur n’a plus aucun contrôle.

votre avatar







versgui a écrit :



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).







L’API battery statuts existe… ou j’ai pas compris ?


votre avatar







TiTan91 a écrit :



https://html5test.com/results/desktop.html

C’est plus pratique que caniuse pour comparer rapidement





Yep <img data-src=" />


votre avatar







jpaul a écrit :



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).







On peut faire beaucoup plus de chose avec chrome ou FF, parce qu’on a accès au source, et que leur usage est plus répendu. Ne serait -ce que les utiliser directe surt des machines, ou à compiler soit même sur une machine. D’ailleurs chromium est mieux de ce point de vue là car on peut enjecter des paramètre à la compilation.



On travaille pour des banques et les DSI n’autorise que Chrome ou FF (en fonction de la banque) donc on dev pour eux. Safari c’est trop marginal pour être concidéré, d’ailleurs dans mes CGV on exclu le support safari et IE


votre avatar







jpaul a écrit :



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).







On a pas la même vision <img data-src=" /> Mais je puis te montrer pourquoi dans bien des cas c’est mieux via le navigateurs. PAr exemple, on fait des dev pour entreprise chinoises =&gt; application mobile interdite ! ils veulent TOUT voir passer


votre avatar

Tu t’attends pas à ne pas être identifiable lorsque tu donnes l’accès à tes contacts.

C’est tout aussi vrai pour les apps que certains installent comme ils visitent des sites.



Faut simplement que lorsqu’un “site” (comme une app) tente d’y accéder la demande soit claire.

votre avatar







TiTan91 a écrit :



Tu t’attends pas à ne pas être identifiable lorsque tu donnes l’accès à tes contacts.

C’est tout aussi vrai pour les apps que certains installent comme ils visitent des sites.



Faut simplement que lorsqu’un “site” (comme une app) tente d’y accéder la demande soit claire.







Dans tous les cas, on tombe sur le même constat problématique (même pour Google) : 90% des utilisateurs ne lisent pas les demandes de droits et acceptent sans rechigner.

Tant que ce probleme ne sera pas résolu, on restera dans le status quo en ce qui concerne les API web.



Toujours le même vieux problème de la chaise et du clavier…


votre avatar

Y a pas vraiment de status quo là dessus

Plusieurs développeurs de browsers ont plutôt intérêt à ça même (google et ms)

Et c’est pas comme si le même souci n’existait pas déjà avec les apps…

votre avatar

Non, Google n’a pas intérêt à ça. Son business model est basé sur la confiance qu’ont les utilisateurs en ses produits (“je sais que je communique des données personnelles, mais ça en vaut la peine, je ne pourrais pas m’en passer”).

Si cette confiance s’effrite ne serait-ce qu’un peu, c’est problématique pour eux. Le problème des demandes de droits majoritairement ignorées a été souligné (et admis) par Google himself lors de sa dernière&nbsp; Google I/O, notamment suite à quelques cas récents d’appli ultra-connues qui ont abusé de droits abusifs.

votre avatar

Y’a la com’ et la réalité hein

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

  • Le Service Worker en approche chez Apple et Microsoft

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

  • De navigateur, Chrome devient trousse à outils

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

  • La simplification ou la diversité

Fermer