14 ms·

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

by butz 9y ago

Bilters 9y ago
This might be an intersting article to read on the side; https://josephg.com/blog/electron-is-flash-for-the-desktop/ https://josephg.com/blog/electron-is-flash-for-the-desktop/
- striking 9y ago
  They're both Electron-based. One is just less optimized than the other. (edit: the parent comment has been edited. Mine no longer makes sense in context.)
  - deleted 9y ago
    [deleted]
- moosingin3space 9y ago
  We really don't need yet another anti-Electron circlejerk here, especially when VS Code is also written with Electron.
glibgil 9y ago
The developers of VS Code wanted it to take up less space? I'm sure someone could reduce Atom to the same footprint
- ComputerGuru 9y ago
  I don't think anyone is questioning that; I believe the OP's question was more along the lines of "what wasteful resource management strategies on behalf of Atom's developers lead to the product consuming so much space and running so slow?"
  - glibgil 9y ago
    You misunderstood my answer. The only way you get to "I want this app to be no larger than 80Mb" is to make that goal and get to work. You cannot, for example, make your operating system boot faster from 30 seconds down to 3 seconds just by making things faster everywhere you can. You have to set the budget at three seconds and approach every problem from there. Atom is large because it has no size budget
nkkollaw 9y ago
We always have to have somebody remind us how wonderful VSCode is compared to Atom every time there's a post about Atom. 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..?
- eridius 9y ago
  > Atom is built on Electron. 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.
  - nkkollaw 9y ago
    The harm is that every time there's an Atom post, most comments are about how much it sucks compared to VSCode, and always from the point of view of memory footprint, and size. I have both GB of memory, and GB of HD space. I don't get the point.
    - krisdol 9y ago
      I'm guessing they are trying to run atom on an embedded android smartwatch OS backported to 2006 hardware? I've never found the argument compelling. My memory is there to be used by apps I use.
mirekrusin 9y ago
Maybe it boils down to npms? Atom is using `dugite` npm for git, which takes more than 40MB alone, babel-* packages are probably above 50MB and silly things like emoji-images >11MB... but to be honest VSCode must be taking more space than that, maybe they're keeping npms outside of the main app because electron framework itself takes 167MB on the current Atom so technically you can't get below that.
FRex 9y ago
Even VSCode is sloppy and could go down easily IMO. 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.

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

by butz 9y ago

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

Bilters 9y ago

This might be an intersting article to read on the side; https://josephg.com/blog/electron-is-flash-for-the-desktop/ https://josephg.com/blog/electron-is-flash-for-the-desktop/

striking 9y ago
They're both Electron-based. One is just less optimized than the other. (edit: the parent comment has been edited. Mine no longer makes sense in context.)
- deleted 9y ago
  [deleted]
moosingin3space 9y ago
We really don't need yet another anti-Electron circlejerk here, especially when VS Code is also written with Electron.

glibgil 9y ago

The developers of VS Code wanted it to take up less space? I'm sure someone could reduce Atom to the same footprint

ComputerGuru 9y ago
I don't think anyone is questioning that; I believe the OP's question was more along the lines of "what wasteful resource management strategies on behalf of Atom's developers lead to the product consuming so much space and running so slow?"
- glibgil 9y ago
  You misunderstood my answer. The only way you get to "I want this app to be no larger than 80Mb" is to make that goal and get to work. You cannot, for example, make your operating system boot faster from 30 seconds down to 3 seconds just by making things faster everywhere you can. You have to set the budget at three seconds and approach every problem from there. Atom is large because it has no size budget

nkkollaw 9y ago

We always have to have somebody remind us how wonderful VSCode is compared to Atom every time there's a post about Atom. 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..?

eridius 9y ago
> Atom is built on Electron. 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.
- nkkollaw 9y ago
  The harm is that every time there's an Atom post, most comments are about how much it sucks compared to VSCode, and always from the point of view of memory footprint, and size. I have both GB of memory, and GB of HD space. I don't get the point.
  - krisdol 9y ago
    I'm guessing they are trying to run atom on an embedded android smartwatch OS backported to 2006 hardware? I've never found the argument compelling. My memory is there to be used by apps I use.

mirekrusin 9y ago

Maybe it boils down to npms? Atom is using `dugite` npm for git, which takes more than 40MB alone, babel-* packages are probably above 50MB and silly things like emoji-images >11MB... but to be honest VSCode must be taking more space than that, maybe they're keeping npms outside of the main app because electron framework itself takes 167MB on the current Atom so technically you can't get below that.

FRex 9y ago

Even VSCode is sloppy and could go down easily IMO. 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.