Sorry, I saw the API page but it didn’t have anything about performance in that post itself, so I didn’t dig further. Doing so now reveals this link about different startup time enhancements.
However, it appears those enhancements are all past tense, already in the release version. So we’re still looking at a slow text editor. In 2015 this is just deeply confusing to me. We have so much power under the hood, in the silicon, and any newly built text editor that is slow to open has fundamental design issues.
I just did some informal testing on startup times of Atom and its contemporaries. These are all warm/second launches: restart Windows, launch and close each app, then launch them again.
Atom 0.176.0: 5.1 sec
Microsoft Word 2013 64-bit: 4.0 sec
LibreOffice Writer 22.214.171.124: 3.9 sec
Cream VIM 0.43: 2.1 sec (and that’s with a flash of an error along the way)
Sublime Text 2.0.2: <= 1 sec
Notepad++ 6.7.4 Je suis Charlie Edition: <= 1 sec
VIM 7.3.107: <= 1 sec
Light Table 0.7.2: 2.4 sec
Note that the time for Atom is actually somewhat generous. It’s the only the application where I see a spinning donut for some time after it’s opened/rendered. So it’s not quite ready at 5 seconds, though I’m not sure of the details of what it’s doing. I didn’t count the extra 3 or so seconds of spinning donut after opening.
From an engineering standpoint, a text editor is very similar to a word processor (BTW, what a terrible term for writing software – it’s amazing that it stuck, that we all say “word processor” all the time like it’s a Cuisinart for words, and that we don’t call Excel a number processor.) Text editors have lots of advantages compared to writing software. For one, they’re much lighter weight, don’t have to embed all sorts of objects, images, sophisticated grammar and spell checking, highly customizable tables, charts, shapes and colors, rich formatting options, dynamic tables of content, layouts, etc. – all the things that make modern writing software similar to what they used to call desktop publishing software. And Word is so freaking heavy because it has to be backward compatible with several generations of fundamentally different file formats from before the modern .docx XML framework, it writes PDFs and does a million other things that perhaps only Word maestros even know about.
Still, Word opens faster than Atom. Relatedly, I enjoyed reading about LibreOffice’s latest release and all the things that went into it. Michael Meeks has a nice post about it. Like MS, they’re burdened with a pretty heavy application that supports lots of file formats and has all the rich features of modern writing software, spreadsheets, presenters, etc. (For dev geeks, Caolan McNamara has a cool post about how they used Coverity to get down to near-zero bugs, and Michael Stahl at Redhat has posted about getting away from cygwin for build time improvements.)
Their architecture is different so their specific moves and decisions aren’t directly portable to Atom, although some of the things they’re talking about might be relevant at a certain level of analysis.
I think node.js is essentially brilliant, has made life better. But I don’t understand why anyone would build a desktop application out of it if they didn’t have to, especially if it’s going to be slow. It doesn’t seem like a node app would have to be slow, but I can’t find any details about the Atom architecture beyond the brief blog post, and I’m no node expert. Maybe node desktop apps are necessarily slow. It’s going to be very shoehorny whatever you do. Why would anyone invite the DOM into their desktop application? The DOM is the worst. It makes no sense to voluntarily use it for real software. Yes, we can do all kinds of things with web apps, and yes they’re much richer and faster than they were in 2008. But nothing else logically follows from that truth – they’re fast…er than themselves historically, not fast by normal desktop software standards.
It would be great if we could get something going to redesign the Atom core. If creaky old Notepad++ – which doesn’t leverage modern APIs, instruction sets, or acceleration at all – can open in a second or less, then a clean-sheet modern text editor like Atom should open in a tenth of a second. This is a very doable thing given modern operating systems, modern CPUs, modern GPUs, etc. Computers are incredibly fast now – there’s no reason for software to be slow. How hard would it be to build a modern desktop application core that runs in a flash, but presents the same plugin API, or even extends it? It doesn’t seem hard. It’s a text editor. An extensible text editor. I’m in for fifty bucks easy to build a new core. 2,000 x $50 is $100,000. I don’t think it should take more than that, but I could be wrong. It might not take any money. I would think Github staff could swing it.
But I’m happy to pay. We need a next-gen, fast editor from somebody – it might as well be Atom. Maybe UltraEdit is already there, but they don’t seem to have a plugin architecture, which is a nonstarter. Atom appears to be architecturally unsustainable – it can’t deliver the responsiveness that a lot of us take for granted, and that we should take for granted in a clean sheet desktop text editor. Sublime has checked out. Notepad++ has no future in its current form and very little plugin energy at this point (and is Windows only.) Brackets seems as slow as Atom from similar bizarre decisions, and more narrowly focused on webdev. It would save a lot of new effort if Atom asserted itself with a new, serious core.