Classe !

Pouvoir faire de la complétion dans un <textarea>, c’est possible, avec tx-content-assist, c’est possible !

C’est en fait une réécriture du moteur d’assistance de code de Eclipse, et c’est même possible de le déclencher avec « Ctrl+Espace » / « Alt + Espace » (enfin, certains navigateurs l’ont déjà reservé).

Pour une petite démo, c’est par ici, pour les sources, c’est sur github.

Pas de flash, pas de chocolat

Futurs possesseurs de l’iPad, farouches combattant du Flash, vous voulez vous aussi pouvoir utiliser un outil de dessin On Line ?

Alors voici SketchPad, une application de dessin proche de Photoshop Express et des autres outils d’online painting, mais avec un particularité : Il est développé en HTML5/Javascript. Tout est donc contrôlé via des Canvas, vous n’avez donc pas besoin d’avoir Flash sur votre machine (mais un navigateur compatible HTML5 qui supporte les Canvas).

Have fun !

jQuery 1.3 sort, enfin

Youpi, houra et autre bravos … jQuery 1.3 est enfin sortie des cartons !

Ce n’est pas juste une version de plus, c’est (a mon humble avis) la release qui va faire de jQuery THE librairie Javascript.

• Sizzle, le moteur de sélecteur CSS dont j’avais déjà parlé est enfin en place, avec des performances bluffantes ;
• jQuery devient la première librairie JS qui ne fait pas de Browser Sniffing, et il était temps ;
• Une grosse réécriture de l’HTML Injection, avec aussi, un gain de performance étonnant ;
• Pleins d’autres choses !

Re youpi ! Re bravo !

Voici donc un petit panaché d’astuces d’optimisation de jQuery, un peuplus poussées que de combiner et minifier les sources.

Payez-vous le meilleur des CDN !

Grâce à Google AJAX API, vous allez pouvoir utiliser le plus puissant, le plus rapide et le plus stable des CDN, j’ai nommé Google !

Les avantages sont énormes :

• Vous réduisez le délai de connexion et de téléchargement de vous utilisateurs : Google a forcément des serveurs près de chez eux, voir dans leur garage ;
• Vous réduisez la charge de votre serveur : Une requête en moins sur votre serveur, c’est plein de ressources laissées libres ;
• Vous réduisez le temps de chargement : Vous êtes probablement pas le premier site consulté utilisant Google AJAX API, jQuery est probablement déjà dans le cache de votre utilisateur ;
• Vous réduisez vos frais de bande passante : jQuery, c’est quand même 94Ko de code javascript. Sur un million de visiteurs, c’est presque 100Go économisé.

L’intégration est super simple, après avoir inclut le fichier source :

Il ne reste plus qu’a loader jQuery (avec la version voulue, c’est mieux) :

google.load('jquery', '1.2.6');

Utiliser des ID le plus souvent possible

Spécifier ses éléments dans le sélecteur en précisant leur ID est beaucoup plus rapide. L’explication est logique :

• Quand il peut, jQuery se base sur getElementById(), qui (théoriquement) est optimisé ;
• En cas de parcours du DOM, il s’arrête, quoi qu’il arrive sur le premier élément trouvé, ID devant être unique.

Un petit test sous firebug sur la home page du blog nous en dit long :

console.time('Selector on id');
for (var i = 0; i < 10000; i++) {
	jQuery('#imonline');
}
console.timeEnd('Selector on id');

	 // Selector on id: 236ms

console.time('Selector on class');
for (var i = 0; i < 10000; i++) {
	jQuery('div.sidebarboxbottom');
}
console.timeEnd('Selector on class');
	// Selector on class: 5266ms

Contextualiser les sélecteurs

