Tim Caswell, un membre connu de la communauté JavaScript et Node.js, a eu l'idée de réimplémenter Git en JavaScript et a réussi à financer son projet en 28 heures avec un peu plus de 360 investisseurs. Le projet est un autre exemple de la loi d'Atwood: "toute application pouvant être écrite en JavaScript sera un jour écrite en JavaScript."
InfoQ a interrogé Tim pour en apprendre plus à propos du projet.
D'où est venue l'idée de JSGit ?
Je suis toujours à la recherche de nouvelles façons de développer sur les appareils que je possède. Des personnes de Microsoft m'ont récemment envoyé une Surface RT, j'ai deux iPad grâce à des précédents projets et je viens juste d'acheter un ChromeBook Pixel. Il s'agit d'appareils intéressants, mais j'ai été un peu frustré qu'ils soient si verrouillés et très hostiles au développement. La plate-forme que personne n'ose verrouiller, pas même Apple, c'est JavaScript dans le navigateur. Vous pouvez générer et exécuter du code, accéder au stockage local et vous pouvez envoyer et télécharger des données sur internet.
Après avoir travaillé sur Cloud9 pendant un an, j'ai réalisé qu'un IDE dans un navigateur est maintenant possible. Le seul problème que Cloud9 n'a pas bien résolu est la partie hors-ligne. Je souhaitais pouvoir cloner mon repo Git localement sur mon appareil, travailler hors ligne tout en traversant des océans (ou en traînant tout au fond de mon jardin), puis une fois de retour sur internet, envoyer les changements dans mon repo Git public.
Comme Javascript est devenu la plateforme disponible partout, j'ai décidé que je voulais vraiment porter Git dessus.
Qu'est que vous imaginez comme cas d'utilisations pour JSGit, est-ce seulement pour les IDEs et éditeurs basés sur le navigateur, ou est-ce qu'il y a d'autres applications possibles ?
Mon cas d'utilisation principal est pour les environnements de programmations dans le navigateur, mais beaucoup de personnes ont exprimé leurs intérêts pour d'autres utilisations, tel qu'un client et serveur Git en pur JavaScript pour Node.js. Git est composant commun dans beaucoup de systèmes de déploiement et avoir un contrôle plus fin de Git pour les serveurs et clients Node.js pourrait être très utile à plein de personnes.
Est-ce que vous avez une idée des performances ?
JavaScript est lui-même est assez rapide, j'ai récemment écrit quelques fonctions de hachage très performantes (MD5, SHA1, SHA256) en JavaScript et j'étais capable d'avoir jusqu'à 500 000 hash MD5 par seconde sur mon navigateur de bureau. Puisque cloner un repo Git est lent même avec le client natif sur un portable pour les repos importants, je ne m'attends pas à gérer correctement ce cas. Mais pour les petits repos, je m'attends à ce que ce soit plutôt rapide.
Pourquoi ne pas prendre l'approche de la cross-compilation de l'implémentation existante en C de Git avec quelque chose comme Emscripten plutôt que de réimplémenter tout à partir de zéro en JavaScript ?
J'ai l'intention de me pencher dessus, mais à partir de mes recherches initiales je vois 2 problèmes. Premièrement, Emscripten est un générateur de code. Il génère une assez grande quantité de code et finit par être un portage direct sauf si vous modifiez manuellement beaucoup de code. Deuxièmement, en regardant l'implémentation en C de Git, ils sont extrêmement liés au système de fichiers et aux appels réseau. Cela nécessiterait une personnalisation importante pour une version de Git basé sur le navigateur. J'aurais besoin d'écrire à la main une abstraction du système de fichiers pour toutes les plateformes web puisqu'elles ont chacune leur propre API pour le stockage des fichiers.
Il y a des implémentations de Git en C, Java et d'autres langages, d'après vous quel seront les challenges de le faire spécifiquement en JavaScript ?
Je suis plutôt expérimenté dans l'implémentation de trucs de crypto en JavaScript, donc je ne m'attends pas à ce que ce soit un problème. Mais la quantité de code qu'il va falloir produire va être un problème. Je prévois de travailler sur le strict nécessaire en premier puis ajouter des fonctionnalités jusqu'à ce que je manque de temps.
Pourquoi faire ce projet maintenant ? Est-ce qu'il y a des technologies HTML5 qui permettent de le faire aujourd'hui ?
C'est plus à cause du matériel. Il y a de plus en plus d'appareils qui ont des batteries avec une grande autonomie et de supers écrans, mais offrent des expériences de développement pas terribles.
Votre projet a été financé en un peu plus d'une journée, quelles fonctionnalités pensez-vous être capable de faire avec l'argent que vous allez recevoir ?
Comme je l'ai estimé dans mes objectifs, j'espère avoir les fonctionnalités essentielles de Git implémentées et s'il y a le temps, quelques intégrations avec différentes plateformes.
Pourquoi Kickstarter ?
Cela semblait une bonne idée au départ. Jusqu'à présent ça fonctionne, même après avoir lu toutes les règles Kickstarter, j'ai le sentiment que ce type de projet rentre parfaitement dans leur idéal d'un projet.
Pensez-vous que d'autres projets (JavaScript) open source devraient essayer de se faire financer sur Kickstarter ?
Je ne sais pas encore, c'est une expérimentation. J'aime l'idée d'obtenir du soutien sur un projet avant de passer des mois à travailler dessus. J'ai déjà passé des centaines d'heures de mon temps libre sur des projets passé pour ensuite me rendre compte qu'il y avait qu'un petit intérêt de la communauté. J'aime vraiment l'idée de travailler à temps complet sur des projets cool dont les gens ont envie. Je ne sais pas si Kickstarter fonctionnera sur le long terme, mais je vais continuer à chercher d'autres idées si ce n'est pas le cas. JSGit n'est pas le premier projet JavaScript à réussir à obtenir son financement sur Kickstarter. Il y a eu des projets tels qu'un livre sur la programmation asynchrone en JavaScript et une série de screencast sur le TDD en JavaScript. Cependant, JSGit est le premier projet Kickstarter destiné à produire une librairie JavaScript.
Le projet est ouvert aux investisseurs jusqu'au 30 mars 2013. Tim s'attend à commencer à travailler sur le projet peu après la fin de la date limite.