4 ms·

Atom was unbelievably slow. How will the performance be improved? Visual Studio Code somehow managed to surpass the awful Electron performance just enough to ma

Atom was unbelievably slow. How will the performance be improved? Visual Studio Code somehow managed to surpass the awful Electron performance just enough to make it usable, and it's pretty unbelievable this project will come close to that.

qbasic_forever 4y ago
Why couldn't they take the optimizations from vs code and integrate them? VS code is open source, it's only their proprietary extensions like remote dev that aren't open. I remember Atom in its later releases had significantly improved performance to the point I never noticed problems.
- bobajeff 4y ago
  Looking at both projects vscode uses typescript heavily while this project mainly uses coffeescript. So that might be a hindrance. So I guess that might be part of it.
  - Daeraxa 4y ago
    We are actually looking to "decaffeinate" back to vanilla JavaScript. Unfortunately there is rather a lot of it still even after the Atom team's attempt to remove some of it.
swatcoder 4y ago
For those who want fast and lightweight without falling all the way back to emacs/vim, I’m really digging Lite-XL. Lua for customization, thin accelerated rendering layer in SDL2+freetype, zero nonsense. Binary packages are like 2MB. The code itself is clean and readable. The plugin collection is still young and won’t have everything you’d find in the Electron-family of editors, but that’s also a plus when it comes to it staying lightweight and streamlined like some might want in these tools.
- jorvi 4y ago
  No need to fall back to Vim, Sublime has stellar performance already.
  - sourcecodeplz 4y ago
    Have used: dreamweaver, vi, nano, notepad, ++, atom and sublime. Sublime so soo superior, it's not even fair. Haven't tried vscode but I understand it's a resource hog.
    - ricardobeat 4y ago
      I reluctantly switched from Sublime Text to VSCode about four years ago, but now it's simply unimaginable to go back. It's heavier, but fast enough to have four or five different workspaces open, in very large projects. The language support, intellisense, and plug-in ecosystem are miles ahead.
      - bobajeff 4y ago
        I'm curious as to why that is. I would think it's LSP support would close the gap on languages (and intellisense) at least.
    - ElectronBadger 4y ago
      Sublime Text (plus Sublime Merge) all the way. I've been on Emacs, vim, nvim and always get back to ST.
  - FunnyLookinHat 4y ago
    Sublime performance can't be beat, but I'm seeing the end of the road for active plugin development. It's getting harder and harder to adopt new tools without farting around with configs all day. At least, this was my experience trying to get Deno development to feel "right". It feels like vim and VSCode are the platforms that get plugin support nowadays, and the rest are a hack.
- khimaros 4y ago
rcme 4y ago
I would interested in understanding how VS Code overcame these limitations. Did the VS Code team ever do a write-up anywhere?
- yencabulator 4y ago
  You might enjoy https://news.ycombinator.com/item?id=11940043 https://news.ycombinator.com/item?id=11940043
  - rcme 4y ago
    That was very enjoyable. I think the tldr is that they use custom scrolling via translate3d, limit any computation on the file to just the visible lines, and they split the text into lines with regex to leverage native loops instead of trying to split the next manually via JS. Mono-spaced font probably makes this problem a lot easier as measuring text is pretty trivial.
thatxliner 4y ago
For starters, I’m pretty sure their focused on updating the project and dependencies.
admax88qqq 4y ago
Electron is rarely the cause of performance problems itself. It's more that JavaScript makes it really easy to write slow memory bloated code. But it's possible to write really fast and efficient apps in JS. There are a few fundamental limitations with web/js. No shared memory concurrency, no reasonable storage layer, no integer types. Those can make some things hard to make performant but most apps I see are not limited by this. Most apps are slow due to a few common mistakes. - React/Anglular diff based rendering cycle. - Garbage collection due to careless allocation of objects in tight loops. - Poor client side data models, resulting in blocking on the network for simple things. - Careless use of the bad storage abstractions (bleh indexeddb) which requires copying data for every operation leading to GC pressure and wasted CPU. - V8 is a moving target in what it chooses to optimize well and what it fails to optimize. tl;dr fast electron apps are possible but the platform makes it easy to write slow apps by default.

