Rik Arends vient de publier TraceGL, un nouvel outil pour déboguer une application JavaScript en utilisant trace debugging. Pour simplifier le debug et comprendre les applications web complexes ou basées sur Node.js, l'outil capture, visualise et laisse l'utilisateur naviguer entre les traces d'exécution pendant que l'application tourne.
TraceGL est composé de deux parties : un serveur basé sur node.js et une application cliente basée sur WebGL qui tourne dans un navigateur web. L'interface utilisateur composée de quatre panneaux montre une mini carte de l'arbre d'exécution en haut à gauche, une version agrandie d'une partie de l'arbre en haut à droite, une pile d'exécution en bas à gauche et le code exécuté en bas à droite. Lors du survol d'une variable dans le code, l'interface montre la valeur de la variable. De plus, l'arbre d'exécution des structures de contrôle est affiché.
Pour en savoir plus sur ce projet, InfoQ s’est entretenu avec son créateur, Rik Arends.
Pourquoi aviez vous besoin de TraceGL, les débogueurs intégrés aux navigateurs web ne sont pas assez bon ?
Les débogueurs des navigateurs sont définitivement de mieux en mieux, mais ils fonctionnent dans un mode "point d'arrêt/pas-à-pas". Tout d'abord, vous devez savoir où mettre votre point d'arrêt, et si vous passez au-dessus de la mauvaise fonction, vous devez tout recommencer depuis le début. Avec une trace, toute l'exécution est enregistrée. Ce qui signifie qu'à la place de faire du pas-à-pas, vous allez voir toute la logique d'un coup, toutes les variables et les paramètres des fonctions sont visibles, et vous pouvez utiliser la recherche, et la visualisation de l'agrégation des données. Vous ne pouvez plus rien louper. En plus, comme il s'agit d'un enregistrement, vous n'interrompez pas le programme. Surtout avec un code basé sur les événements, le comportement est différent si vous mettez un point d'arrêt quelque part, avec les traces d'exécution le code se comporte d'une manière plus naturelle. Et maintenant que l'enregistrement peut être partagé, ce qui ouvre de nouvelles possibilités pour aider le débogage dans un processus d'assurance qualité.
TraceGL m'a certainement appris beaucoup de chose à propos de mon propre code et des bibliothèques comme jQuery, juste en errant autour du code.
Il y a t'il des types d'applications pour lesquelles cela est particulièrement utile ?
Plus vous avez de code, plus vous avez besoin d'un traceur, surtout si ce n'est pas votre propre code. Utilisez-le sur n'importe quelle application HTML5 assez complexe et vous apprenez beaucoup de chose sur votre code. Voir ce que fait votre code lorsque vous vous déplacez dans l'interface utilisateur est vraiment agréable. Cependant, je dois dire que TraceGL est aussi très utile pour Node.js. Comme c'est entièrement dirigé par les évènements, le débogage par point d'arrêt n'est pas un choix naturel, mais les traces d'exécution le sont. La disponibilité d'une pile de closure vous permet de naviguer dans et hors de la fonction de rappel simplement en cliquant sur la fonction, ce qui est très pratique. C'est comme avoir une fenêtre dans votre serveur et pouvoir voir ce qui s'y passe.
Comment TraceGL fonctionne, intègre t'il une machine virtuelle JavaScript ? Est-ce qu’il instrumente le code ?
TraceGL fonctionne à la fois comme proxy, et serveur de fichier et il marche en instrumentant votre code JavaScript, de la même manière que CoffeeScript est compilé en JavaScript. J'utilise l'excellent analyseur syntaxique de Marjin Haverbeke, et donc je modifie le code source de façon non destructive. Lors de l'exécution de ce code source modifié, il enregistre tout l'arbre d'exécution à travers une connexion WebSocket, via le processus de Node pour l'interface utilisateur pour la visualisation. Cela signifie que traceGL n'a pas besoin d'une connexion de débogage à la machine virtuelle JavaScript. Il peut tout aussi facilement tracer votre code sur un téléphone mobile, que sur un backend Node.js.
Quelle technologie est utilisé pour implémenter l'interface TraceGL ?
Étant donné que TraceGL peut recevoir un volume important de données en entrées, j'avais besoin d'afficher et de faire défiler beaucoup de texte. Pour expérimenter, j'ai décidé d'écrire toute l'interface utilisateur en webGL, et faire un rendu en texte via des vertexbuffers statiques. Cela signifie que quand l'on défile ou que l'on zoom, il y a très peu de traitement au niveau du JavaScript, étant donné qu'il n'y a qu'un seul appel pour afficher une grosse partie du texte. J'ai implémenté une boite à outils basique pour l'interface avec une gestion de zone, et j'ai écrit un compilateur GLSL pour les shaders qui gère le style de l'interface utilisateur. Ce qui veut dire que je n'utilise plus de CSS pour styler quoi que ce soit, mais j'écris plutôt de petits bouts de code de shader. Toute l'interactivité marche via une sélection de rayons et une liaison de données d'un DOM JavaScript avec des variables de shader. Si vous allez dans cette voie, vous aurez à gérer les écrans Retina par vous même, mais ça marche très bien. Je suis originalement un codeur graphique en C++, donc pouvoir faire une interface rapide sans HTML dans un navigateur web a été très rafraichissant.
Est ce que TraceGL marche avec les langages de compilations vers JavaScript, comme CoffeeScript ?
TraceGL peut instrumenter et afficher la sortie d'un compilateur CoffeeScript, mais je n'ai pas encore le support pour faire correspondre le code source au code CoffeeScript d'origine.
Alors que TraceGL n'est pas un éditeur ou un EDI, il donne une sensation similaire à de la "programmation en direct", comme LightTable. Tandis que LightTable le fait en vous montrant les résultats individuels de chaque fonction anonyme et vous permet de les éditer pour influencer les résultats, avec TraceGL vous gardez votre propre éditeur, et utilisez l'interface de TraceGL pour visualiser l'arbre d'exécution soit en direct, soit après coup.
TraceGL est disponible sur son site web pour $14.99. Il est distribué en tant qu'un seul fichier JavaScript et marche sur toutes les plateformes qui peuvent faire tourner Node.js et les navigateurs web surportant WebGL (principalement les versions récentes de Chrome et Firefox)