I used atom for so long and at work we were kind of forced in a way to use vscode which opened my eyes that vscode really is better in terms of speed and auto formating etc, meaning you have plugins but it doesn't seem to add weight to it where atom just chugged. I have a 3 year old macbook pro, a spanking new macbook pro and a 2 year old mac pro. It was severely noticeable on the 3 year old one for sure and always noticeable although considerably less on the spanking new one.
I've been enjoying VS Code for a while after really trying to find a text-editor on Mac that fits my personal preferences (tab navigation, open new files in tabs in existing window, fast launch time, css syntax highlighting inside of an HTML file).
I've tried so many and like very few of them. MS seems to have done some good work on performance. It's still faster than this new version of Atom for startup, especially cold starts (with it not open at all, going into FTP client > open file).
Though, I revisited Sublime Text today, and I have to say, I know it's just a few seconds saved here and there, but the difference between Sublime and ANY other editor as far as launch/file ready time is a huge gap. While the measured time doesn't seem significant- the "feel" of using it does. It's hard to put into words how much better it feels to use, like the difference between using applications on a HDD vs an SSD.
I'm still debating (as a hobbyist that doesn't make much money on what I use text editors for) whether the license is worth it for Sublime or if I should just stick to VS Code. $80 is reasonable for most use cases (developers, etc) but it's a bit steep for mine. It really feels like it might be worth it, even just for the speed difference.
Sublime has always been king of the hill for opening giant files (like CSVs if you need to troubleshoot data imports) but unix tools and software like head and vim can take you pretty far if budget is a concern.
Is subl really that much faster at big CSV's for you? I made a quick 10 million line, ~1GB CSV in Python, opened it in both sublime text and code. code opened in 20seconds, subl took over a minute.
(copying comment to your other reply for benefits of thread)
Honestly, it's been a while since I tried. Perhaps I'll take another stab at it and see how VS Code has improved. Out of curiosity, how wide is the file? Some of the files I open are 250+ field invoices, so each line is easily 1k characters each.
Sublime: Application not responding after ~60s, waitied another 60s, no change. Same behavior each of the two times I attempted.
Atom: ~8s, smooth scroll, ~30s per jump, occasional "Editor is taking too long to load" messages.
Note: Atom enforces a maximum line length of ~500 chars before it wraps regardless of word wrap setting. This means the 8s load was only showing a couple lines worth of content. I find this restriction not acceptible for the long-line test case, but including anyways for completeness)
I doubt Sublime is faster than vim. And I doubt it's faster than opening a new file in emacs which is always running on my system. It seems that your definition of "ANY other editor" is limited to bloatware like Atom, VS Code etc.
You are mostly right, "ANY" was a poor choice of words (not to mention my unnecessary all-caps emphasis), and of course now I can't edit the post. Oops. I meant out of any of them that I consider using (I know I'm a heretic but I just can't get into fully keyboard-based editors like vim, emacs, etc).
But it does include other non-bloated apps that come close in speed, but don't have the feature set the way I want like TextWrangler, CotEditor, Geany, TextMate.
I think TL;DR - I am very picky about text editors, probably too picky.
Sublime startup time is... well, sublime. It's instant. Great for quick note taking.
But, startup time is a tiny tiny fraction of "normal use" time for anything besides jotting quick notes, and I'm weird and take notes with an actual notebook on my desk, so I don't have much use for Sublime.
There are some who feel the difference but don't care about it, and there are those like me which has what I call "latency intolerance." Where we get pissed about the 10ms difference.
This is exactly what I mean in terms of "faster". Which, for opening rather small (HTML, CSS, JS) web files, and lots of them, makes a significant difference in perception of speed.
I tried it (and TextWrangler) previously but I'm not sure what I didn't like about BBEdit, might need to revisit it. For me, my two biggest (admittedly nitpick) issues with TextWrangler are that the UI chrome itself has no dark mode and the tabs are on the side and cannot be moved to the top
I was a loyal Atom user until I tried and fell in love with VS Code. Although there's a richer set of add-ons for Atom, some of the VS Code are of a much higher quality - especially the ones backed by Microsoft. Anyway, GitLens [0] is one of the non-Microsoft ones.
I see IDE competition kinda like browser wars. I was just thinking the other day that VSCode was slower than it used to be. What if VSCode becomes slower? What if MS adds a bunch of bloat to it and it becomes like VS proper?
Similar to when Chrome was the shiny new entrant, while FF was suffering with memory leak issues. Today, the roles are a bit reversed.
If Atom can pull a Firefox I could see it taking market share away... anyway, competition is healthy, even if the value prop isn’t so clear right now.
I recall when Mozilla announced that they were dropping legacy extension support, people were upset. Firefox legacy extensions pretty much had free reign in the browser internals, making them very powerful, but also making performance improvements difficult and API changes a headache. Now that Firefox has "done a Quantum" and vastly improved performance, it has won back some users, but there's still a vocal contingent of legacy extension fans holding on to some old Firefox version or a fork.
I use Atom precisely because of its extensibility, although I'll admit I wish it were faster sometimes. I've never used VS Code but I understand it beats out Atom in performance by limiting extensibility, much like what Firefox Quantum has done. So I feel "Atom Quantum" already exists in the form of VS Code, and Atom going that direction would cause it to lose whatever proposition it has in the eyes of its users (who do exist, although you wouldn't be able to tell from this thread alone) and turn it into "a crappy VS Code/Sublime knockoff."
TL;DR: As an Atom user, I would much rather Atom keep its focus on extensibility and make performance gains where possible, rather than drop its focus and try to become VS Code.
I think editors tend to do best in the language they're made in, as thats the prime use case the developers have in mind. VS is great for C++ and C#..., but actually kinda terrible for JavaScript and TypeScript. On the other hand, VSCode is great at web, but debugging C++ in it is miserable. No support for STL containers, constant digging around in fields to get what should be at your fingertips from the start.
As for performance, I took a clean install of VS Enterprise just last night, opened the VSCode source code in it, and files would take up to 10 seconds to just syntax highlight. Compare that to opening the VSCode source in VSCode, where everything is instant. And you say VS opens as fast as VSCode? I find that hard to believe. VS has an entire loading box it shows before it even renders the main window, because of how slow the startup is. Is this a cold open or maybe restoring from an in-memory instance?
> VS has an entire loading box it shows before it even renders the main window, because of how slow the startup is
And even when it's loaded it's not done. You can look forward to some more loading when you open a code file, when you try to open the main menu and a dozen other things. They went full eclipse.
Citation needed. I never could experiment with Clang in VS, but using the MS toolchain, all the most horrible experiences I had with C++ were exclusvely tied to VS.
Pretty sure Atom will just go away soon. VS Code is better at the same thing and now that they’re under the same roof it makes no sense to keep Atom around.
I haven’t looked into it in about a month, but there are people on the atom team working on an experimental text editor engine written in rust rather than electron.
It won't be going away. Microsoft and GitHub have both independently said they see a place for Atom and they're not getting rid of it.
Let's also not forget that the deal isn't done yet. They still have 5-ish months to go before it's done. It'll probably still go through but until then they're separate companies (and even after then GitHub is becoming a subsidiary).
It has awesome packages and looks pretty good. I’m sure this comment is repeated in every post that has mentioned atom in the last year or two, so there may be some more in depth analysis if you do a search.
VSCode and Atom have nearly the same value prop. Atom’s ecosystem works better for me for the languages I develop in.
For me the biggest argument in favor of atom is that because it's based on chromium it displays emojis properly, in colors. As someone who makes use of emojis extensively as variable and function names, this is very important.
I am quite curious of the domain where you use emojis in function name? That sounds fun, and also from what I have seen of unicode support somewhat terrifying.
I work mostly in enterprise backend so variable names are typically boring, but I have never heard of emojis being used in var names.
Joking or not, Sublime renders emoji just fine as far as I can see. I am not using them for variables, but they are sometimes embedded in strings, and in this case it's nice that they render correctly. How does Atom improve emoji experience?
I think you're being sarcastic but others seem to think you're serious. Care to clarify? I'm leaning towards you're being sarcastic. I'd flip a table if I opened up code full of emojis.
Emojis make your code a little more like math formulas. In math formulas you use single letters. This makes the syntax easy to parse, but has the drawback that the letters are mostly meaningless and so not very suggestive. Names in programming language tend to be words. This makes it easier to remember what they are supposed to stand for but also make the syntax hard to parse and other occurrences hard to spot
Emojis combine the best of both worlds. Like the letters used in math they are easy to parse and it's really easy to find other occurrences of the same var when the name is an apple . But like the more verbose names in programming languages they can carry meaning. Eg I use the dango emoji for arrays and the monitor emoji for window instances.
Dango would be more appropriate for a dequeue, as it's not random access - you can only remove pieces from either end of the skewer. The bento box makes more sense for an array, because you can pick from any compartment.
Pancakes for a stack, popcorn for a heap, burrito for a monad.
Ah yes, because nothing says “data structure consisting of a contiguous block of memory broken into uniformly sized chunks so elements can be cheaply accessed by index” like a little picture of rice dumplings on a stick. Much better than just using the accepted technical term “array”.
Personally I prefer the abbreviation arrr, or sometimes yarr. Lets anyone reading the code feel like they just downed a pitcher of grog.
I'm not sure if it is more horrifying or beautiful that we inhabit an internet culture where we can't immediately write off "I use emoji as function names" as sarcasm.
In a culture where sufficiently novel things get brought up with sufficient frequency, dealing in sarcasm becomes dangerous territory; more generally jokes whose punchline rely on a phenomenon being sufficiently improbable cease to be humorous.
You know what really boggles my mind? You are the only person so far who has had a sane reaction to this. All these other people saying "this sounds like fun" are making me cringe in revulsion.
I can see it being 'fun' in something like Scratch. I expected op to reply with either some edutech or some domain I hadn't heard of. It does however seem that op is trolling, and I missed it.
The big reason I still use Atom is that it's both more visually customizable (VS Code is somewhat locked to its core layout) and that it BY FAR has the best ESlint support. VS Code is nice, and definitely faster, but it just has rougher support for addons at this point, and is just a worse UX for more complex integrations.
In general I use Sublime when I need fast editing of a one-off script, or basic work on things. I use Atom for JS development, and VS Code for the rest. If Atom was faster for starting up and handling larger projects, I'd much prefer it, but for now, I make due with VS Code.
Really, one of my biggest gripes with all of them, and VS Code especially, is that the addon ecosystem has a serious discoverability problem. If I want to find a new theme, or find a new addon for a specific language or whatever, it's much easier in Atom than almost anywhere else. When one of them fixes that, I'll be happily in on it.
I own a Sublime Text 3 license but either VS Code or Atom have a much richer plugin ecosystem. Sublime Text 3 opens in the blink of an eye so I use it to save work notes since it opens and closes so fast.
for me, atom’s initial value proposition way back when was, (well, in addition to the customizability/programmability) the third party plug-in ecosystem. It was a pretty big deal for me at the time not to have to wait for my code editor to release an extension for that-one-thing-I-use.
Atom is slow for larger files, but the vast amount of third party plugins is a great asset.
I’ve only used SSD’s since 2012.. and it’s not always the case but it’s noticeable on large files. For example sometimes I open a gigantic CSV file (at least tens of thousands of rows) or JSON file in Atom, and it really chokes. But at the same time other tools are probably better for handling such large data files so it’s not a deal breaker.
Large files. (hundreds of MBs or in the GBs) For many this isn't a use case, but if you do a lot of data loading, troubleshooting CSVs is a common need.
Is subl really that much faster at big CSV's for you? I made a quick 10 million line, ~1GB CSV in Python, opened it in both sublime text and code. code opened in 20seconds, subl took over a minute.
Honestly, it's been a while since I tried. Perhaps I'll take another stab at it and see how VS Code has improved. Out of curiosity, how wide is the file? Some of the files I open are 250+ field invoices, so each line is easily 1k characters each.
I love Atom and use it as my default text editor. There are all these people talking about IDE wars in the comments. I feel like Atom is an enhanced text editor at best. But the comparisons to VSCode and then eventually IntelliJ...not even the same ballpark.
> But the comparisons to VSCode and then eventually IntelliJ...not even the same ballpark.
VSCode is pretty close to Atom in many ways (though some of its plugins and things like the integrated terminal get it closer to IDE territory)
Are you sure you're not thinking of Visual Studio rather than Visual Studio Code? (2 entirely different projects; Code isn't a subset or a "lite" version)
I am talking about VSCode, but you make a good callout about the two products because many people may not realize the differences. I agree that VSCode and Atom are similar, but you are right, and I feel like many people, end up using plugins to the point that push VSCode to IDE levels.
Integrated debugger is a big step on the way to IDE-land as well. Having it interact with high quality language servers takes it another step (find all refs, jump to definition, etc). Throw in automated tasks and build rules and the line between enhanced editor and IDE starts to get really blurry.
Tried VS Code several times, and failed to set it up correctly, so that I would be able to edit files over SSH and see a tree of files (without syncing, downloading entire projects, etc...). I just want to connect, browse to the needed file, double click on it, edit, save and close it. May be someone who has similar needs can point me to the right plugin/tutorial, I would try VS Code again?
But for now, using Atom as my primary editor, and was able to set it up the way I described above. Plugin which I use to edit files over SSH is Remote FTP (https://github.com/icetee/remote-ftp), if someone is interested.
I tried to do something like this for a while, but ended up much preferring a local copy of the codebase with the changes rsynced across to the server. Without the files locally, the editor wasn't able to index them, so it was a little janky to jump to other files in the project, and a lot of the utility of plugins (like automatic code completion) just didn't work great since it couldn't find the relevant files to use.
You should give the Atom plugin nuclide a try, it has really good remote code editing support (including indexing the files, which was someone elses criticism). You do need to install a server script, but it still just works over ssh. https://nuclide.io/docs/features/remote/
What I've done is install VS Code on the remote system (usually a dev VM) and with X forwarding I open up VS Code, works perfectly, as others have suggested another approach is to just mount the VM or remote systems drive somewhere on your local machine but I've yet to try this.
I like Atom because I can keep it a relatively dumb editor. I hate autocomplete, I hate automated code formatting usually (I do occasionally use Prettier to get legacy code cleaner) and I don't want to see my linter until I go to make a commit.
I do wish Atom was faster, especially on Windows. I do appreciate the support for ligatures in font though, and how easy it is to change editor behavior as I go.
It's nice to see some love for BBEdit. I confess that I use VS Code for programming more often, but I'm a technical writer, and I almost always use BBEdit for my work. The other day I had to do a task that boiled down to "recursively search for all files in this directory that do NOT contain the following text, then in the result set, run the following regex-based search and replace." In BBEdit, this is essentially a two-step operation (the first search, then a "text factory" with the regex search-and-replace that used the search result window as the input). I'm sure there are other editors that could do that same operation, but I have doubts how many could do it as easily.
Really, if I could bring a couple of the more "IDE-esque" bits over from Code (most notably language-sensitive smart indent, something I'm boggled Bare Bones hasn't broken down and added yet), I'd probably just stick with BBEdit full time still.
There is no reason for Microsoft keeping two Electron-based code editor.
Would be nice to see how both communities from VSCode and Atom can work together and drive an even better coding experience with an unlimited extensions ecosystem.
Expect Atom to be killed, or just have security updates very soon. Microsoft has teams right now looking at what they can bring in from Atom before shelving it. No sense in having two "electron" based editors.
I hope vscode copies the text search interface from atom - after using atom for awhile I switched to and love vscode but the more functional/information rich search result navigator is the buggest thing I miss from atom ...
Long time Emacs user here. I’m enjoying Atom more and more on each new release. It’s not slow anymore and the UI is really minimalistic and clean. Highly recommend it.
I'm surprised that no one asking this - but what's the future for Atom in VSCode in light that they are pretty much direct competitors AND developed by same company now. Any plans to merge teams / unify development? ( Or opposite, close one of the projects ? ) Competition was definitely beneficial to both of them, but is it common to have healthy "intra-company" competing products?
Nat Friedman, who will be the new CEO of GitHub, answered this. He said that both would be maintained as long as there were dedicated users, and that he expected it to be for a very long time.
I expect it could be used to promote Microsoft.
Surprisingly, Atom doesn't even say GitHub above the fold on https://atom.io/ There's an octocat above the fold, but it doesn't mention GitHub until further down the page.
Since Microsoft has taken over, perhaps my take might hurt people's confidence in Github in light of that news...but they really should just kill off Atom and focus on VS Code. I'd rather they focus energy on building other tools.
How is Atom with a11y? I tried using VoiceOver with Atom but I couldn't quite get it to work. Is accessibility something the Atom team is committed to?