qbasic_forever 4y ago

Why couldn't they take the optimizations from vs code and integrate them? VS code is open source, it's only their proprietary extensions like remote dev that aren't open. I remember Atom in its later releases had significantly improved performance to the point I never noticed problems.

bobajeff 4y ago
Looking at both projects vscode uses typescript heavily while this project mainly uses coffeescript. So that might be a hindrance. So I guess that might be part of it.
- Daeraxa 4y ago
  We are actually looking to "decaffeinate" back to vanilla JavaScript. Unfortunately there is rather a lot of it still even after the Atom team's attempt to remove some of it.

swatcoder 4y ago

For those who want fast and lightweight without falling all the way back to emacs/vim, I’m really digging Lite-XL. Lua for customization, thin accelerated rendering layer in SDL2+freetype, zero nonsense. Binary packages are like 2MB. The code itself is clean and readable. The plugin collection is still young and won’t have everything you’d find in the Electron-family of editors, but that’s also a plus when it comes to it staying lightweight and streamlined like some might want in these tools.

jorvi 4y ago
No need to fall back to Vim, Sublime has stellar performance already.
- sourcecodeplz 4y ago
  Have used: dreamweaver, vi, nano, notepad, ++, atom and sublime. Sublime so soo superior, it's not even fair. Haven't tried vscode but I understand it's a resource hog.
  - ricardobeat 4y ago
    I reluctantly switched from Sublime Text to VSCode about four years ago, but now it's simply unimaginable to go back. It's heavier, but fast enough to have four or five different workspaces open, in very large projects. The language support, intellisense, and plug-in ecosystem are miles ahead.
    - bobajeff 4y ago
      I'm curious as to why that is. I would think it's LSP support would close the gap on languages (and intellisense) at least.
  - ElectronBadger 4y ago
    Sublime Text (plus Sublime Merge) all the way. I've been on Emacs, vim, nvim and always get back to ST.
- FunnyLookinHat 4y ago
  Sublime performance can't be beat, but I'm seeing the end of the road for active plugin development. It's getting harder and harder to adopt new tools without farting around with configs all day. At least, this was my experience trying to get Deno development to feel "right". It feels like vim and VSCode are the platforms that get plugin support nowadays, and the rest are a hack.
khimaros 4y ago

rcme 4y ago

I would interested in understanding how VS Code overcame these limitations. Did the VS Code team ever do a write-up anywhere?

yencabulator 4y ago
You might enjoy https://news.ycombinator.com/item?id=11940043 https://news.ycombinator.com/item?id=11940043
- rcme 4y ago
  That was very enjoyable. I think the tldr is that they use custom scrolling via translate3d, limit any computation on the file to just the visible lines, and they split the text into lines with regex to leverage native loops instead of trying to split the next manually via JS. Mono-spaced font probably makes this problem a lot easier as measuring text is pretty trivial.

thatxliner 4y ago

For starters, I’m pretty sure their focused on updating the project and dependencies.

admax88qqq 4y ago

Electron is rarely the cause of performance problems itself. It's more that JavaScript makes it really easy to write slow memory bloated code. But it's possible to write really fast and efficient apps in JS. There are a few fundamental limitations with web/js. No shared memory concurrency, no reasonable storage layer, no integer types. Those can make some things hard to make performant but most apps I see are not limited by this. Most apps are slow due to a few common mistakes. - React/Anglular diff based rendering cycle. - Garbage collection due to careless allocation of objects in tight loops. - Poor client side data models, resulting in blocking on the network for simple things. - Careless use of the bad storage abstractions (bleh indexeddb) which requires copying data for every operation leading to GC pressure and wasted CPU. - V8 is a moving target in what it chooses to optimize well and what it fails to optimize. tl;dr fast electron apps are possible but the platform makes it easy to write slow apps by default.