Connexion
Abonnez-vous

La bêta de Chrome 55 brosse les développeurs dans le sens du poil

Un peu de lisibilité dans ce monde de brutes

La bêta de Chrome 55 brosse les développeurs dans le sens du poil

Le 24 octobre 2016 à 08h45

Chrome 55, dont la bêta est maintenant disponible, propose plusieurs nouveautés intéressantes pour les développeurs, particulièrement dans la gestion des textes. On retrouve évidemment les améliorations déjà évoquées sur les performances à la sortie de la version Developer.

Cette version 55 doit pour rappel soulager la mémoire vive des appareils en libérant plus efficacement la mémoire pour le JavaScript. Comme pour d’autres améliorations liées à la gestion de la RAM, les nouvelles se concentrent donc sur la machine virtuelle V8. Les calculs JavaScript pourraient ainsi prendre jusqu’à moitié moins de mémoire vive que dans les versions précédentes. Il s’agit évidemment d’un cas idéal et qui fluctuera en fonction des pages.

Les évènements souris et toucher gérés de manière uniforme

La bêta de Chrome 55, sortie ce week-end, propose d’autres améliorations, pour la plupart destinées aux développeurs. Le navigateur unifie ainsi les évènements MouseEvent et TouchEvent via les PointerEvents. L’éditeur promet des pages plus réactives, le défilement n’étant par défaut pas bloqué. Les développeurs qui le souhaitent peuvent mettre en place des listeners passifs d’évènements pour obtenir les mêmes performances qu’avec TouchEvent.

Les mots-clés async et await pour le JavaScript sont également de la partie. Un ajout important qui permet de structurer le code de manière à le rendre beaucoup plus lisible quand un site comprend de « longues chaines de dépendances asynchrones ». On peut voir ci-dessous la manière dont le code devient plus lisible avec les mots-clés.

chromechrome

Des césures automatique dans les CSS

L’une des fonctionnalités les plus réclamées par les développeurs est désormais en place : la césure automatique pour le CSS. Il s’agit de pouvoir placer un texte dont les dimensions adaptent dynamiquement les césures dans les mots – autrement dit leur découpage avec des tirets – ce qui évite d’avoir des lignes de taille variable. Notez cependant que cette fonction n’est pour l’instant gérée que par les versions Android et macOS de Chrome. Elle arrivera dans les autres « plus tard ».

Parmi les autres nouveautés disponibles, signalons la possibilité de marquer un site comme possédant un stockage web permanent, Chrome ne le supprimant donc plus. La gestion des connexions TLS prend par ailleurs en charge GREASE, pour mieux affronter les serveurs ayant des bugs. Côté développeurs, le lecteur multimédia se dote de deux capacités : la présence d’un bouton de téléchargement quand la source est associée à un fichier classique (MP3, MP4, etc…).

L’arrivée des nouveautés dans le canal Beta permet de les tester sans trop risquer de problèmes, contrairement à la version Developer, nettement plus « brute » (moins de tests). Contrairement à cette dernière cependant, la bêta ne peut pas s’installer aux côtés d’une version stable : elle la remplace. Attention donc si vous décidez d’y jeter un œil.

Commentaires (22)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

ça fera du bien à certains développeurs d’être un peu brossés :  j’en connais qui sont hirsutes.

votre avatar

brosser les développeurs dans le sens du poil



Euh pas vraiment. Avec la clôture cette semaine par un wontfix du bug à la deuxième place des attentes [des devs] on ne peut pas dire qu’ils brossent les devs dans le sens du poil.

Il sera donc impossible d’ouvrir un xml+xsl en local car ils sont incapables d’implémenter correctement la same origin policy pour un fichier local… 

votre avatar

“GREASE” , voila j’ai les chansons dans la tête. pff



“un stockage web permanent” : ça regroupe quoi ça ? j’ai du mal à voir.

votre avatar

Bah il en aura fallu du temps à Google pour supporter les pointers events de Microsoft…



On se souviendra de leur refus à l’époque pour différents motifs :




  • Apple ne le supporte pas donc ça risque de ne pas prendre… Dixit la société qui à au moins 6070% du marché web mobile avec son moteur de rendu Blink et qui choisit donc quels technologie seront vraiment utilisés sur le Web

  • problème de performance (quant est-il aujourd’hui ?)

  • problème au niveau du mouvement “pull to refresh” (quant est-il aujourd’hui ?)



    A l’époque vu le doigt d’honneur fait à la communauté, on se demande si c’était pas juste une manœuvre politique pour bloquer Microsoft qui était encore dans le mobile et lançait le concept des Surfaces…

votre avatar







arno53 a écrit :



Bah il en aura fallu du temps à Google pour supporter les pointers events de Microsoft…



