The file open times where we are talking about a difference of just over half a second for files which are larger than most web-devs (the target market for Atom and VSCODE) shouldn't make a difference in real life usage.
However, where the big difference comes is in searching across an entire project. Want to find all references to `someVar` it's super snappy in Sublime and 10x slower in VSCode and Atom (of course, it depends on the size of your project as well, but my projects are not that large).
Having said that, I'm still using VSCode, my biggest hope is improved search performance. The Git integration is fantastic.
For my programming class in the upcoming winter, I'm finally switching to Atom from Sublime Text as the recommended default text editor for my (novice) students. My reasons, in descending order of importance:
1. Atom has nice defaults, such as spaces for default tabbing and automatic trimming of white space upon save. In ST, you have to manually alter the user config file.
1.5 Atom has much better file handling in its project sidebar -- e.g. Right-clicking a file brings up the expected options for moving/copying/etc a file. And the dialog box is much clearer. In ST, IIRC, I have to install 2 separate plugins to have that convenience.
2. Atom's package manager is built in. In ST, you have to activate the console and paste in a Python command to install the PM.
3. The prominent "Download" button on sublimetext.com, until recently, defaulted to 2. And the download page for 3 lacks a call to action, at least in comparison to the page text that warns the reader that 3 is still in beta. I was always amazed at how many students installed ST2 contrary to my instructions until I visited the ST homepage for myself (which I never do unless I have to reinstall ST from scratch).
4. Atom installs the 'atom' CLI command by default. ST requires manual shell configuration to get 'subl'
5. Atom is free. ST has a free trial but then nags the user upon every nth save. I know, minor inconvenience, but as a happy purchaser of ST, I found that I vastly underestimated how much that nag dialog broke the flow, especially if students followed my advice to hit Cmd-S casually.
I agree with the OP that ST is substantially more performant, which is why ST is still my editor of choice. But for my students, performance is less of a concern. For most novices, their concept of a "text editor" is Microsoft Word...so a 3 second load up time won't bother them.
That Atom chokes on non trivial data files, e.g. a CSV of 100K rows, has been the strongest reason to stick to ST. But I now see that as an asset when it comes to teaching beginners. I make them learn the command line, and no better way to drive home the importance of tools like head, tail, sed, and grep than to have students experience firsthand Atom's grinding death when trying to render even simple text.
You should give VS Code a try. I used it with novice programmers and find it has the easiest to use (and explain) step debugger I have ever seen. Being able to stop a program and inspect variable state and the call stack proved very helpful when learning concepts such as loops, recursion and variable scope.
I had students using it on Linux, Mac and Windows with no problems. Only had to assist with setting up the debugger to make it use the right interpreter (Ruby, Python, PHP).
Normally I defend Sublime Text, but I think this is the ideal use case for Atom/VSCode. It has great defaults and is easy to get started with without plugins.
Sublime is still easier than VIM/Emacs for beginners but it does require some effort to get up to full awesomeness.
Have been using Sublime Text 2 for years now and then last year tried out Sublime Text 3 (various builds). Sublime Text 3 (still in Beta), for me, has issues when it comes to loading text files which are around 20MB in size (or more). It just freezes or takes a very long time to load (on my Linux machine). Haven't seen the same issue with Sublime Text 2, which has been a very good editor. I understand that Sublime Text 3 is in beta, but it's the only version that's made available via the official repos on LinuxMint installations. So I had to manually switch to Sublime Text 2 to have a stable working editor.
That's truly interesting, I load HUGE (I mean stupidly huge, like multi-hundred MB) files into ST3 and have done for years without issue, even on a relatively low spec machine like my base MacBook (non-pro, gutless as anything) it's quite acceptable.
Given that I was able to consistently see this issue when I was using Sublime Text 3, I'll see if I can come up with something more concrete to show/report this issue, over some weekend.
Just had a quick look at one of the files which I remember was giving me trouble. The file extension is .txt. I will boot up the machine on which I have ST3 installed and give it a try pretty soon.
I think I have narrowed this issue down now. Earlier I had assumed this affects all files of certain size, since when I had run into this I was involved in a project where I had to look at certain textual content (dumped out of DB as JSON). That content was generated by one of the in-house dump tools. I had a closer look at one of the files just now and now have a simple python script which consistently reproduces this issue with ST3. Here's the python script which generates a file which can then be opened in ST3 and timed.
content = 'a'
with open('content.txt', 'w') as f:
for x in range(1, 18888789):
f.write(content)
It took me 39 seconds (consistently) to open it. The generated file size is less than 20MB.
The problem appears to be that ST3 slows down while loading this file which just has 1 huge line. If I tweak that script to change the content from 'a' to 'a\n' to include a new line within the content, the generated file loads relatively quickly and in reasonable time (around 6 seconds for the 37MB odd file).
I admit, this now I think can be considered a corner case but when I ran into this pretty frequently, I just assumed this happens with all files with such sizes. As for why I believed ST2 doesn't have this issue - I'm not sure anymore, because when I try these files now with ST2 it too behaves similarly.
I no longer work on that project which generated these files so had it no been for this thread, I would never have bothered to dig deeper into this and would have just stuck with ST2 :)
Yes and I don't disbelieve you either, I'm just wondering if it's perhaps something like interaction with a specific file system or disk scheduler that might be causing a block level locking issue, it's a bit of a stab in the dark without knowing anything about your setup but I build quite a few storage systems and have experienced some fun interactions with IO blocking.
Awesome comparison! I believe both Atom & Visual Studio Code will only get faster over time.
I've been using Atom for over a year and it has made great strides over the last few months. I don't have any problems opening large repos or files now, as much as I did a few months ago.
I use VScode for personal projects & it's fast and awesome as well.
I find Atoms memory usage (and leaks) combined with odd periods of strange input latency so aggravating that I end up going back to sublime text 3 every time I try it. It just 'feels' so javascripty - like a web app, not like a snappy desktop app which is the reason I don't use my web browser for development. Coupled with the poor performance handling files over a few MB in size I can't see myself using atom in the foreseeable future unless it became a native / compiled app which isn't going to happen.
It's exactly what you would expect. But are VS Code and Atom fast enough to be useable? I didn't think so before a year or more back), but I think so now.
I find that the electron/node based apps tend to work acceptably when you're running on SSD, otherwise the startup is much slower. But I've been very happy with VS Code for well over a year now... much happier than my experience with Brackets and Atom at the time. And imho it's gotten a lot better, though could stand for some more flushed out git support in the box, there are a couple extensions that improve things.
These numbers "feel" very accurate - I ended up adopting a peculiar behaviour using st3 & atom in parallel, using st as a default editor for anything that likely is big or will probably be accessed outside of "project scope" like csv, conf, sql, and sticking to atom as dev environment.
Need to adapt here and there but couldnt bother to decide for good
I agree with pretty much everything people say about Atom. But I tolerate those flaws because of how easy it is to get my environment configured for a bunch of languages. Finding working, decent plugins for sublime felt frustrating at times, and never quite obvious.
However, where the big difference comes is in searching across an entire project. Want to find all references to `someVar` it's super snappy in Sublime and 10x slower in VSCode and Atom (of course, it depends on the size of your project as well, but my projects are not that large).
Having said that, I'm still using VSCode, my biggest hope is improved search performance. The Git integration is fantastic.