There are many reasons. The elsephant in the room, being that it’s Javascript and includes a full blown browser with a JS VM.<p>When I write a C or C++ app, if I use libcurl and a library I’m using does as well, it links to the same shared libcurl library (mapped in RAM) as all other running processes do as well. With NPM, you can’t share libraries across process space and you’ll often even find the same packed being imported multiple times within the same app. In JS, it’s like statically linking all of your dependencies, but even less efficient. It can be argued that this is as good as it is bad.<p>When you build a code ecosystem atop JS, the underlying inefficiencies multiply as each layer is added. VS Code is more efficient, but even 192MB is still pathetically bloated.<p>Expect Atom to eventually approach and surpass 1GB of RAM, not less... at least in the short term.
At a high level, it's because Atom is buult from components, and each of those components is made up of hundreds of components, and each of those is made from hundreds of components, etc. Each component is general-purpose in some way, and includes code that isn't used by Atom. To be slightly more specific, when I pull apart components like this to figure out why they're so large (like a 100MB XML-parsing library), the vast majority of the bulk is usually huge tables of data, such as unicode mappings. Most likely, Atom contains multiple components which contain the same data tables, but because of the hierarchical nature of modern software development, no one can cut through the layers and DRY up (denormalize?) that data.
Atom is ALSO a text editor. It's really a web browser in "to go" mode so it brings all its dependencies and a whole lot more along with it. I'm sure there are multiple copies of some components brought along for ride. I've seen this with quite a few NPM based projects. eg three copies of the same module because of dependencies in other modules.<p>Bloated for a text editor.
It's javascript. I think this article does a fine job explaining it: <a href="https://medium.com/s/silicon-satire/i-peeked-into-my-node-modules-directory-and-you-wont-believe-what-happened-next-b89f63d21558" rel="nofollow">https://medium.com/s/silicon-satire/i-peeked-into-my-node-mo...</a>
I'm not in front of a Mac right now, nor do I use Atom on said Mac, but you can right-click on atom.app/Show Contents and get a directory layout of what's in there. It won't break out the binary and statically compiled libraries, but you can see if it's using large assets, or dragging along bunch of dynamic libs.
Ubuntu snap of Atom 206 is 178M squashfs, which uncompresses to 1.1GB.
I suppose that most of /Application/Atom is uncompressed data.<p>Snaps are similar to Mac packages, since they bundle most of the libraries together with them.
Just because something is named atom doesn't mean it's small.<p>It's a clever marketing.<p>Downvotes for pointing out the flaw in marketing vs reality.