On se souviendra de leur refus à l’époque pour différents motifs :




  • Apple ne le supporte pas donc ça risque de ne pas prendre… Dixit la société qui à au moins 6070% du marché web mobile avec son moteur de rendu Blink et qui choisit donc quels technologie seront vraiment utilisés sur le Web

  • problème de performance (quant est-il aujourd’hui ?)

  • problème au niveau du mouvement “pull to refresh” (quant est-il aujourd’hui ?)



    A l’époque vu le doigt d’honneur fait à la communauté, on se demande si c’était pas juste une manœuvre politique pour bloquer Microsoft qui était encore dans le mobile et lançait le concept des Surfaces…









    C’est l’une des raisons pour lesquelles un monopole dans le secteur du web a toujours été décrié.

    Avant, Microsoft, maintenant, Google …

    Et le pire c’est que vu la quantité de sites “optimisés pour Chrome” qui sont apparus, visiblement beaucoup de devs n’en ont rien à faire.


votre avatar

Hello,



Ce n’est pas “ne rien avoir a faire” mais c’est surtout que depuis l’HTML5 Chrome est généralement le navigateur qui supporte bien mieux les API et qui les sort en premier.



Le dernier exemple en date que j’ai est la capture de la webcam que j’utilise dans un projet pour permettre a un utilisateur de répondre a une question en vidéo , sous Chrome / Firefox et Opera (Chromepera, hum) aucun soucis le tout en JS et ça marche du tonnerre même si les prototypes / noms des fonctions ne sont pas exactement les mêmes



Par contre pour Safari, IE et Edge je suis obligé d’utiliser du Flash (oui oui, du flash en 2016), ce qui est un tantinet embêtant point de vu dev et qui m’oblige à avoir un serveur RTMP en back, de plus la qualité n’est pas vraiment la même au final.



Dans mon cas je n’ai pas eu le choix car le client se fiche de ces problématiques, lui il a son Safari sur son MAC il veut que ça fonctionne.



Mais il est vrai que dans bien des cas c’est relativement relou de faire en sorte que ton front-end fonctionne partout (Safari … je te haie, vraiment !) donc certains estiment que le coup nécessaire a une compatibilité a 100% pour un navigateur ne vaut pas la PDM donc ils le mettent de coté.

votre avatar







 Silentk a écrit :



 Mais il est vrai que dans bien des cas c’est relativement relou de faire en sorte que ton front-end fonctionne partout (Safari … je te haie, vraiment !) donc certains estiment que le coup nécessaire a une compatibilité a 100% pour un navigateur ne vaut pas la PDM donc ils le mettent de coté.





On en parle d’IE 6 ? <img data-src=" />traumatisé à vie !


votre avatar

Non, laisse le ou il est celui là :p



