How does VSCode manage to take up less disk space than Atom, with similar feature set? Currently on Windows box:
VSCode 1.14.0 - 156MB
Atom 1.19.0 - 516MB
I'm wondering—if you prefer VSCode, why even comment a post about Atom? I doubt your care that much..?
Atom is built on Electron. That means that it includes a whole version of Chromium (OMG!), and it isn't even optimized, so its size is 5 times that of VSCode.
Is that really a problem? Are you trying to tell me that as a developer you don't have 400MB to spare on your hard disk for one of—if not the most—important tool to work your job, and the size is really a reason to pick one editor over another?
Atom is about 100 times slower than Sublime Text, and like you pointed out 5 times bigger than the insuperable VSCode.
Now, I use Atom as my main editor, because I find it simpler than others for certain things, and it saves be a lot of time because GitHub integration is done very well. Also, I like the name (can't say the same thing about VSCode).
Some people like Atom because they're more productive, and don't care about its size, super-crappy speed, and whatever else you think Atom is worse than VSCode at.
Can we put this thing to rest..?
So is VSCode.
> Can we put this thing to rest..?
Where's the harm in having an actual discussion about this? If you're comfortable with your choice of Atom, you can just ignore anyone comparing Atom to VSCode.
I don't get the point.
It seems more like discussion just for the sake of it, then because of actual, real-life problems.
My laptop isn't even amazingly powerful, and I constantly have 3GB to spare despite the fact that I run many random apps and almost never restart it.
As a developer, I don't see what the problem would be if my main tool occupied even 2GB of memory (and we're talking about 500MB-1GB in most cases).
I never heard any graphic designer complaining about Photoshop occupying 10GB of memory for a logo (which happened to me a few hours ago).
So is VSCode! Hence the constant comparisons.
So it's valid to ask what did the VSCode people do to come to the different result?
On a related note, I wonder about the speed difference now, after Atom has done a lot of optimizations.
I'm also not convinced the feature set is identical. Atom comes with a lot of language support, customization options, and extensibility out of the box.
And no, I don't think anyone is ready to stop pointing out that Atom is slow. Atom can implement a thousand killer features, but until they fix their performance problem nobody is going to switch back to it.
I tried many editors when I decided which one to use—including VSCode—and Atom was the one where I was the most productive by a long shot.
Speed isn't everything. Atom is quick enough for the code I work on, and in other, much faster editors like Sublime Text I would be less productive and therefore slower. For instance, editing settings/packages in Sublime Text in unnecessarily nightmarish. Changing settings and installing plugins in Atom is a breeze.
Who cares if the editor is a few milliseconds faster when you're many minutes slower..? Just because of its excellent GitHub integration Atom is worth 100 times more than Sublime Text to me (even if it wasn't free).
Me. I care. That little hang Atom does after saving a file gets annoying after a while.
I get annoyed about having to switch to GitHub, for instance.
It's fine to have opinions, I'm just annoyed by the fact that every time there's a post about Atom the conversation gets hijacked by "VSCode vs. Atom" comments.
That's why I'm bitching.
I shall go update Atom instead.
How so?
GitHub integration is done very well -- Not nearly as well as the Git integration in VSCode
Also, Atom has in the past been much slower than VSCode in nearly every aspect.
VSCode has a built-in debugger which takes it dangerously close to being called a full-fledged IDE rather than just a text editor with plugins cough Atom cough
The reason they keep getting compared is really simple: they both aim to achieve the same goals, and both use a very similar approach.
One editor I haven't seen mentioned in a LONG while, though, that can probably be considered the 'grandfather' of both of these is Brackets. If I remember right, it had a lot of performance issues, as well.
Is that a bad thing? I like debuggers.
VSCode ranges closer and closer to a full-fledged IDE, which is awesome.
It would be like if Honda made a better car utilizing a Mazda engine than Mazda itself.
(I hate iTunes, and have no idea if the Windows version was a better Windows programs than others, I just thought I'd leave this here)
OMG! is right, imagine trying to make sure the zoo of various Node and Chromium versions on your computer do not have any unlatched vulnerabilities.
And you know? I have 400 MB for one Electron app. I even have 8000 MB for 20 Electron apps. I just do not want to give them because you'll eventually tell me that your containerized Electron-on-Docker-on-Electron virtual machine requires 64GB of RAM to run.
Now, I'm not saying that you should not use Electron ever. But if using a TEXT EDITOR on a laptop with 2GB of RAM requires sacrificing a quarter of its resources, that text editor is not a good piece of software. And if you say I should buy an OP max-spec computer to write freaking HTML, you are creating an unnecessary barrier to CS.
They have a folder with js modules (I didn't look too deep into it, there might be native dlls there too) that's 75 megs, compressing (and i.e.: recompressing on any change, update, download, etc.) would help with disk space taken and loading times. Not even an SSD will beat a zip file kept in memory, SSD, resolving file paths, NTFS, they still have overhead and I'm sure it'll be more than just decompressing out of a zip in memory.
would beat keeping that zip in memory and accessing it to decompress any script when needed. 75M resources 17M resources.zip 6.7M resources.7z
Third party ones aren't even minified which would be free size savings!
It's basically free saving and super common in game dev to package files and not have them scattered like that.
(edit: the parent comment has been edited. Mine no longer makes sense in context.)