5 ms·

It's impressive how Sublime perform well despite having so many advanced features. Too bad Atom.io doesn't manage to get its performance issues in order.

SwellJoe 10y ago
I was actually pleasantly surprised by Atom's performance. It used to be remarkably slower than VS Code...like dramatically so. Now, it seems to be breathing down VS Code's neck, in terms of performance. (Both are the chubby kids huffing and puffing along at the back of the pack while being lapped by the other contenders, of course, but they're trying.)
- bastawhiz 10y ago
  That's interesting to hear, because I've tried Atom three times now and the biggest deal-breaker every single time has been performance. Around the first release, there was noticeable lag as I typed. About a year later, tabbing through find results was just absurdly slow. More recently, opening a multi-megabyte JSON file with syntax highlighting was an inexcusably painful experience. I really, really want to use and support Atom, but the performance compared to Sublime has just been atrocious (in my experience).
  - SwellJoe 10y ago
    Oh, it's still slow. Pathologically so in some cases. But, so is VS Code. But, Atom's speed has become manageable in recent versions. I rarely find myself unable to work with a big file in Atom. For code, I rarely see files bigger than a few thousand lines (and never produce files that large myself), and Atom handles them OK (not great, but acceptable, given the other benefits of the tool). VS Code is still better, and of course, vim smokes them both. But, there are trade offs, and Atom has a lot of cool features. I wouldn't use it for really large files, however. It really shows its ass in those cases (as the XML file test here shows).
- hartator 10y ago
  My main issue with Atom.io performance is typing lag, it's kind of my main thing for an editor unfortunately. I love Atom.io otherwise.
  - SwellJoe 10y ago
    I don't notice typing lag, anymore. Just now I opened it up and tried to get ahead of it by slamming flat hands on keyboard, but it kept up fine. My current performance complaints are: startup time, big files (especially big files with highlighting), selecting large blocks of text (spanning more than a screen), and probably some other things I can't think of right now. Some of the plugins are buggy and prone to screwing up more than just the thing they're supposed to changing, but that's not performance-related. Just immature code that's expected of new-ish projects.
elsurudo 10y ago
Since it's based on node-webkit, that will be difficult. I find it hard to understand why they thought building text editors in a web engine was a good idea. Cross-platform support seems to trump all other considerations.
- hartator 10y ago
  Sublime has also cross-platform. However, Atom.io is very easy to modify. I was able to do 1 or 2 PRs on the code base without any big issues.
- bastawhiz 10y ago
  It's actually built on Electron, which is their own from-scratch version of NW. JavaScript is very fast, though, and there's really not a way of rendering arbitrary content as well as a browser. The ability to take contributions from the community is much better, as well. Far more people can competently write JavaScript (or with Atom, coffeescript) than C++.
  - skykooler 10y ago
    But, it's not abitrary content. It's text. And we've had good text rendering engines for decades.
    - majewsky 10y ago
      And then you want a popup with a progress bar. Where's your text rendering engine now?
      - deleted 10y ago
        [deleted]
      - flukus 10y ago
        You launch a popup with whatever GUI toolkit you're using, just like every other application. We had popups with progress bars before computers had GUI's at all.
zeveb 10y ago
> It's impressive how Sublime perform well despite having so many advanced features. Does it have any features which emacs — which outperforms it — lacks?
- hartator 10y ago
  Multi cursors that allow notably powerful column editing will be the main one. For example, it might be the very best - and fun - interactive way to transform a weird CSV in a regular JS array or anything else.
  - jorams 10y ago
    There's an emacs package for that[1]. It's not as well integrated and there are some rough edges, but it's incredibly useful. I use it a lot. Often for quick local refactoring, but also for larger things like you mentioned. [1]: https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el
  - zeveb 10y ago
    There's https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el And also keyboard macros, which are more often used for the use case you mention.
- JorgeGT 10y ago
  As shown in the test, editing very large files.
  - zeveb 10y ago
    Fair point — although I do edit ½-gigabyte files pretty commonly.
  - josteink 10y ago
    In general, editing large files in Emacs is super-fast. What's NOT super-fast is editing files with super-long lines (it doesn't even have to be a "big" file). For whatever technical reason, that can grind Emacs to a halt. I'd love to see that bug fixed myself.
