Mot-clé - javascript

Fil des billets

jeudi 23 avril 2009

WebKit's week - #8

French version

After four months without news, I'll try to be more regular. Let's hope my new organisation will help.

Changes of the week

Everything mentioned below should work with the latest nightly available at the moment (42662).

6 parallel connections (42457, 42559)

With this commit, WebKit can now use 6 parallel connections per domain, previously 4. The number of parallel connections is important to download as fast as possible the resources of a web page. WebKit is now behaving like latest versions of IE, Firefox or Chrome. Opera uses 8 connections per domain. To test this, you'll have to wait for a future version of the CFNetwork library.

function.displayName (42478)

You can create anonymous function in JavaScript. They are very useful but the drawback is they also appear anonymous in the profiler. This make the interpretation of the results pretty hard. Now, you can give a name to those functions and it will be used in the profiler.

Yarr! (42481)

Yarr! (Yet Another Regex Runtime) is, as it suggests, a new Regex Runtime. It is disabled by default for some reasons like being incomplete at the moment but said to be faster than the old one. Hoperfully, we'll have more news when he'll be live.

XMLHttpRequest withCredentials (42483)

This is a new feature from the XMLHttpRequest Level 2 spec. With the withCredentials attribute, you can define whether or not you wanna send the cookies and HTTP authentication data when using a cross domain XHR. Like the number of parallel connections, we need a new version of CFNetwork to test this.

Array.reduce and Array.reduceRight (42563, 42570)

These are two new methods define by ECMAScript 5. You are invited to read the documentation on the Mozilla developer center.

SQL is read only with private browsing (42616)

When using the private browsing mode (aka porn mode), the web database is no longer writeable. Inserts, updates, deletes are no longer available. This way, the website can't record stuff while in a private session.

Implementation of the played attribute (42619)

The new video element has a played attribute which give info about what part of the video has been played. You got access to a TimeRanges object.


This is everything for this week. Of course, this is just a selection I've made. If you've noticed any other interesting changes, please let me know. Same thing if I got something wrong.

La semaine de WebKit - #8

Après une interruption de 4 mois, je vais essayer de reprendre mes petites nouvelles. J'ai changé d'organisation pour essayer d'être plus régulier.

Changements de la semaine

Tout ce qui est mentionné ci-dessous doit normalement fonctionner dans la dernière nightly disponible (42662).

6 connections parallèles (42457, 42559)

Avec ce changement, WebKit passe de 4 à 6 connections parallèles par domaine. Le nombre de connections par domaine est important pour télécharger au plus vite les ressources des pages web. WebKit s'aligne donc sur les dernières versions de IE, Firefox et Chrome. Opera utilise 8 connections par domaine. Il faudra juste attendre une prochaine version de la librairie CFNetwork pour voir le changement effectif dans Safari.

function.displayName (42478)

JavaScript permet de créer des fonctions anonymes. Elles sont très pratiques mais la contrepartie, c'est qu'elles sont aussi anonymes dans le profiler, ce qui rend difficile l'interprétation des résultats. Grâce à ce changement, on peut désormais donner un nom aux fonctions et il sera utilisé dans le profiler.

Yarr! (42481)

Yarr! (Yet Another Regex Runtime) est un nouveau moteur de RegExp. Il est désactivé par défaut pour l'instant mais semble plus rapide que l'ancien (encore heureux) mais pas encore suffisamment. Il est d'ailleurs encore incomplet. Des nouvelles lorsqu'il sera plus avancé.

XMLHttpRequest withCredentials (42483)

Nouvelle fonctionnalité faisant partie de la spec XMLHttpRequest Level 2, l'attribut withCredentials permet de choisir si l'on souhaite envoyer les cookies et les autorisations HTTP lors d'une requête XHR sur un autre domaine. Comme pour le nombre de connexions parallèles, il faudra attendre une prochaine version de CFNetwork.

Array.reduce et Array.reduceRight (42563, 42570)

Deux nouvelles méthodes définies par ECMAScript 5. Je vous invite à lire les explications sur le centre développeur Mozilla.

SQL en lecture seule en navigation privée (42616)

