3 ms·
Atom is known to be slow. That doesn't make all electron-based applications slow.
by josteink 10y ago
Atom is known to be slow.
That doesn't make all electron-based applications slow.
- Can_Not 10y agoActually do you have any prime examples of fast electron apps? I'm interested in finding a DOM-free electron alternative, but if I had a good case study for a legitimately fast electron app, that would be valuable insight for me.
- josteink 10y agoI think VSCode is more than responsive enough. I've had zero performance issues with it on any hardware I own. The Spotify desktop app also feels millisecond-fast to me, but that might be Chromium Embedded Framework and not "full" Electron? I'm not sure.
- ctrl-j 10y agoAtom is slower than VS Code, sure. However, if you end up in a file of any significant size in VS Code, you're pretty much toast. https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
- josteink 10y agoGood link. Really appreciated. I would be interested in seeing how that 3GB looked like though. For instance Emacs has no issues with huge files (logs with many lines), but can completely choke when the lines are really long (like a minified JS-file without lineshifts). I guess similar constraints may exist in other editors too. Without knowing how those 3GBs looks, it's hard to make a decent judgement of what the "load" test actually tests.
- ctrl-j 10y agoFrom the link: > huge 3 GB file (3M 1K lines) So, somewhat long lines, but not unreasonably huge. For me, working on a nasty legacy codebase with 10-15k LOC classes - VS Code is slow enough with syntax highlighting that I pretty much need to use something else.
- deleted 10y ago[deleted]