DEV Community

Discussion on: Why I switched from Atom to Visual Studio Code

Collapse
 
ocoka profile image
Ivan Ocoka • Edited

Hello people, last time I posted a comment was 2 years ago I think, but I can't get past that article.
I'm a developer (frontend mainly) for 13 years, for that period I've used a lot of editors (VIM, Eclipse, IntelliJ, Wingware, VisualStudio (not code), Netbeans, JDeveloper, Emacs, Atom, VSCode, a lot of...), yeah, I just like editors, and like to try them all.
Then I met Atom I was charmed, after all that years I just found it, all the features that I want in one editor, of course, not all of them was "out of the box", I'm using about 120 community packages, and of course, some of them I found a much later, some of them I've written by myself.
For people, who stated "Atom so worthless comparing to VSCode", I think they are just lazy and don't want or can to craft the things, they are "consumers", and corporation like Microsoft controls them by that meaning.

  • the main claim over Atom is "performance" and its related to chosen by Atom team plugin architecture (I will talk about a little bit later)
  • Atom team do a lot of work, got many investigations about editors and UI performance, written a lot of articles, and that work, with no doubt, formed the basis of VSCode UI architecture
    • we can't forget that not so time ago Microsoft just bought the Github (Atom developers), and, of course, that played its role in VSCode promoting and improvement

Ok, now about people comparing features amount:
Atom team stated at the very beginning that: "A hackable text editor, for developers from developers"
1. A hackable (you gave all the power to adopt editor for yourself)
2. The text editor (it's just not stated that Atom is IDE, it's not, only plugins can make it a full-blown IDE)

Atom: hackable text editor
VSCode: IDE for people that don't want to hack anything

But, "With Great Power Comes Great Responsibility":
If you do things incorrectly and do it many, then you, of course, should fill that ( because you do it for yourself :) )
Many plugins are written without deep knowledge about Web performance, and who will ever do such optimization from the beginning, where the main thing to provide some functionality in short time (for ex: "GIT log visualization", it's slow but it works, and if you want, you can hack that concrete plugin, change rendering system, make PR, profit)
And Microsoft take it into account and make plugin architecture where all plugin run in the isolated process, and can't access the UI, the API provides the list of capability points, and you can only declare what you want to displays, but not how, and that's the reason why Microsoft has to had to implement many things out of the box
Atom just don't provide any UI API, at the beginning they have something that was called "Pen View", but later it was deprecated with the notation that you can use all power of web technologies, and people do, each start to use it's own preferable web frameworks to form UI for their plugins: React, Angular, Vue ... etc so now Atom UI with plugins it's some Zoo ))

VIM support in VSCode is ugly, comparing to Atom. It's funny I've seen just identical issue, one in Atom, second in VSCode repository, all from different authors, but each about same: "I need feature X in core to implement feature Y in Vim plugin", Atom team: "ok, let's look into the matter and we will fix that" (and they fixed), VSCode team: "ok, let's talk about it", and at that moment M$ manager arrives and close that issue with words like: "We have more priority things to do right now, happy coding" (aha, for example, make some bells and whistles)
p.s: factory always wins over crafters