Malgré le rachat de Github par Microsoft, ces derniers ont annoncé qu'ils allaient continuer à soutenir et développer Atom. Je me suis demandé pourquoi la question se posait, et je découvre que Microsoft a développé ces dernières années un éditeur similaire, VSCode, gratuit et multi plate-forme.

Est-ce qu'il y en a parmi vous qui peuvent faire un retour sur VSCode, et particulièrement sur ses avantages ou inconvénients avec Atom ? J'utilise Atom depuis quelques années (après avoir délaissé Sublime Text) et je l'apprécie, mais il est "lourd" à charger, et c'est la principale raison qui fait que je lance encore quelques fichiers dans gedit de temps à autre quand il s'agit juste d'une petite édition à faire sans avoir à bénéficier des moultes features de l'éditeur.

Du coup, quand je lis que VSCode est considéré comme étant pratiquement instantané et bonne alternative à Atom, je me tâte

J'ai fait le même chemin Sublime Text vers Atom, sauf que moi Atom c'est mon éditeur léger, j'utilise Intellij en IDE polyglotte principal.

Je sais que VSCode est très bien mais je n'ai pas fait l'effort de changement pour remplacer Atom, vu que c'est un éditeur que j'utilise à la marge je n'ai pas vraiment envie de passer par une phase d'apprentissage.

Je crois avoir lu que GDI utilisait VSCode, mais est-ce qu'il est passé par la case Atom ? Je suis preneur d'un feedback aussi, en tous cas

Je suis preneur de vos lumières. En effet, j'ai récemment changé de machine et d'OS au boulot (le mac a finalement tiré sa révérence au bout de 10 ans, il a été bien amorti !) et je n'ai pas encore eu à développer autrement que modifier trois lignes ici et là. Je suis désormais 100% linux au taff aussi.

Du coup, mon éditeur du moment est (attention, séquence barbu !) ... vim (que c'est une tuerie atomique, il faut comprendre que ce n'est pas un éditeur texte mais que tu n'écrit pas du texte dessus, tu donne des ordres à celui-ci pour qu'il le fasse), qui est certes super, mais quand je vais devoir refaire un vrai nouveau projet, je vais probablement reprendre un éditeur un peu plus user-friendly.

