La bêta de Chrome 55 brosse les développeurs dans le sens du poil
Un peu de lisibilité dans ce monde de brutes
Le 24 octobre 2016 à 08h45
3 min
Logiciel
Logiciel
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.
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.
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
Commentaires (22)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 24/10/2016 à 08h58
ça fera du bien à certains développeurs d’être un peu brossés : j’en connais qui sont hirsutes.
Le 24/10/2016 à 09h39
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…
Le 24/10/2016 à 09h44
“GREASE” , voila j’ai les chansons dans la tête. pff
“un stockage web permanent” : ça regroupe quoi ça ? j’ai du mal à voir.
Le 24/10/2016 à 10h58
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 :
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…
Le 24/10/2016 à 11h26
Le 24/10/2016 à 12h36
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é.
Le 24/10/2016 à 12h47
Le 24/10/2016 à 13h03
Non, laisse le ou il est celui là :p
Plus jamais, plus jamais :‘(
Le 24/10/2016 à 13h04
google… " />
Le 24/10/2016 à 14h37
Google n’est pas en monopole
Le 24/10/2016 à 18h34
Le 25/10/2016 à 06h44
https://netmarketshare.com/http://gs.statcounter.com/
Chrome est à moins de 60% de PdM. Rappelle moi la PdM de Windows ?
Le 25/10/2016 à 07h56
Le 25/10/2016 à 10h55
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..
Le 26/10/2016 à 08h02
Tu peux installer Firefox/IE/Opera/Safari
-> 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.
Le 26/10/2016 à 08h10
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).
Le 26/10/2016 à 08h35
Le 26/10/2016 à 08h48
Le 26/10/2016 à 09h24
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, …)
Le 26/10/2016 à 12h13
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.
Le 26/10/2016 à 17h19
Ben JavaScript était plutôt au point mort qu’en roue libre à mon sens " /> " />
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).
Le 26/10/2016 à 17h26
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…