En mode navigation privée (aka porn mode), les écritures ne seront plus autorisées dans les bases de données web. Plus d'insertion, modification ou suppression possible. Ainsi aucune information durant une session privée ne pourra être enregistrée.

Implémentation de l'attribut played (42619)

La nouvelle balise video contient un attribut played permettant de savoir quelles parties de la vidéo ont déjà été visionnées. Cet attribut représente les intervalles de temps qui ont été lus.


Voilà pour cette semaine. Évidemment, ce n'est qu'une sélection que j'ai faite. Si vous avez remarqué d'autres changements intéressants, n'hésitez pas à les mentionner. Idem si je me suis trompé dans une explication.

lundi 2 mars 2009

Redesign du Web Inspector

Ci-dessous, une traduction du billet de Timothy Hatcher du blog Surfin' Safari. Quelques fautes et imperfections de traductions doivent s'être glissées, n'hésitez pas à me les signaler. Le billet original date du 30 septembre 2008 et ne parle pas encore de la beta de Safari 4.

Lire la suite...

mardi 3 juin 2008

Nouveautés Safari 3.1 : Selectors API

Présentation

Comme promis, on va parler de quelque chose de bien plus intéressant pour accélérer vos applications web. Une attente de longue date, la fameuse et célèbre Selectors API ! C'est l'équivalent de $$ en Prototype et Mootools, $ en jQuery, YAHOO.util.Selector.query en YUI et... document.querySelectorAll pour base2. [1] Pour ceux qui connaissent, cela permet donc de sélectionner un liste d'éléments qui correspondent à un sélecteur CSS.

L'exemple du billet précédent devient donc document.querySelectorAll('.post'). Une différence à noter entre ces deux méthodes : querySelectorAll retourne une liste statique, un tableau en quelque sorte.

Regardons un peu les performances :

var start = new Date(); for (var i = 0; i < 1000; i++) var list =document.querySelectorAll('.post'); new Date() - start
104
var start = new Date(); for (var i = 0; i < 1000; i++) var list =document.getElementsByClassName('post'); new Date() - start
2

C'est sans appel, pour un sélecteur simple, il vaut mieux utiliser une méthode spécialisée. J'ai fait quelques autres tests. De manière générale, si vous voulez traversez simplement le DOM, tenez-vous en aux autres solutions. Cette méthode sera peut-être optimisée plus tard, ce n'est que la première implémentation.

Évidemment, le navigateur ne reconnaîtra que les sélecteurs qu'il connaît. Pas de problème avec Safari 3.1 puisqu'il connaît tous les sélecteurs disponibles à ce jour (on en reparlera plus tard, peut-être). Par contre, avec IE8, ce sera plus compliqué. Oui oui, IE8 implémentera cette API ! Et comme cette API a été bien conçue, le navigateur est censé renvoyer une exception lorsqu'il ne connaît pas un sélecteur. Le monde est presque parfait !

Les librairies

  • Prototype : dans la version de dev (un appel à un div vide puis le vrai appel)
  • YUI : rien
  • mootools : rien
  • base2 : Oui, en dev.
  • jQuery : rien.

Le piège.

Le comportement de cette API est pour l'instant trompeuse. Lorsque l'on utilise cette méthode sur un élément, elle va chercher tous les éléments du document qui correspondent puis ne retourne que ceux qui sont des enfants de l'élément. Le comportement des librairies (et qui me semble plus naturel) est d'appliquer le sélecteur à partir de l'élément en question. John Resig en parle bien mieux que moi

Les petits plus

Que peut-on faire de marrant avec cette API ? On peut par exemple récupérer tous les liens présents sur la page qu'a visité l'utilisateur. Un simple document.querySelectorAll(':visited') fera l'affaire.

On peut aussi récupérer la liste de tous les éléments qui sont actuellement survolés par l'utilisateur. document.querySelectorAll(':hover') vous donnera satisfaction.

Notes

[1] Oui, cette librairie est tellement bien qu'il n'y a pas besoin d'apprendre autre chose que les standards

mercredi 28 mai 2008

Google Ajax Librairies : une bonne idée ?

Google vient donc d'annoncer la possibilité de servir 5 librairies javascripts depuis ses serveurs.

