C’est sous ce titre volontairement ambigu et un brin racoleur que je souhaite vous faire part de ma première expérience avec Visual Studio Code. Autant le dire tout de suite, hormis une partie de leur nom, Visual Studio et Visual Studio Code n’ont rien en commun. Le premier est un EDI (Environnement de Développement Intégré, aussi appelé IDE) et l’autre est un éditeur de code enrichi avec la possibilité de déclencher des tâches automatisées.

Afin de simplifier la lecture de ce post je ferais référence à Visual Studio Code sous le nom VSCode et Visual Studio sous le nom VS2015.

Alors ? La voiture Ninjago ou le bateau pirate ?


La période de Noël étant encore proche, et heureux papa d’un petit garçon de 3 ans (oui je sais on n’est pas sur Facebook), un parallèle m’est venu assez rapidement : Playmobil et Lego. Deux univers bien distincts avec chacun leur fans et leur détracteurs. Et pourtant deux succès sans conteste. L’univers Lego centré sur la construction et les possibilités infinies de combinaisons s’apparenterait plutôt à VSCode, qui laisse le soin à l’utilisateur de définir les tâches à exécuter dans son projet grâce à des outils en ligne de commande tel que Gulp, Grunt, ou Yeoman. De son côté Playmobil est orienté sur l’expérience de jeu immédiate et serait donc plus dans l’esprit de VS2015 qui permet au travers des modèles de projets et des outils intégrés de se concentrer sur le code plutôt que sur la plomberie.

Le parallèle s’arrête cependant là, car si Playmobil et Lego sont en concurrence sur le marché du jouet, VSCode et VS2015 ne s’adressent pas aux mêmes cibles (sans être pour autant complémentaires). Précisons d’ailleurs tout de suite pour ceux qui n’auraient pas suivi qu’il ne sert à rien d’offrir un Visual Studio (Code) à votre enfant de 3 ans, il risque de ne pas apprécier…

Visual Studio est un environnement de développement complet et riche gérant tous les langages ou presque et toutes les typologies, mais disponible uniquement sur Windows. Visual Studio Code est un environnement léger et multiplateformes (Windows, Mac, Linux) plutôt orienté pour les développements sur des technos récentes (NodeJS, ASP.NET5 sur Mono/DNX, ou Unity).

VSCode est d’ailleurs toujours en Release Candidate (RC), ce qui signifie que le produit n’est pas encore finalisé. Cela explique le nombre restreint de langages et de typologies supportées. Ce côté non finalisé se fait parfois plus gênant, et il n’y a qu’à tester la création d’un projet ASP.NET 5 sur MacOSX pour s’en rendre compte. Mais VSCode évolue rapidement, et cette évolution est ancrée dans l’outil avec la possibilité d’ajouter des extensions, d’utiliser des outils en ligne de commande, et grâce également à un cycle de mises à jour plus rapides que Visual Studio. C’est donc un environnement jeune mais qui s’adaptera plus rapidement aux standards du marché et aux technos émergeantes.

Gulp, Grunt, Yeoman, Bower : Késako ?


