Why choose Atom? (ATOM vs VISUAL STUDIO CODE)



Consulting some random web searched topics will have me believe that Visual Studio Code is the better framework. My question is not a straight one on which one is best. It is rather: Why do you choose Atom?

I have spent some of my private time with Atom. Yet I have the feeling I am betting on the wrong horse. I hope to convinced otherwise.

#####Allow me to disclose my position and first impressions -
I am an industrial PLC coder (LAD/FBD/SCL) by day. This started with me wanting to learn Python. The need is to process work data more effeciently than what LibreOffice Calc can handle. I am starting at the bottom with all ‘this’ (text editor / program languages).

My own installation of VSC does seem more capable than Atom right out of the box, for a beginner like me. Having built-in terminal that can run scripts and handle name = 'Your name: ' makes so much sense.

Atom has a terminal as an optional Package which I’m still not sure which one is best. My current choice seem buggy. VSC also offer change tracking for not-connected-to-web work, again out of the box. The footprint of VSC is more friendly for my 5th generation (mobile) i5.

Atom does seem more friendly on making changes to Packages. I could already customize the ‘buggy’ Terminal Package to make it capable to run scripts with a touch of a button. Coffeescript (Atom) does seem more friendly for me than TypeScript (VSC).

All I am trying to do is discover the right fit for me without spending too much time teaching myself both frameworks. I hope to also be able to give back to the community with some custom changes to Packages / Extensions.

I hope on a constructive chat that will help a n00b like me.

  • Dan Padric


I use Atom because it feels like every part of the program is open to me to be modified. I haven’t taken advantage of this as much as I could, but I place value on the aesthetic experience of using a program where, at any point, I can go into the source code, tweak it, and rebuild it. If I download a package and am less than happy about how it’s working, I can change that package.

Atom has its weak points. Every Electron app contains a minimum amount of bulk. Atom is a bit slow and has a few substantial bugs and doesn’t hold your hand about anything, but for those flaws I get an editor that is putty in my hands, its potential limited only by my understanding of JavaScript. I’ve used and abandoned tools in the past because they were too opinionated or didn’t have the feature I wanted. Atom feels like something I can use for as long as I’m typing things up on a computer, for every purpose.

I’m a dabbler. A dilettante. I play with scripts and make digital toys and then abandon them to move on to other hobbies. I tried and greatly disliked IT as a profession, so what I do I do purely for the fun of it. I need an editor that can facilitate my disjointed projects. For many years, this was Notepad++ for me. It had basic language highlighting and an FTP plugin and that was basically all I needed. Then I decided that I needed the ability to make my own language highlighting scheme and the rigidity of N++'s system led me to search the Internet for something new. I found Atom. From the first day, I was able to find packages that did things I wanted from my editor. I was able to find language packages other people had written, and I could understand most of what they were doing. I found a rich API and I learned CoffeeScript and could make the editor do anything I wanted it to, though my grasp of MVC is still a bit shaky. At this point, I wouldn’t call myself brand loyal, but I’m at home with the program.

Which package do you have, and what bugs are you observing?

Coffeescript (Atom) does seem more friendly for me than TypeScript (VSC).

Internally, Atom is actually transitioning to ES6, if I recall correctly, but I’m not sure where I can find a source for that. For packages, any language that compiles into JavaScript to run in the browser will work just fine with Atom.


Good to hear from you. Thank you for your reply.

I think you and I would have had some good conversations over some coffee.

To answer your question - perhaps look at

You have answered elsewhere that you use a Package that is a fork from the one I mention. This one a fork from an abandoned (?) project. In my opinion a terminal should be cornerstone of an app like Atom. Important enough to attract in-house development. It seems as though Microsoft agrees with me on this point.

It is not really that important to me if ES6 (what is it?) (Javascript V6) is used or not. The interface I prefer as “customer” is to use Coffeescript instead of straight on JS. If I had a choice I’d go for Python if given a choice.

For Package development it would be real nice if you go test run code snippets in the language you develop it in. In other words, no need to convert to JS if already in Coffeescript or Typescript. In honesty, if you provide for the one, you might as well provide for the other too.

My first impressions of the tutorial help provided for Extension development for VSC is not rounded of nearly as well as tutorial for Packages in Atom. Atom’s version has some small mistakes and gaps that leaves a beginner in the dark for a while. It is worse for VSC… not showing all the steps leaving gaps in the tutorial.

What I do like VERY much is the debug section incorporated in the before mentioned tutorial. A built-in functionality that is well in your reach and hidden in Atom.