Plus jamais, plus jamais :‘(

votre avatar

google… <img data-src=" />

votre avatar

Google n’est pas en monopole

votre avatar







plop97 a écrit :



Google n’est pas en monopole







On vit sur la même planète <img data-src=" /> ?



De fait, Google fait ce qu’il veut au rayon standard web HTML5 depuis un moment.


votre avatar

https://netmarketshare.com/http://gs.statcounter.com/



&nbsp;Chrome est à moins de 60% de PdM. Rappelle moi la PdM de Windows ?

votre avatar







plop97 a écrit :



https://netmarketshare.com/http://gs.statcounter.com/



 Chrome est à moins de 60% de PdM. Rappelle moi la PdM de Windows ?







Ce n’est pas une question de part de marché de navigateur, mais d’influence.

Google est actuellement un corps très influent dans le standard HTML5, et c’est pas forcément de sa faute d’ailleurs.



Il n’y a qu’à voir comment le W3C a eu des passages décousus, et la quantité de préfixes CSS -webkit (donc attachés au moteur de rendu poussé par Google, de fait, aujourd’hui) supportés par Chrome. qui débordent sur les autres navigateurs.



cf. : nextinpact.com Next INpact


votre avatar

Rappel moi la part de Windows sur le matériel pc+tablette+smartphone ?



Rappelle moi la part de marché du moteur de rendu Blink sur pc+tablette+smartphone ?



Rappelle moi la part de marché des moteurs de rendu n’ayant jamais eu pour base Webkit sur le marché des pc+tablette+smartphone…



Avec ces 3 chiffres je pense que tu vas comprendre que EdgeHTML et Gecko n’ont au final que très peu de part de marché et qu’ils n’ont qu’un impact limité sur les standards en devenir..

votre avatar

Tu peux installer Firefox/IE/Opera/Safari

-&gt; Google n’est pas en situation de monopole.

Le jour où il n’existera qu’un seul navigateur fonctionnel alors là oui.

Par contre oui google est clairement en position dominante.

votre avatar

Si c’est pour un dev interne, il y a toujours la solution du flag “–allow-file-access-from-files”. Leurs choix de sécurité ne sont que rarement discutables.

Si c’est pour du “web pure”, que fait une app à charger du contenu local ? (c’est une vrai question)

(Chromium command line switches).

votre avatar







AmaCha a écrit :



Si c’est pour un dev interne, il y a toujours la solution du flag “–allow-file-access-from-files”. Leurs choix de sécurité ne sont que rarement discutables.

Si c’est pour du “web pure”, que fait une app à charger du contenu local ? (c’est une vrai question)

(Chromium command line switches).





Ca fait un bout de temps que le –allow-file-access-from-files ne fonctionne plus.

&nbsp;

Impossible de charger une xml qui fait appel à une xsl dans le même répertoire ? seriously ?

C’est con pour les gens qui proposait de la doc (ou un dump de leur site) à ce format là.



Leurs choix de sécurité font peur.

Wontfix parce que “le mec qui a intégré le comportement qui emm tout le monde s’est barré depuis longtemps” [et qu’on a pas été capable de reproduire le comportement de Firefox]



&nbsp;


votre avatar







Blood_Man a écrit :



Tu peux installer Firefox/IE/Opera/Safari

-&gt; Google n’est pas en situation de monopole.

Le jour où il n’existera qu’un seul navigateur fonctionnel alors là oui.

Par contre oui google est clairement en position dominante.







J’ai été imprécis, je ne parle pas de navigateur mais de moteur de rendu.

Firefox (Gecko) et IE (Trident) sont techniquement autonomes ; Opera, Vivaldi, Chrome, notamment, sont tous sur le même moteur de rendu : Blink. Safari, dans une moindre mesure, et toute une foule d’autres reposent aussi sur le même moteur : Webkit, dont Blink est un fork made in Google.



Quand on voit la propension de Firefox ou IE à supporter les propriétés CSS préfixées “-webkit-” (signalant des propriétés inventées par Blink/Webkit, mais surtout Blink en fait), on peut s’inquiéter de la réelle concurrence en matière de définition de ce qu’est le web via HTML.



Surtout quand on voit que Chrome ne supporte toujours pas, depuis tant d’années, certaines propriétés CSS parce que leur bon vouloir les juge inutiles, ou “trop dur à supporter”, alors que Firefox les supporte depuis perpette… Parfois des propriétés très courantes et remplacées par du JS, donc avec un vrai besoin !

cf. http://caniuse.com/#search=position%3Asticky


votre avatar

Clair que l’on tape pas mal sur eux… mais on oubli vite le marasme de JavaScript et d’HTML4 qui n’ont pas évolué pendant (trop longtemps).

C’est tout de même pas mal grâce aux équipes de travail de Google et la formation du WhatWG (avec Mozilla et Opera notamment) que l’on a des WebWorkers en ECMAScripts, ainsi que les WebComponents.

De même si leurs API des WebExtensions étaient si mauvaises, elles ne seraient par reprisent par tous les concurrents (Firefox, Edge, Opera, …)

Et si les implémentations d’ECMAScripts 5/2015/2016… sont aussi rapides (et vraiment les bienvenus, vu comme l’on part de loin) c’est aussi dû au fait que Mozilla et Google se “tirent la bourre”… (async, promises, arrow function, class declaration, …)

votre avatar

Je ne veux pas taper sur le travail de Google, même s’il est trop souvent orienté dans un sens qui personnellement me déplait.



Je veux taper sur leur comportement un peu “solo” parfois, qui est nettement dommageable à une saine mise en concurrence des idées.



L’abomination Flash, Javascript en roue libre, … des choses qu’on aimerait oublier, et on est pas à l’abri de recommencer.

votre avatar

Ben JavaScript était plutôt au point mort qu’en roue libre à mon sens <img data-src=" /> <img data-src=" />

Après s’ils proposent des idées et que tous les autres les adoptent, c’est que ça manquait peut-être finalement… ;)



Mais je suis tout à fait d’accord qu’il faut garder de la concurrence.

Mais justement, que fait la concurrence ? Ils sont bien souvent plus suiveur qu’autre chose.



Il y a bien qu’Opéra ou Vivaldi pour essayer de proposer d’autres choses/fonctionnalités, mais basé sur Blink (même pas WebKit qui avance “trop lentement” à cause des “freins” d’Apple bien souvent).

votre avatar

Le position:sticky est un peu un mauvais exemple car il y a du dev dessus et est activable via flag (–enable-experimental-webkit-features) mais perso je ne l’ai pas dans la dernière build stable.

À savoir, les specs W3C ne sont toujours pas finalisées et pose encore des problèmes non résolus.

Les problèmes d’implémentations sur les versions actuelles de Chrome sont d’ailleurs bien expliquées sur Stack Overflow.



Et concernant Microsot Edge c’est toujours pas ça… un navigateur continuellement entre version alpha et beta…

La bêta de Chrome 55 brosse les développeurs dans le sens du poil

  • Les évènements souris et toucher gérés de manière uniforme

  • Des césures automatique dans les CSS

Fermer