Et donc je songeait à Atom. Qui sur mon vieux mac était totalement inutilisable vu qu'il ouvrait une instance webkit avant de s'ouvrir, donc 30-40 secondes de chargement (Sublime Text s'ouvrait en 1 sur le dernier projet ouvert). Ou juste regarder ce qui se fait désormais. Il y avait aussi le projet open source d'adobe (brackets), aucune idée de là où il en est désormais.

Bonus point si l'éditeur que je choisirai comprend les keybindings vi. Sublime le faisait, mais c'était pas idéal.

Alors VSCode, c'est de la balle, sérieusement. Très léger et rapide, des tonnes et des tonnes de plugins, complètement gratuit et open-source...

Je l'ai utilisé pour faire un projet en Angular 2, et franchement aucun souci. Le debug intégré, les outils d'aide au dev (genre intellisense), la rapidité de l'éditeur, tout ça a fait que c'était un charme à utiliser.

J'avais déjà utilisé Atom pour un projet perso en RoR, et ça m'avait moins impressioné à l'époque, mais bon je pense que les 2 se valent, si ce n'est que VSCode a vraiment le vent dans le dos pour le moment et progresse énormément à chaque release (petit + pour l'intégration de Typescript dans VSCode, les 2 équipes travaillent de concert, et ça se sent dans le tooling)

J'ai fait quelques essais avec VSCode aujourd'hui. Essentiellement, je l'ai utilisé dans le contexte de développement d'un petit outil Python mono-fichier, sans git, et aussi dans le contexte d'un papier (Latex) avec git et multi-user.

Tout d'abord, VSCode est effectivement plus rapide qu'Atom au chargement, que ça soit en activant ou désactivant les extensions. C'est assez surprenant, car les deux éditeurs proposent grosso-modo les mêmes features de base et reposent sur la même technologie (Electron), mais il y a facilement un facteur 2 sur le temps d'ouverture des deux cotés. Le fait que VSCode affiche la fenêtre plus vite (même si le contenu n'est pas encore visible) doit jouer également sur cette impression.

Au niveau du feeling global (ergonomie, etc.) c'est fort comparable. On retrouve la merveilleuse command-palette, la sidebar et la statusbar avec grosso-modo le même genre d'informations dedans. La command-palette me semble plus réactive que celle d'Atom, et probablement plus simple à utiliser (même si les commandes sont malheureusement triées par "frequently used", ce qui signifie qu'il faut quand même lire les résultats avant d'en choisir un ). Coté réglages, VSCode travaille avec un fichier de config global et en parallèle, la config utilisateur. C'est moins ergonomique qu'un vrai "panneau de settings", mais ça fait le job. A noter qu'il y a une option permettant d'utiliser le panneau de settings qui sera prochainement intégré. Dans les deux cas (Atom et VSCode), on est en terrain connu et ça reste simple à manipuler.

Coté extensions, elles sont moins nombreuses dans VSCode, mais beaucoup plus riches. Par exemple, il ne faut qu'une seule extension (et ses dépendances) pour avoir un full support de Python (environnements virtuels, linter, autocompletion, ...). Pour Latex, c'est pareil (latex-workshop pour VSCode, contre linter-latex, language-latex et latexer pour Atom). Ca a ses avantages et inconvénients, mais ça permet de rentrer plus rapidement dans le "vif du sujet".

Pour le support de git, c'est intégré dès deux cotés. VSCode semble proposer d'autres providers, mais je n'ai pas essayé (et je suppose qu'Atom a sensiblement la même chose, même si je ne sais pas si c'est "compatible" avec l'ergonomie/UI de git dans Atom). Dans les deux cas, on a accès à tout ce qu'il faut pour "naivement" utiliser git. Il y a une extension sympa pour VSCode (gitlens) pour avoir rapidement accès à l'historique des modifications et au "blame" notamment. Je ne sais pas si je vais la laisser active ou pas, on verra à l'usage.

La gestion de projets est une question délicate pour moi. J'ai toujours détesté, sur ce type d'éditeurs, devoir configurer mes projets. Dans Atom, j'utilisais un addon qui considérait chaque répertoire comme un projet potentiel, ce qui permettait (via CTRL+P) de passer rapidement (fuzzy search) d'un fichier à l'autre, ou d'avoir accès à la completion sur base des fichiers présents dans le même répertoire. Ca marchait bien, même si c'est un peu chiant parfois quand on a un folder "fourre-tout". Je retrouve le même feeling du coté de VSCode, sauf qu'il faut impérativement "ouvrir un répertoire" au préalable (si on ouvre un fichier, les autres fichiers dans le même répertoire ne sont pas considérés comme étant "disponibles" immédiatement). Ce ne sera pas problématique, vu que le raccourci CTRL+R permet d'ouvrir un répertoire récent en un clin d'oeil.

Au niveau de Latex, j'ai du chipoter un petit peu. Le workflow dans Atom est simple pour moi : je travaille sur un fichier, je fais CTRL+ALT+B pour produire le PDF, le PDF est ouvert dans Evince, et synctex me place directement au bon endroit dans le PDF. En cas de modification, j'ai juste à sauver puis refaire CTRL+ALT+B. Dans VSCode, j'ai du chipoter un petit peu au niveau de la configuration de latex-workshop pour avoir quelque chose de sensiblement comparable. Premièrement, il n'est pas possible d'utiliser un visionneur de PDF externe. On a deux options : soit un tab directement dans l'éditeur (mais ça ne colle pas avec mon travail sur plusieurs moniteurs, surtout que les tabs ne sont pas facilement détachables quand ce ne sont pas des fichiers), ou alors via le browser. Avec ce dernier, le workflow est simple : CTRL+ALT+V pour lancer l'ouverture du pdf, puis à chaque fois que je sauve, le PDF se met à jour à l'emplacement du curseur. On verra à l'usage si c'est "tout aussi pratique", mais ça ne devrait pas fondamentalement changer les choses (on est vite attaché à ses habitudes, hein ? ).

Pour l'instant, j'ai donc configuré VSCode pour que ça soit l'éditeur par défaut, le temps de me faire la main avec ce dernier. C'est surtout sa vitesse à l'ouverture qui m'intéresse.

Il reste cependant quelques "détails" :
- Le gutter semble être placé à droite, dans la scrollbar du document. Or j'ai l'habitude d'avoir les infos de linting affichées à gauche. Je n'ai pas trouvé la possibilité de changer ça.
- La barre d'activité (quelques boutons pour ouvrir l'explorateur de fichiers, le scm, les extensions, etc. en gros, la sidebar) est par défaut à gauche. Il m'a fallu chercher pour la placer à droite (hint : y a une commande "toggle side" !). Je n'aime pas la sidebar à gauche car je la cache dans 90% des cas, et quand on l'ouvre, ça "décale" le fichier sur lequel on travaille, donc on perd ses repères visuels.
- Bonus point pour le support des environnements virtuels en Python, même s'il est impossible de configurer un linter/mypy spécifique pour chaque environnement (j'ai donc un linter python3 global, quelque soit l'environnement, et je ne peux pas utiliser mypy pour l'inférence de type, vu que chaque environnement dispose de ses propres librairies, ce qui n'aurait pas beaucoup de sens pour mypy).
- Si tout se charge plus rapidement, il faut quand même signaler qu'à l'ouverture d'un fichier, il faut bien 3 à 4 secondes avant que certains plugins ne se mettent en route (par ex, l'affichage des lignes modifiées ou même le linting). C'est du détails, mais quand même Au final, Atom est sans doute plus rapide sur ce point car l'éditeur est dans un état "totalement utilisable" un peu plus rapidement.

