Archives par mot-clef : javascript

Je l’ai déjà évoqué à de multiples reprises sur ce blog, mais je vais le refaire. La mise en cache est une pratique clé pour les performances. L’idée est simple : mettre dans une variable locale une autre variable contenue dans une autre. Pas besoin que l’élément mis en cache soit très bas dans l’arborescence de son objet. Même au premier niveau vous aurez un gain si l’objet parent tout en haut est global. Exemple : var App = function () { controllers : [ one : {}, two : { some : "value" } ] }; if(undefined !== App.controllers[0].some) { App.controllers[0].some = "thing"; } Ici le script va d’abord vérifier si monObjet est local. Non. Il va donc remonter d’un score et non, toujours pas. Encore un scope, on arrive en global, et là on y est. Cette recherche … Continuer la lecture

Une assertion est un terme utilisé dans le cadre des tests unitaires. Elle définit un appel de fonction qui est censée retourner true. Ce sont l’ensemble des assertions qui constituent les tests effectifs. Si toutes les assertions répondent vraies, le test est donc valide. Exemple, avec MochaJS, outil de tests unitaires pour JavaScript : var assert = require("assert"); describe('Array', function(){ describe('#indexOf()', function(){ // ici, on annonce le début du test it('should return -1 when the value is not present', function(){ // Ceci est une assertion, répondant vrai assert.equal(-1, [1,2,3].indexOf(5)); // Ceci en est une autre, répondant faux assert.equal(-1, [1,2,3].indexOf(3)); }) }) }) Ici les assertions sont tous les appels à l’objet assert. La fonction it() est le test effectif.

On m’a toujours dit que $("#test").hide().show(); // est moins rapide que $("#test").css('display', 'none').show(); Mais, ça m’embêtait un peu parce que hide n’est pas réellement un alias de display:none. Sauf que moi, je suis aussi un peu fainéant. J’aime bien hide parce que ça va plus vite écrire. Et surtout, ça donne pas un peu moins l’idée qu’on peut jouer directement avec les CSS dans du code JS. Après tout, à part pour quelques raisons pratiques quasi indéfendables, manipuler les styles via le JS plutôt que le CSS n’est pas une bonne idée. Autant ne pas y faire explicitement allusion. Du coup, j’ai fait un JS Perf. Je suis satisfait de voir que je vais pouvoir continuer de faire mon fainéant et utiliser hide(). Les résultats ici : http://jsperf.com/jquery-hide-or-display-none

Vous avez sûrement déjà croisé ce genre de code : (function($){ /*…*/ })(jQuery); Et vous vous êtes sûrement demandé pourquoi il y a jQuery en paramètre pour être du coup re-traduit en $. Qui pourtant vaut déjà $ dans les variables globales. La blague, c’est que de nombreux sagouins ont tendance à coller diverses choses dans leurs sites en plus de jQuery. Du genre du prototype ou encore du mootools. Ou d’autres bibliothèques qui exploitent le $. Donc par sécurité, passer jQuery en paramètre vous assure que dans le corps de la fonction ci-dessus, $, c’est bien jQuery et pas autre chose. C’est d’ailleurs aussi pour ça que vous croiserez des fois ça : (function($, undefined){ /*…*/ })(jQuery); Là c’est pour vous assurer que undefined vaut bien undefined. Si si, j’ai déjà vu des bachibouzouks surcharger undefined …

Aujourd’hui, j’ai décidé de m’attaquer au mythe que ++i serait plus performant que i++. Une histoire d’allocation de variable en mémoire tampon qui ferait que i++ retourne la valeur de i avant l’affectation alors que ++i retourne directement la nouvelle valeur. Traduction codée : var i = 42; console.log(i++); // 42 console.log(i); // 43 i = 42; console.log(++i); // 43 console.log(i); // 43 Vous saisissez mieux ? Et bien, hormis sur Chrome 31 où il y a une différence de 10% (environ) en faveur de i++, les résultats pour tous les navigateurs sont similaires. Aucun des deux n’est notablement plus rapides que l’autre. Rien ne justifie donc de changer votre façon de coder sur ce point. Rumeur infondée en JS à priori. Les résultats des tests sur lesquels je m’appuie sont disponible à tous sur JSPerf : http://jsperf.com/increment-an-integer

Il y a peu, j’ai rencontré un problème. Je travaillais sur une appli one-pae assez lourde avec AngularJS et j’avais besoin qu’elle soit accessible sur mobile ou en dégradé sur du IE8 par exemple. J’ai donc fait le choix du lazy loading de mes composants. Et là, la doc de AngularJS n’en parle tout simplement pas. Lazy loading Le lazy loading, c’est tout simplement le chargement d’éléments quand on en a besoin et non immédiatement. Ressource Je suis tombé sur ce site : http://ify.io/lazy-loading-in-angularjs/. Il explique bien la solution mais j’ai plusieurs soucis avec celle-ci : j’utilise curl ; j’utilise UI-Router. Curl J’ai utilisé mon outil de comparaison de loaders de scripts pour déterminer ce que j’avais besoin et en l’occurrence, curl est mon favori. De ce côté là inverser $script par curl n’est pas compliqué pour un sou. Il suffit … Continuer la lecture

Une réalité du travail dans le monde du commerce, que ce soit « B2B » ou « B2C » (skills bullshit bingo et anglicismes de merde + 1), c’est que vous vous retrouvez en général vite à lier des partenariats et avoir besoin de collecter des infos depuis leurs média à eux. Dans mon cas, j’avais besoin d’échanger des données depuis d’autres sites, notamment pour prendre des demandes clients (affiliation). Hors nous connaissons tous la règle dite de Same Origin Policy Cette règle interdit tout échange via XHR sur un autre domaine que celui où est exécuté le script. Pour contrer ça, il existe JSONP, jQuery propose évidemment son exploitation. Tout comme ExtJS, Mootools, qooxdoo, … JSONP JSONP, ça veut dire tout simplement JSON Padding. Ou encore tout simplement, du JSON encapsulé. Comment ça marche ? C’est très simple. Au lieu d’aller charger du JSON, … Continuer la lecture

Venez discuter JavaScript entre confrères, le mardi 10 décembre au Lock Groove. A partir de 19h30. Le Lock Groove Bar ambiance rock psychédélique années beatles/Jackson five. On peut y discuter tranquille, manger de bonnes choses pas trop chères et boire de bonnes bières originales pour pas cher. Pour ceux qui ne boivent pas de bière ou d’alcool tout simplement, il y a aussi ce qu’il faut. Alors, vous venez ?

J’avais commencé il y a quelques mois une série d’articles sur JSLint et plus précisément sur les messages d’erreur qu’il peut générer. Et finalement, j’ai arrêté, encore par manque de temps. Ceci dit, je souhaite mettre une fin propre à cette série en vous proposant une source d’informations des plus correctes. JSLint Errors vous propose l’explication des erreurs JSLint et JSHint. Il y a tout un dépôt GitHub derrière et le site a l’air pas mal suivi et maintenu.

Salut à tous, J’ai pris la décision d’arrêter de tenir la chronique jQuery. Alors j’arrête pas de bloguer hein, j’arrête juste la chronique. Je n’avais déjà plus la motivation pour l’écrire de façon hebdomadaire. Il faut comprendre que ça me prend plusieurs heures par semaine pour lire tout ce qu’il se dit sur le net à propos de jQuery chaque semaine. Puis encore beaucoup de temps pour mettre à plat, écrire, relire et enfin publier. A côté de ça, les ressources nouvelles se font de plus en plus rare, les intéressantes encore plus. Alors que le taux de rigolos, qui continuent d’utiliser x versions de jQuery et de ne pas comprendre pourquoi ça ne marche pas, augmente de façon quasi exponentielle. Ça manquait tellement de plus en plus de ressources intéressantes que je me retrouve régulièrement à ne pas publier. … Continuer la lecture