I hope this sparks some others to join in with sharing opinions.

  • Dan Padric


I use Atom for similar reasons to @DamnedScholar. It is nice to have an editor I know that I can easily customize and build on. It was also time for a change from NP++ :). However, I am not the best at giving such an open-ended response, so that’s all I have to say at the moment.

I’m not positive about what you’re asking, but I’m fairly confident that you can use any language for package development provided that there is an npm package available that transpiles it back to Javascript. Popular choices of course include Coffeescript, Typescript, Flow, and bleeding-edge Javascript.

Please do comment on what you were confused on and what mistakes you saw! Better docs help everyone :slight_smile:

One of the more fundamental differences between Atom and VSCode is that Atom started out as more of a multipurpose editor, whereas VSCode started out as more of an IDE. It’s why VSCode decided to include a terminal and Atom didn’t. Of course, that distinction is becoming blurrier and blurrier as Atom is adding on more IDE features and the general proliferation of packages. I’m definitely with you though on wishing that Atom shipped with an official terminal package (though I don’t deem it important enough to go install one - occasionally tabbing out to Powershell isn’t too much of a hassle for me).

Finally, I noticed that you talked about VSCode offering “change tracking for not-connected-to-web work”. I’m not too familiar with that (maybe I’m used to a different term); what is that exactly?


Are you talking about the developer console? Because that’s built by the people at Google and I don’t know if it’s possible to rig it up to transpile things you put into it.

@danPadric has been looking for a way to get git-diff working when he doesn’t have an Internet connection. I figured that it would work to have a repo on a LAN network, but there hasn’t been much success on that front.


@Wliu: Thanks for jumping in.
@DamnedScholar: Welcome.

No, I was not talking about console specifically. When developing some code, some research and testing is required. Especially if it is something new (Atom API). Creating a full Package just to have code space to write little test code snippets / modules / procedures / functions does not really make sense to me.

PLUS each time after a change you have to restart (CTRL-SHIFT-F5 / window:reload). I was wishing for a test environment that works like you have for scripts. (1) code the function (2) save the file (3) execute the code (4) change the code (5) save the file (6) execute (7) {repeat until done} (8) Save function as reference (9) Do next function. (10) Divide and conquer.

More directly put - Some functionality that helps me track changes that occur. Without being connected to a server.

A valid point to make. I was hoping to be convinced that Atom is the one to commit to and get involved with because of a strong community and feature rich environment.

I have respect for guys and gals sharing their skills in developing open source and shared programs. One vital flaw is that it seems as everyone wants to do their own thing. Just imagine (example) what GIMP would be today if all the resources were channelled to there instead of the branched off or unique projects. Combined efforts is very powerful but working to a common goal seems against human nature.

Internal / local / on-your-own-hard-disk version control and difference monitoring.


Now I have gone into much “nonsense”. Some more of that but to the subject at hand.

Microsoft’s Visual Studio Code seems to be much closer to an IDE than Atom… out of the box.

Atom seems at first glance to be more friendly to hack and expand to one’s needs. That means as user you have the opportunity to make Atom feel like home.

The price you pay within Atom is that the components (Packages) that can give the text editor some IDE powers - Those components are community driven. High demand from other users or loss in interest can make the curators abandon the projects. Especially true if they stand alone in driving the package.

The IDE type components in VSC is part of the core. The main curators are from Microsoft, assisted by the community.

My opinion - some packages that gives Atom IDE abilities should be absorbed as core packages. Unless a unified effort is made by the community to support and build stronger packages.

Short term (opinion) - VSC seems to be the right choice if you are looking to use the app to create code and not create code for the app. Atom is the choice when wanting to create code for the app.


I would argue that restarting Atom is executing the code. It just takes 10 - 30 seconds longer than the instantaneous results you get in a REPL. That is, perhaps, undesirable considering the small amounts of JavaScript that people are writing, but it’s a fairly snappy turnaround time compared to some things (imagine how long it takes to make iterative small improvements on an operating system).

If you want, you could fairly easily write up a CoffeeScript command that disables and then re-enables your package and attach it to a keybinding. In fact, there’s a package that already does that.


There have been big performance improvements in 1.17, 1.18 and 1.19 including rewrites of performance-sensitive code as native components. This affects both day-to-day editor response times, start-up times (snapshots, spell-check startup) and large file handling.

As for IDE like features, that is launching soon - the UI and a core set of languages will be maintained by the Atom team who are also helping the community with additional languages and are making it as easy as possible to provide richer language support through language servers much like VS Code (actually the same protocol)