Beaucoup de gens dans ma boîte sont passés sur VSCode et en sont ravis.

Pour ma part j'utilise toujours Webstorm plutôt que VSCode, j'ai mes habitudes et les outils visuels de merge sont vraiment sans équivalent* (c'est la seule interface visuelle que j'utilise pour du GIT).

Et pour du texte simple (genre modifier une conf hors projet), j'utilise Geany.

Dans l'IT de ma boîte, les fronts-end devs utilisent donc soit du VSCode pour tout, soit du Webstorm + éditeur léger.

* Et aussi c'est Microsoft l'éditeur. Déjà qu'étant sous W10 et devant compiler notre backend avec Visuel Studio je fais de sérieuses remontées acides, alors je me console comme je peux…

Seconde journée avec VSCode (ouais, ça fait un peu journal du naufragé, du coup ).

Je regrette de ne pas avoir migré plus tôt Le support pour Latex est vraiment, vraiment très bien implémenté et bien pensé. La command-palette étant super réactive, c'est également très agréable. Le support pour Python est aussi très très bon, à tel point que je vais l'utiliser pour 2 projets en cours pour lesquels je travaillais avec PyCharm jusqu'à présent (le support Python inclut directement un déboggueur ainsi que le support pour les suites de tests, même si l'output pourrait être un peu plus "claire". Y a aussi un support pour les virtualenvs, ce qui est assez rare). A propos des suites de test, j'ai été étonné de voir deux petits boutons discrets, entre deux lignes de code, permettant de "run" et "debug" individuellement chaque test. C'est la première fois que je vois ça dans un éditeur supposé "léger".

L'intégration avec Git est bien fichue. Il y a quelques "détails" embêtant (pas de "commit --amend" directement dans l'UI, il faut passer par la command-palette ; pas de fetch mais un synchronize qui pull+push). Le tout est super réactif, ce qui fait bien plaisir.

Je confirme cependant que la "grosse" différence avec Atom en terme de vitesse vient certainement du chargement "lazy" des extensions : l'éditeur s'ouvre super vite, mais il faut parfois plusieurs secondes (jusqu'à 10 dans un gros projet Latex) pour que tout devienne disponible. Ca reste utilisable en attendant, mais si votre premier réflexe est de "pull" les derniers changements, il faut parfois attendre

J'ai du chipoter un peu pour intégrer un support pour les dictionnaires (rien de bien grave, mais la première extension choisie - la plus populaire - était un peu pourrie paradoxalement, alors je me suis rabattu sur une autre qui a nécessité de lier (ln) les dictionnaires systèmes. Rien de grave, mais voilà, c'est une étape en plus à faire).

Coté UI, je regrette juste l'affichage des linters qui est un peu moins bons que dans Atom :
- Les hint/info/warning/error s'affichent dans la barre de scrolling (contre le "gutter" dans Atom sous forme de boules, typiquement) et soulignent les éléments concernés (mais c'est parfois un seul caractère, donc on le voit pas bien alors qu'Atom souligne typiquement le "mot", et Sublime text encadre la section, ce qui est encore mieux). Et le listing qu'on retrouve dans la barre de status n'est pas facile à naviguer (on peut filtrer "à la main" en tapant le texte à chercher, mais ça fait un peu ch... d'avoir un listing qui mélange les lint de spelling, de typage, de doc, de style, ...).