lawnchair_larry 10y ago
That's because writing a text editor in javascript and using an entire web browser instance to host it isn't a sane thing to do. I hope this trend dies soon. The inmates are running the asylum.
therealdrag0 10y ago
If only Sublime had debugging/breakpoint functionality :( That's all I use VC Code for.

SwellJoe 10y ago

I was actually pleasantly surprised by Atom's performance. It used to be remarkably slower than VS Code...like dramatically so. Now, it seems to be breathing down VS Code's neck, in terms of performance. (Both are the chubby kids huffing and puffing along at the back of the pack while being lapped by the other contenders, of course, but they're trying.)

bastawhiz 10y ago
That's interesting to hear, because I've tried Atom three times now and the biggest deal-breaker every single time has been performance. Around the first release, there was noticeable lag as I typed. About a year later, tabbing through find results was just absurdly slow. More recently, opening a multi-megabyte JSON file with syntax highlighting was an inexcusably painful experience. I really, really want to use and support Atom, but the performance compared to Sublime has just been atrocious (in my experience).
- SwellJoe 10y ago
  Oh, it's still slow. Pathologically so in some cases. But, so is VS Code. But, Atom's speed has become manageable in recent versions. I rarely find myself unable to work with a big file in Atom. For code, I rarely see files bigger than a few thousand lines (and never produce files that large myself), and Atom handles them OK (not great, but acceptable, given the other benefits of the tool). VS Code is still better, and of course, vim smokes them both. But, there are trade offs, and Atom has a lot of cool features. I wouldn't use it for really large files, however. It really shows its ass in those cases (as the XML file test here shows).
hartator 10y ago
My main issue with Atom.io performance is typing lag, it's kind of my main thing for an editor unfortunately. I love Atom.io otherwise.
- SwellJoe 10y ago
  I don't notice typing lag, anymore. Just now I opened it up and tried to get ahead of it by slamming flat hands on keyboard, but it kept up fine. My current performance complaints are: startup time, big files (especially big files with highlighting), selecting large blocks of text (spanning more than a screen), and probably some other things I can't think of right now. Some of the plugins are buggy and prone to screwing up more than just the thing they're supposed to changing, but that's not performance-related. Just immature code that's expected of new-ish projects.

elsurudo 10y ago

Since it's based on node-webkit, that will be difficult. I find it hard to understand why they thought building text editors in a web engine was a good idea. Cross-platform support seems to trump all other considerations.

hartator 10y ago
Sublime has also cross-platform. However, Atom.io is very easy to modify. I was able to do 1 or 2 PRs on the code base without any big issues.
bastawhiz 10y ago
It's actually built on Electron, which is their own from-scratch version of NW. JavaScript is very fast, though, and there's really not a way of rendering arbitrary content as well as a browser. The ability to take contributions from the community is much better, as well. Far more people can competently write JavaScript (or with Atom, coffeescript) than C++.
- skykooler 10y ago
  But, it's not abitrary content. It's text. And we've had good text rendering engines for decades.
  - majewsky 10y ago
    And then you want a popup with a progress bar. Where's your text rendering engine now?
    - deleted 10y ago
      [deleted]
    - flukus 10y ago
      You launch a popup with whatever GUI toolkit you're using, just like every other application. We had popups with progress bars before computers had GUI's at all.

zeveb 10y ago

> It's impressive how Sublime perform well despite having so many advanced features. Does it have any features which emacs — which outperforms it — lacks?

hartator 10y ago
Multi cursors that allow notably powerful column editing will be the main one. For example, it might be the very best - and fun - interactive way to transform a weird CSV in a regular JS array or anything else.
- jorams 10y ago
  There's an emacs package for that[1]. It's not as well integrated and there are some rough edges, but it's incredibly useful. I use it a lot. Often for quick local refactoring, but also for larger things like you mentioned. [1]: https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el
- zeveb 10y ago
  There's https://github.com/magnars/multiple-cursors.el https://github.com/magnars/multiple-cursors.el And also keyboard macros, which are more often used for the use case you mention.
JorgeGT 10y ago
As shown in the test, editing very large files.
- zeveb 10y ago
  Fair point — although I do edit ½-gigabyte files pretty commonly.
- josteink 10y ago
  In general, editing large files in Emacs is super-fast. What's NOT super-fast is editing files with super-long lines (it doesn't even have to be a "big" file). For whatever technical reason, that can grind Emacs to a halt. I'd love to see that bug fixed myself.

lawnchair_larry 10y ago

That's because writing a text editor in javascript and using an entire web browser instance to host it isn't a sane thing to do. I hope this trend dies soon. The inmates are running the asylum.

therealdrag0 10y ago

If only Sublime had debugging/breakpoint functionality :( That's all I use VC Code for.