I think what you wrote is pretty accurate except for the last part. I’d argue that Atom isn’t just for writing packages for Atom (then what would be the point of using Atom in the first place? :slightly_smiling_face:) but for people who want a balance of having a capable editor that has (almost) no preconceived notions of what you’re going to do with it and being able to modify that editor to their needs. Conversely, VSCode seems to be for people who want a more structured editor that makes people familiar with IDEs feel at home at the cost of some customizability.



All things being equal, I find that on a decent powered Apple Mac, the performance of Atom and VSCode are roughly equal. In other words, both are pretty damn snappy. For me, it comes down to what language I am coding. If I am coding Golang, I will tend to choose VSCode, largely because the Delve debugging plugin for Go, has been particularly well supported in VSCode. If I am coding Python, on the other hand, I will always choose Atom. This because I use the Kite Co-Pilot plugin and it seems to have better support in Atom compared to any other editor - the code completion especially is very good in Atom with Kite. Horses for courses, I think the phrase is!


Exactly! Both are really good at this point.


This might come as a suprise, but I use neither. However, I develop packages/extensions for both, Atom and Visual Studio Code, so I got to know both quite a bit and each has its pros and cons. Performance-wise, I think they are about the same, which in my case is not enough (yet!). There are editors that are much more performant than what I currently use, but for me it’s about finding the best compromise between features and speed.

I agree with what you said about Visual Studio Code, it feels like a complete editor to me, since it’s already equipped with features that are likely used by many users – the console, build tasks, language server – no matter which language you primarily develop in. Developing in TypeScript or React seems to be a pleasure using Code.

What I prefer about Atom is it’s beautiful look (out of the box!) and its powerful API – it’s far better than that of TextMate, Sublime Text, Visual Studio Code or any other modern editor. Period. I love developing for Atom and I’m hoping that one day it becomes my default editor. Earlier this year, I listened to this podcast, The Story of Atom, and IIRC there are some more performance improvements planned.

PS: I don’t think this thread belongs into the support category


AFAIK, that’s not possible. TypeScript is a superset of JavaScript, and CoffeeScript is basically JavaScript for Python/Ruby lovers. There is not interpreter for CoffeeScript, so you need to transpile it to JavaScript. But when developing Atom package, it doesn’t matter, because transpilation runs transparently. I think, in theory you could even develop in Dart or OCaml (via BuckleScript) and transpile the code at install time through a apm/npm script.

Maybe Sublime Text is for you, but it’s not open source and, as mentioned before, its API doesn’t come close to that of Atom.


I thought some more about the differences between the editors and their communities. There’s one particular thing about the Atom community that bothers me. It’s a bit like this often-cited xkcd strip:


Now what does this mean? I appreciate the openness that the Atom eco-system provides, everybody can easily create and release packages or themes. Opposed to this is the Sublime Text eco-system, with Package Control (the package manager for Sublime Text packages) being a curated system. However, it appears that Atom developers prefer publishing their own version of a package, rather than contributing to an existing one (been there, done that!) From the user perspective, this can make it tedious to select “the right” package, especially since the installation dialog offers no filtering (e.g. by rating or downloads).

It’s clear that everybody has their own preferences how a package should be done and that somebody else’s package doesn’t always serve one’s own needs – but with Atom package that got somewhat ridiculous!

Finding a nice syntax theme is a pain

Logical, to the point and well worded - Thank you.
The most valuable contribution.


Apologies for jumping in on an idle thread, but on turning Atom into an IDE, these might be relevant:

  • Nuclide - Facebook-led IDE on top of Atom
  • Atom IDE - stripped-down Nuclide offering the common functionalities


Thank you for your interest and contribution.

Not much was said about Nuclide before you have… :thinking:
As for the Atom-IDE - we will have to see what develops there.

I am hoping for a terminal with debugging tools framework that is part of the Atom core.


I have tried VSC for a merit badge to learn C#. When I took a break I have found out that it took most of my HDD space. I deleted VSC so I can look for another text editor. A few months later I got a GitHub account to make some things and look at the youtube videos. When I installed GitHub desktop I saw that is said: “external editor” at the bottom it said Atom.io text editor. So I tried Atom and I really liked it, it didn’t take all of my HDD space, I had to learn what packages were and I installed the Teletype package. Right now I think everyone should use Atom.io.


That is very strange. Do you have more detail?

I rather like the “simplicity” which Atom offers for customizing functionalities via “init.coffee”.