Interview d’un créateur de framework javascript
John Resig vient de publier depuis son blog une présentation sur l’état de JQuery en 2008 qui lui a servi d’appoint lors de récentes conférences. Cette présentation montre la position dominante qu’a gagné JQuery au fil des années et qu’il occupe aujourd’hui. Mais en dehors de JQuery, c’est tout le monde de javascript qui connaît actuellement un renouveau, pour ne pas dire une renaissance.
Je vous propose aujourd’hui l’interview de Evandro Myller, le créateur d’un nouveau framework javascript : UTM.
UTM est un framework qui se distingue sur ce qui constitue le point faibles des frameworks javascript : la vitesse d’exécution (de 40% à 60% plus rapide que JQuery sur les sélecteurs, selon mes benchmarks). Il offre déjà quelques effets intéressants (dans le domaine d’un scriptaculous ou d’un JQuery UI) dans un module qui ne demande qu’à être complété. Il propose un interface de construction du paquet lors du téléchargement en choisissant les composants et en proposant la compression, comme pour le téléchargement de JQuery UI. Mais laissons plutôt la parole à Evandro pour présenter UTM.
D’abord, peux-tu te présenter un peu et expliquer à nos lecteurs ce qu’est UTM?
Et bien, que dire à propos de moi… Je suis chrétien, développeur web se concentrant sur l’expérience utilisateur avec Javascript. J’ai commencé à apprendre ce langage il y a seulement deux ans, mais ça a été mes deux années les plus productives et amusantes.
À propos d’UTM, je suis dessus depuis un peu plus d’un an, quand j’ai commencé à développer quelques bouts de codes isolés pour m’aider (j’apprenais le JS, et je n’avais aucune idée qu’un jour, je construirai un library). Le projet à démarré réellement il y a quelques mois, sur cette idée d’il y a un an. Aujourd’hui, UTM (UlTiMate javascript library) est un projet dont le but est de donner au programmeur (débutant ou expert) le pouvoir d’écrire des choses cool et puissantes avec quelques simples lignes de code.
Quelle est à ton avis la différence principale entre UTM et les autres framework/libraries?
Je crois que je peux répondre : ses performances. UTM peut faire ce que font les autres libraries, mais il a été conçu autour de conventions qui s’assurent que sa structure est réellement simple et rapide. Le core ne fait que le strict nécessaire pour fournir le bon résultat en moins de temps. C’est donc une bonne base pour tous les composants d’UTM (les effets, les modules supplémentaires, etc). Il a aussi quelque chose de différent et d’utile : un système de modules simple d’utilisation. Vous pouvez importer des modules et leur appliquer des thèmes externes d’un manière très simple : u.include(’your_module’) et, accessoirement, u.useTheme(’theme_name’).
Est-ce qu’UTM s’intègre avec d’autres framework?
Oui. Si vous avez vraiment besoin d’un autre library javascript sur votre site, il n’y a pas à s’en inquiéter. UTM conserve tout dans son namespace, ‘utm’. ‘u’ est un raccourci vers UTM lui-même. Il n’y a donc aucun problème pour travailler avec une autre library, parce qu’il ne change rien du code natif. Et, tu sais, ni ‘utm’ ni ‘u’ ne sont des noms de variables utilisés couramment, n’est-ce pas? =]
Peux-tu démontrer que UTM rox, en trois lignes de code?
Wow, c’est vraiment dur de choisir quoi montrer ici… Mais essayons. Peut-être…
- u(’div#main p.text:contains(”some text”)’)
- .append(’a.mainlink[href="page.html"]‘, ‘Some link’)
- .pulsate(5);
Explications…
1 : C’est un sélecteur CSS3 qui récupère le paragraphe avec la classe ‘text’ et ’some text’ quelque part à l’intérieur, depuis le div qui à l’id ‘main’.
2: Ensuite, ça ajoute un nouveau lien à la fin du paragraphe. Oui, on peut utiliser un sélecteur CSS ici aussi, pour spécifier l’id, la classe et les attributs.
3: Rien qu’un effet. Le nouveau lien va maintenant pulser (fade out puis fade in) cinq fois. =]
Les sélecteurs de JQuery et de UTM sont vraiment plus rapides que ceux de Mootools, et les sélecteurs de UTM sont même encore plus rapide que ceux de JQuery. Peux-tu expliquer pourquoi?
Bien sûr. À la base, UTM tourne plus vite pour trois raisons : la structure du code, le cache et la réutilisation des données des sélecteurs.
Quand je récupère un élément avec un nom de tag depuis un contexte, UTM stock un pointeur vers l’ensemble; donc, si j’ai besoin du même ensemble plus tard, UTM va simplement s’en resservir (ne vous inquiétez pas si un élément a été ajouté ou retiré: HTMLCollection est un objet natif de JS et n’a pas besoin d’être récupéré à nouveau).
Quant à la réutilisation des données, une fois que vous donnez un sélecteur à UTM, il est traité pas à pas et stocké en tant qu’objet. Il sera donc réutilisé par l’ensemble du moteur de sélection sans devoir être retraité à nouveau.
Et tout le code lié aux sélecteurs se trouve au même endroit. C’est simple à lire, toutes les fonctions sont placées au meilleur endroit possible.
Tu m’as dit que la réponse à la question “quelle est la library la plus rapide” peut changer selon le navigateur et l’environnement. Peux-tu expliquer pourquoi et comment UTM gère ça?
Cela dépend de deux facteurs : quelles fonctions du navigateur la library utilise et comment le navigateur gère le code. Par exemple, certains navigateurs ont une fonction appelée ‘document.getElementsByClassName’. C’est réellement plus rapide que n’importe quelle autre manière de récupérer des éléments à partir d’un nom de classe, et donc UTM l’utilise quand le navigateur la connaît.
Le navigateurs peuvent aussi avoir des comportements différents sur les même fonctions. IE6, par exemple, gère les instructions switch beaucoup plus lentement que Firefox. UTM essaie de s’adapter au navigateur tout en ayant le code le plus simple possible.
Pourquoi UTM n’est pas entièrement orienté objet? Est-ce que ça a un impact sur les performances?
L’objet principal utm est entièrement orienté objet. Le prototype principal possède toutes les méthodes que nous pouvons utiliser sur des éléments du DOM. Quelques fonctions simples ne sont pas orientées objet parce qu’elle ne doivent vraiment pas l’être, pour des raisons de simplicité.
Prenons par exemple u.Window (objet provenant du module window) et u.scrollTo (fonction non orientée objet provenant du module scroll). Nous pouvons faire :
var myWindow = new u.Window({ title: ‘a sample window’ });
Cela a du sens, n’est-ce pas? Maintenant…
u(element).scrollTo(target);
Comment utiliserions-nous cela avec new? N’est-ce pas plus simple de cette façon? =]
La library est donc orientée objet quand c’est nécessaire pour des raisons d’usage/performance. Les fonctions les plus simples comme u.trim ou u.clean n’ont vraiment pas à être orientées objet, mais u.Request et u.Window le doivent.
Est-ce qu’il est difficile d’élargir UTM avec de nouveaux modules?
Non, c’est très simple. Il vous suffit d’ajouter une nouvelle fonction au core ou à la collection de ses méthodes d’éléments, ou d’écrire un module. En fait, il suffit d’ajouter du code dans le namespace utm, dans utm.methods, la collection de méthodes customs. Si vous écrivez un plugin, tout est déjà prévu pour que le code soit ajouté automatiquement au chargement.
As-tu besoin d’une quelconque forme d’aide? Apprécierais-tu d’être rejoint par des codeurs français, et que peuvent-ils faire?
Bien sûr! C’est un projet open-source qui a besoin de nous tous pour en faire le meilleur choix pour chacun. Je serai ravi si des codeurs français (et des gens de partout) étaient intéressés par le projet et commençaient à jouer avec. Tout type d’aide serait le bienvenu - opinions, suggestions, code, design de thèmes, tout.
Merci d’avoir sacrifié un peu de ton temps à cet exercice. Bon courage pour la suite :)
Merci pour cette opportunité de répandre UTM et de le montrer à tes lecteurs! J’espère que le projet sera de plus en plus utile à tous. =]
4 octobre, 2008 à 16:03
Interview d’un créateur de framework javascript…
John Resig vient de publier depuis son blog une présentation sur l’état de JQuery en 2008 qui lui a servi d’appoint lors de récentes conférences. Cette présentation montre la position dominante qu’a gagné JQuery au fil des années et qu’i…
27 avril, 2010 à 18:40
Tres interessant!, juste un petit detail le nom utm framework est deja pris il me semble par une société depuis environ deux ans concernant un framework PHP5 objet que j’ai eu l’occasion de voir sur quelques projets. C’est dommage de partir sur un nom deja pris.
Bonne continuation a vous
Michel
1 mai, 2010 à 18:49
Bonjour Michel,
Effectivement, c’est un nom suffisamment court pour risquer les conflits :)
Le framework a été renommé depuis, d’ailleurs. Il s’agit maintenant de mandoo :
http://github.com/emyller/mandoo