Have you used it? It's not just start up that's slow, it every time you open a new window. So if you go to type a git commit message, 5 second lag until it shows up. Double click a text file (after atom is already open), 5 seconds.
If it was just the initial startup, I'd be compelled to agree with you.
That's what I came here to mention. I've been using Atom as my primary editor for a month or so now, and I've never noticed the slowness.
After I read this post, I did a test:
Launching a file when the editor isn't in memory:
> atom filename.js
This takes around 4 seconds on my Mac Air.
Launching a file when the editor is in memory:
> atom filename2.js
This second one takes < 1 second.
I could see the OP having a point if the _second_ version was taking a while: this would be the equivalent of opening a new browser tab in 4 seconds. But opening an entire browser in < 1 second? I don't really expect that on my mac.
Your metaphor isn't really accurate. Atom is not a browser, is a glorified notepad. The fact that internally it uses VP8 or anything else doesn't matter (neither should) to the user.
The user expect it to open in the blink of an eye, no matter what, and it can be done for this kind of program as alternatives in the same league show. If it isn't possible at all with the underlying technology, that was a bad technological choice. However I wouldn't worry so soon, there is a lot of space to optimize, the project is young.
> Your metaphor isn't really accurate. Atom is not a browser, is a glorified notepad.
Ok, let's try another one:
Atom is an IDE like XCode is an IDE. I don't expect XCode to start up "in the blink of an eye" although I do expect opening a _file_ to take a blink of an eye.
That is the behavior I reported: Atom itself doesn't start up quickly, but loading a new file/window is < 1 second, which I what I'd expect from any editor.
So again, I don't see the issue the OP is referring to. Not to say it isn't there on other machines/configurations, but it isn't an issue for me.
Also it's not just the startup time, atom in general is slow but most of the work being done is on the speed of the editor and not startup time. While I do agree that the actual functionality is more important than startup, it seems like they don't really care about the startup time at all.
> I usually open Atom using the Shell command "atom [filename]"
So it might be that he opens up the editor many times a day.
Anyway, I don't think asking for a snappy editor start up time is much to ask for, in this day and age. And if some editor doesn't offer that, there are enough other editors that will offer fast start up time as well as features that are associated with power editors.
I sometimes can start up my editor (Emacs) many times a day. Maybe I have an Emacs up for some editing on one workspace, but I need to open it in another workspace, because it fits better in that workspace. Not to mention that some programs uses my $EDITOR variable to launch Emacs when I need to edit something. That's another program start up, and I'll be damned if I have to wait 2 minutes to edit for my editor to start up just so that I can edit a git commit message.
In my case, I guess I might be able to set up an Emacs daemon, if start up time and stuff like that is ever an issue (what isn't possible in Emacs, with enough effort?). But if any editor offers something like that as a solution so slow start up times, it better be straightforward to set up.
Another emacs user here. I don't know which version of emacs you use and on which OS but this is what I can do with emacs 24 on Ubuntu (X11, Gtk).
Open another window of the same editor (a frame): File, New Frame or C-x 5 2 and then move it to another workspace. This seems quicker and more efficient than opening the whole editor again but maybe this isn't faster in your setup.
Emacs starts a server if you include (server-start) in the .emacs file. Then you can open files in that emacs like this $ emacsclient -n file
I have a alias ec="emacslient -n" in my .bashrc
The -n is to make the command terminate without waiting for the buffer to be closed in emacs. Maybe you want to do without the -n if you use emacs inside other programs (e.g. for editing the log messages in git) but I usually use vi for quick edits.
Unfortunately running two emacs with one server each doesn't ends well so the emacs server is almost bound to using new frames in multiple workspaces.
How often do you start up an editor per day? If the editor offers tools that save you more time than that, you won.
It's like refusing to use a chainsaw instead of a handsaw because it's a 2 minute walk to get it.
EDIT: I talked before my turn. I thought this was just about initial startup, but apparently it's about each editor window. Thanks schrodinger.