L’idée d’avoir un dépôt central est plutôt intéressante. Pour avoir un cache relativement partagé entre les sites, être sûr de la configuration HTTP au poil, bénéficier du CDN de Google. Après, il faut aussi voir que l'accès à votre site sera conditionné par la disponibilité de ses serveurs. Mais il semble que ce soit la tendance... (Amazon S3)

Par contre, Google propose de s'occuper de charger la dernière version à travers son API Javascript. C’est une très très mauvaise idée que d‘avoir la version la plus récente de la libraire. Il faut toujours tester ses applis avant de mettre la nouvelle version d’une librairie en production. À la rigueur pour les versions mineures, et encore.

Après, cela va certainement défavoriser les librairies non sélectionnées. Des librairies comme Base2, Mochikit ou YUI ne sont pas listée par exemple.

Enfin, Google a annoncé vouloir travailler avec les éditeurs de navigateurs pour intégrer certaines librairies directement dans le navigateur. Si jamais cela se réalise, ça va être marrant pour les versions et encore plus discriminant pour les librairies non incluses. Les développeurs choisiraient non pas la librarie la plus légère ou la plus performante mais la plus souvent intégrée dans les navigateurs.

Google ferait mieux de travailler avec les éditeurs pour améliorer le support des standards et l’implémentation des prochains standards. Car un code en C, C++ ou autre sera toujours plus performant que sa version Javascript.

En résumé : idée peut-être intéressante dans l’état actuel d'implémentation des standards mais attention à la discrimination et surtout, continuer à améliorer le support des standards.

jeudi 10 avril 2008

Nouveautés Safari 3.1 : getElementsByClassName

Allez, on continue dans Webkit (parce que ça me botte en ce moment). Je ne suis pas tombé sur beaucoup d'articles en français résumant les nouveautés de Safari 3.1. Et comme on n'est jamais mieux servi que par soi-même...

Commençons par getElementsByClassName. Kékecé ? À l'instar des getElementById, getElementsByTagName, getElementsByName c'est une méthode pour récupérer des éléments du DOM selon un critère, en l'occurence la ou les classes. Par exemple, sur la page d'accueil de ce blog, document.getElementsByClassName('post').length renvoie 20 mais document.getElementsByClassName('post odd').length renvoie 10. Comme toutes ces consœurs, cette méthode marche aussi à partir d'un élément du DOM, restreignant ainsi les résultats.

Il faut faire attention en manipulant la liste renvoyée. Elle est "live", c'est-à-dire que tout changement dans le DOM la modifie (comme getElementsByTagName). Exemple:

var list = document.getElementsByClassName('post');
for (var i=0; i < list.length; i++)
{
  list[i].parentNode.removeChild(list[i]);
  alert(list.length);
}

En exécutant cette fonction sur la page d'accueil, on verra disparaître un billet sur deux et la NodeList diminuera au fur et à mesure. Attention donc en manipulant les résultats. Pour être sûr de ce qui va se passer, on peut recopier le tout dans un tableau classique, mais attention aux performances.

Cette méthode est actuellement supportée par Safari 3.1 (of course) et bientôt Firefox 3 et Opera 9.5. Elle fait partie du brouillon pour HTML 5.

Vous voyez évidemment à quoi ça sert ? Ça accélère considérablement tous les accès qu'on peut faire, si on l'utilise. Et comme de plus en plus de gens utilisent des librairies pour ne pas s'embêter avec les compatibilités entre navigateurs, on va vérifier qu'on bénéficie bien de cette amélioration quand disponible. On va surtout étudier les méthodes du style $ ou $$, qui permettent de sélectionner des éléments à partir d'un sélecteur CSS

Bilan : Ah bah c'est pas génial. Si j'étais mesquin, je dirais que c'est une raison de plus pour ne pas utiliser de librairies Javascript. À leur décharge, ce n'est pas vraiment nécessaire puisqu'elles utilisent XPath lorsque c'est disponible et c'est disponible sur tous les navigateurs ayant cette méthode. Pour jQuery, c'est regrettable, puisqu'elle n'a pas d'implémentation XPath. Bien évidemment, XPath est plus rapide que DOM, mais tout de même plus lent que getElementsByClassName.

Mais finalement, on verra bientôt qu'il y a d'autres méthodes pour nous aider.