401–410 of 459 posts
Earlier quoted context omitted.
Funny, as VS Code is based on Atom.
VS Code is not based on Atom - it's built on Electron, the app framework Atom is also built on, and uses some of the same Node packages Atom developed.
Earlier quoted context omitted.
VS Code is not based on Atom - it's built on Electron, the app framework Atom is also built on, and uses some of the same Node packages Atom developed.
Electron was extracted from Atom and was originally named Atom Shell. I don't see your point.
Earlier quoted context omitted.
I just tried it on a 14MB file to confirm, and Atom can open files larger than 2MB. (I also scrolled through the whole file just to make sure Atom wasn't cheating somehow, and it seemed to be working fine.)
I just tried it on a 35MB log file and it gave me an alert that said it was gonna be sluggish, then took about 20s to actually open the file I requested (I could navigate to other tabs in the meantime but there was no indication that anything was happening), and then once the file appeared, it took another 20s to become responsive. Searching for a string which appeared in the second line of the file took over 30s, pr…
Earlier quoted context omitted.
Electron was extracted from Atom and was originally named Atom Shell. I don't see your point.
Electron was also not extracted from Atom - it was always extracted as atom-shell. It was just rebranded as Electron. Atom ≠ atom-shell.
"Initially developed for GitHub's Atom editor"
So what are we talking about?
Earlier quoted context omitted.
Electron was also not extracted from Atom - it was always extracted as atom-shell. It was just rebranded as Electron. Atom ≠ atom-shell.
Maybe we aren't speaking the same language. Here's what it says on electron.atom.io: "Initially developed for GitHub's Atom editor" So what are we talking about?
I find it to be a bit depressing that software bloat has advanced to the point that we have text editors plagued with performance issues.
The killer feature of Atom to me is the ease with which it can be extended (via packages) and the openness to community contribution on core features. That's not a knock against any other editor (some of which share similar characteristics in this regard) – it's just what draws me to Atom. It's super easy to hack on and contribute to.
It's the Cycle of Bloat. 1. Develop tool. It's small and fast and minimal! Woo! 2. It's easy to modify because it's so small! Woo! 3. Look, there's a budding ecosystem of packages! Woo! (Let's not talk about the fact the packages exist precisely because the original product wasn't big enough.) 4. Oh dear, some of them conflict, a lot of them suck. Well, here's some winners, let's pull them into the core. Now the base…
Basic things like https://atom.io/packages/find-and-replace
Facebook's nuclide project replaces a bunch of core features like the tree-view and the quick file opener.
> let's pull them into the core
That doesn't actually happen. They may adopt a package or publish a more official version of a package, but all major functionality is in packages.
Earlier quoted context omitted.
Sorry be that guy who posts his specs and disagrees... :-) Running on a stock mid-2011 Air w/ 4GB Ram plus a Thunderbolt display. If it was slow, I would have switched or upgraded my machine sometime ago. Things that are slow to me are waiting for node-sass to compile on save, server-side code reloading, npm installing... and so on.
It highly depends on your usage pattern. I usually have one long-lived instance of an editor for the project/thing I'm focusing on, but I also frequently fire up "temporary" instances for one-off editing jobs, from the terminal. The difference between, let's say, "subl ." (launch Sublime Text in the current directory) and "atom ." is staggering: Sublime Text starts instantly with a boatload of plugins; Atom starts ne…
I have to say amazing job to the team. My reason: last time I looked/was regularly using Atom the generic memory size was around 100mB if I remember correctly. I just checked with 1.0 and the memory size has now dropped below Sublime Text 3.0 (~70mB) to ~60mB. (OS X.10)
Same project and files open in ST3, 30mb.
I may be reading it wrong though; task manager is reporting ~30mb for atom , but there's ~100mb of background processes for atom shown as well.