3 ms·

Vs code is an antiexample here. The whole point for then from the start was to not to repeat the Atom fiasco. The entirety of the project was running around o

Vs code is an antiexample here. The whole point for then from the start was to not to repeat the Atom fiasco. The entirety of the project was running around of making Webkit not suck. They spent ennormous effort on that.

e_proxus 6y ago
That being said, I immediately notice when switching from Sublime to VS Code. It’s something in the key presses... I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.
- disgruntledphd2 6y ago
  I noticed this a bunch when I moved from emacs to Jupyter notebook. Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order. Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block. I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).
  - pdimitar 6y ago
    I am using Spacemacs and have spent days trying to make it work faster (I am on macOS). Took a while and some effort but with a few strange tweaks I managed to make it more responsive. Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still. Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.
- deleted 6y ago
  [deleted]
schmorptron 6y ago
Wait, what is the atom fiasco?
- foldr 6y ago
  Atom (https://atom.io/ https://atom.io/) is another Electron-based text editor release by GitHub (before it was acquired by Microsoft). I think it predated VSCode. It certainly had more mindshare in the early days. But whereas VSCode has always been quite snappy, Atom acquired a reputation for poor performance.
  - zwirbl 6y ago
    Pretty much like that, I tried Atom once (when I found platform.io and wanted to have a look) and it was just wild how slow it felt. On the upside, it made using those crappy Eclipse forks MCU manufacturers release (like CCC, Dave, etc.) fell a lot less painful
  - Rapzid 6y ago
    > another Electron-based text editor Well electron used to be called "atom shell" :)
    - foldr 6y ago
      Ah good point. I didn't know that.
  - WorldMaker 6y ago
    > I think it predated VSCode Yes, and no. They have a really interesting tale of convergent evolution. Atom was the original Electron app (as pointed out Electron was even originally named "atom-shell"), so it predates VSCode as an Electron app. But the extremely performant "Monaco code editor" that VSCode was built on top of (that forms the heart of VSCode) was started at Microsoft years before to be a code editor in parts of the Azure Portal, and also it was the code editor in IE/Edge dev tools from as far back as IE 9 or 10 I think it was (up until the Chromium Edge). It wasn't packaged into an Electron app until after Atom, but it has an interesting heritage that predates Atom and was built for some of the same reasons that GitHub wanted to build Atom. (ETA: Monaco's experience especially in IE Dev Tools and the wild west of minified JS dumps it had to work with from day one in that environment is where a lot of its performance came from that led VSCode to jumping Atom on performance out of the gate.)

e_proxus 6y ago

That being said, I immediately notice when switching from Sublime to VS Code. It’s something in the key presses... I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.

disgruntledphd2 6y ago
I noticed this a bunch when I moved from emacs to Jupyter notebook. Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order. Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block. I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).
- pdimitar 6y ago
  I am using Spacemacs and have spent days trying to make it work faster (I am on macOS). Took a while and some effort but with a few strange tweaks I managed to make it more responsive. Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still. Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.
deleted 6y ago
[deleted]

schmorptron 6y ago

Wait, what is the atom fiasco?

foldr 6y ago
Atom (https://atom.io/ https://atom.io/) is another Electron-based text editor release by GitHub (before it was acquired by Microsoft). I think it predated VSCode. It certainly had more mindshare in the early days. But whereas VSCode has always been quite snappy, Atom acquired a reputation for poor performance.
- zwirbl 6y ago
  Pretty much like that, I tried Atom once (when I found platform.io and wanted to have a look) and it was just wild how slow it felt. On the upside, it made using those crappy Eclipse forks MCU manufacturers release (like CCC, Dave, etc.) fell a lot less painful
- Rapzid 6y ago
  > another Electron-based text editor Well electron used to be called "atom shell" :)
  - foldr 6y ago
    Ah good point. I didn't know that.
- WorldMaker 6y ago
  > I think it predated VSCode Yes, and no. They have a really interesting tale of convergent evolution. Atom was the original Electron app (as pointed out Electron was even originally named "atom-shell"), so it predates VSCode as an Electron app. But the extremely performant "Monaco code editor" that VSCode was built on top of (that forms the heart of VSCode) was started at Microsoft years before to be a code editor in parts of the Azure Portal, and also it was the code editor in IE/Edge dev tools from as far back as IE 9 or 10 I think it was (up until the Chromium Edge). It wasn't packaged into an Electron app until after Atom, but it has an interesting heritage that predates Atom and was built for some of the same reasons that GitHub wanted to build Atom. (ETA: Monaco's experience especially in IE Dev Tools and the wild west of minified JS dumps it had to work with from day one in that environment is where a lot of its performance came from that led VSCode to jumping Atom on performance out of the gate.)