Nous voici donc au sujet qui a inspiré le titre de cet article. En tant qu’architecte SharePoint, j’ai l’habitude de travailler avec Visual Studio dans un cadre connu avec peu d’outils tierces, le .Net Framework étant bien assez riche pour traiter la plupart des cas et VS2015 incluant déjà beaucoup d’optimisations et de tâches automatisées. Cependant en tant qu’architecte applicatif je me dois de connaître ce qui se fait d’autre sur le marché, d’où mon intérêt pour VSCode. Et c’est là que la claque arrive… A peine arrivé sur le site de VSCode (http://code.visualstudio.com) on est bombardé de termes jusque-là vaguement entendu ou lu à droite à gauche : gulp, grunt, yeoman, bower,…

Très franchement au début on se demande bien à quoi cela peut servir. Puis en lisant les tutoriaux et la documentation de VSCode on se rend compte à quel point tout est à faire, et ô combien ces outils vont se révéler précieux. Loin de moi l’idée de décrire ceux-ci en détail (je vous laisse vous référer à leur site respectif) mais il me semble utile de préciser rapidement à quoi servent certains pour illustrer mon propos.

Gulp et Grunt sont deux « task runners », c’est-à-dire des outils permettant d’exécuter automatiquement des tâches, soit à la demande (par exemple pour préparer un déploiement), soit de manière automatique (par exemple à l’enregistrement d’un fichier). Dans VSCode on peut s’en servir par exemple pour transpiler des fichiers TypeScript en JS. Transpiler ? Oui vous avez bien lu, ça fait aussi partie de l’aventure : des nouveaux vocabulaires à utiliser. Transpiler c’est transformer un langage en un autre, il ne s’agit donc pas d’une vrai compilation mais plutôt d’une conversion. Ici un fichier TypeScript (qui est un superset de JS) est converti en JS pur pour permettre son interprétation par les interpréteurs JavaScript (Navigateurs, NodeJS,….).

Yeoman (Yo pour les intimes), est un outil de « Scaffolding » ou d’échafaudage en bon François de chez nous. Et vlan, un autre nouveau terme au passage. Pour ceux qui ne savent pas ce qu’est le « Scafffolding » : cela permet de créer des structures de dossiers et de fichiers à partir d’un template. On peut donc choisir dans une liste un template et Yo s’occupe de créer la structure de dossiers, copier les fichiers par défaut, et configurer certains fichiers (grunt ou gulp par exemple). Dans VS2015 cela s’apparenterait à la création d’un nouveau projet. Et c’est là une grande différence entre VS2015 et VSCode, quand le premier fourni un cadre de travail préconfiguré, avec un nombre de projet de base assez conséquent, le second n’offre de base qu’un éditeur de contenu. Tout est à faire vous dis-je !

La brique versus le préfabriqué


Vous vous souvenez de mon analogie Lego / Playmobil ? On est en plein dedans ! Par défaut VSCode ne va rien vous imposer, libre à vous d’utiliser Gulp, Grunt, Yeoman ou autres, c’est très flexible. Cela demande par contre un effort de mise en place non négligeable pour un développeur qui n’a pas baigné dans ces outils. Il n’y a pas de template tout fait dans VSCode (mais on peut en trouver sur le site de Yeoman). A l’inverse VS2105 guidera plus volontiers l’utilisateur avec des templates tout prêts, quitte à l’enfermer dans un certain cadre. Les deux possibilités ont avantages et inconvénients, comme pour les jouets : à chacun son choix.

La démarche mise en place par VSCode a cependant ses limites car il n’est pas possible actuellement de traiter toutes les typologies de projets : exit ASP.Net MVC, exit Azure, etc… Pour le moment VSCode gère le Web nouvelle génération (comprendre NodeJS / ASP.NET 5), des framework multiplateformes (Mono, Unity), les outils front office (AngularJS, React, SASS, LESS,….) et quelques langages annexes type Markdown pour la description de projet dans Git.

Ca y est le mot est prononcé : Git. Car il faut bien l’avouer lorsque l’on prend en main VSCode pour la première fois on ne peut s’empêcher de penser qu’il a été conçus pour les projets hébergés via Git (et plus particulièrement GitHub). Même organisation en dossiers, même convention, support du Markdown,…

Microsoft s’adresse donc avec cet éditeur, non pas aux utilisateurs Visual Studio standard mais plutôt à tous les autres développeurs, qui ont l’habitude de travailler sur d’autre éditeurs. Nul doute que pour ceux-là : Gulp, Grunt, ou Yeoman n’ont rien d’inconnu.

Et c’est pas fini…

(Tout ressemblance avec une publicité récente est bien évidemment fortuite…)

Avec tous ces outils à installer (et bien d’autres), il vaut mieux un bon outil de gestion de package, car VSCode ne le fera pas pour vous. N’y voyez aucune malveillance, il s’agit là encore de ne pas vous imposer d’outil, et de ne pas réinventer la roue. Il existe en effet pléthore de gestionnaires de packages : npm, bower, homebrew,…

Pour ma part, le choix a été vite fait : NPM (Node Package Manager), le gestionnaire de package de NodeJS sera selon moi votre plus fidèle ami. Il est simple, largement utilisé, supporte un grand nombre de packages (et d’autres sont ajoutés quotidiennement) et est disponible sur toutes les plateformes.

Si la démarche d’utiliser les outils existants est louable, il faut bien avouer que garder un terminal ouvert en permanence et jongler entre NPM et VSCode est un peu casse pied. Un accès à ces lignes de commandes depuis VSCode aurait amélioré l’expérience utilisateur (surtout sur un Mac ou basculer d’une fenêtre à l’autre est plus pénible que sur Windows).

Fort heureusement NPM est facile d’usage, et les outils précités également. Il n’y donc rien d’insurmontable pour un développeur prêt à se retrousser les manches.

Alors ? Heureux ?


J’avoue que sur Windows je garderais très volontiers mon VS2015 (ou à défaut un Visual Studio Community). Par contre ayant fait l’acquisition d’un Mac récemment et développant sur Linux depuis déjà quelques temps, l’option VSCode est plus qu’intéressante. Cela permet d’avoir un éditeur commun sur les trois environnements pour faire du C# et / ou du NodeJS.

Reste que pour un développeur habitué à un Visual Studio standard, la claque est bien ressentie. Mais soyons honnête, malgré les problèmes de jeunesse et la courbe d’apprentissage un peu rude au départ pour maîtriser tous les petits outils annexes, VSCode est convivial, et bien pensé. Et puis comme indiqué, la cible est plutôt les développeurs utilisant des solutions similaires et qui n’auront pas à apprendre l’usage des outils tierces qu’ils connaissent déjà en général.

En définitive, peut-être que Microsoft aurait dû utiliser un nom différent pour cet outil très convainquant afin de ne pas entretenir une fausse filiation avec Visual Studio qui reste tout de même mon IDE préféré.

Article aussi disponible via LinkedIn : https://www.linkedin.com/pulse/visual-studio-code-quel-choc-edgar-maucourant?trk=prof-post