Par défaut, lorsque l'on définit un sélecteur, typiquement $('div.cssClass'), jQuery va traverser TOUT le DOM à la recherche des éléments respectant ce sélecteur. Or, il arrive souvent que notre recherche ne soit pertinente qu'à un certain niveau du DOM, par exemple, à l'intérieur d'un <div> et l'on a souvent l'habitude (parce que la lisibilité est accrue et que c'est plus rapide à taper) de garder le parcours entier du DOM avec l'écritude $('div.cssClass').

Cependant, grâce au concept d'enchaînement de jQuery, on peut contextualiser un sélecteur dans un ou plusieurs éléments donnés. Cela permet non seulement d'éviter des erreurs lorsque la conception d'un page change et surtout d'optimiser le code, jQuery ayant moins d'éléments à traverser.

Exemple :

/**
 * Ne recherche des input que dans des forms (évidemment)
 */
$('form').find('input');
/**
 * Écriture alternative, recherche les li qu'a l'intérieur d'un ul nommé
 */
$('ul#myList', $('li'));

Réduire au maximum les opérations de sélécteur (surtout celles qui sont inutiles)

Le résultat d'un selecteur n'est pas forcément un donnée volatile à chainer, type $('div#errorBox').hide().remove(); Cette écriture est certes très pratique mais nous perdons le résultat de $('div#errorBox'). Cette erreur de conception typique vient du nommage de la fonction $ qui, certes, rend le code beaucoup plus lisible, mais induit le codeur en erreur ; lui faisant penser que $('div#errorBox') est une variable et non un appel de fonction.

Un développeur doit toujours se demander lors de l'utilisation du sélecteur $ si ce resultat va être utilisé à nouveau après cette ligne ou pas.

Exemple :

/**
 * jQuery va retraverser le DOM 100 fois à la recherche de ul#list
 */
for (var i = 0; i < 100; i++) {
	$('ul#list').append('
Numéro ' + i + '

');
}
/**
 * jQuery va retraverser le DOM une seule fois à la recherche de ul#list
 */
var	list = $('ul#list');
for (var i = 0; i < 100; i++) {
	list.append('
Numéro ' + i + '

');
}

Inutile de dire que dans ce cas, le gain de ressource est énorme !

http://is.gd/bJOt

SocialHistory.js est un petit bout de Javascript totalement intrusif mais vraiment bien pensé !

Il permet de détecter quels sont les sites sociaux utilisés par l’internaute qui visite votre site. Ca peut permettre par exemple de n’afficher ques les icônes utiles (Digg This, Sumble Upon this site, etc.) à afficher, au lieu d’en afficher 50.

Le fonctionnement est très bête mais vraiment efficace : il crée un iframe cachée dans votre page et y insère les liens vers des dizaines de sites. Après il ne reste qu’a utiliser une petite faille connue depuis des années. Les liens déjà visités sont mauves, les autres sont bleus.

On peut donc supposer qu’un site déja consulté est un site utilisé … simple, mais efficace !

JSLint, the Javascript Verifier

Quand je code, en général, je suis assez gadget-o-phile. Voire même excessivement, j’ai quelques fois eu tendance à passer plus de temps a maîtriser un outil de développement qu’a développer ! Maintenant, c’est vrai que utliser les bons outils au bon moment est souvent un des piliers d’un développement réussi et d’un planning respecté. Cependant, concernant Javascript, je me suis contenté, jusque là, de Firebug.

Cependant, Firebug est un outil de debuggage, mais pas un vérifieur de syntaxe, et c’est là ou JSLint intervient. Le cas classique (en ce qui me concerne), c’est la virgule en trop dans la définition d’un object :

  var myOptions = {
    'propertyA' :      5,
    'propertyB' :      'string',
  };

Cette virgule en trop, après ‘string’ est un mauvais reflexe que j’ai acquis en codant en PHP, et est d’un point de vue syntaxe incorrect. Resultat, ce code vas marcher sous Firefox, mais pas sous IE, qui m’indiquera une erreur très précise comme ‘Syntax Error’.

Passer ce code dans JSLint, nous donne donc :

JSLint Screenshot on error

Pratique, non ?