4 ms·

So that's the case for JetBrains' products then? VSCode is Microsoft's product, and they are doing solid job with it now, but who knows what they will do with

So that's the case for JetBrains' products then? VSCode is Microsoft's product, and they are doing solid job with it now, but who knows what they will do with it in 5 years' time. I won't be surprised if they try to integrated it with Azure more closely and do some things which are not relevant to me. Plus it's Electron app which I won't use. And it's not like open source solution can't fail and be abandoned. Only two editors that I think will last forever (at least it seems so now) are emacs and vim. Everything else has similar chances of surviving test of time.

auvi 9y ago
What's wrong with an Electron app? I am curious.
- 8draco8 9y ago
  They are slow, unoptimised , massive memory and cpu hogs. Here is the best example https://www.theregister.co.uk/2017/03/23/cursor_devours_cpu_cycles_ms_code_editor/ https://www.theregister.co.uk/2017/03/23/cursor_devours_cpu_...
- Philipp__ 9y ago
  You can check out some of my previous comments on my profile. I think we have discussed & covered it extensively here on HN. :)
- Can_Not 9y ago
  My opinion is that an advanced text editor or IDE should be written in a low level language to be light weight and fast. Everytime I try atom it performs so bad and slow that I need to switch back to sublime. I even have a probably unfair paranoia bias against editors written in Java because it might be slower than one written in C. Electron has a lot of great uses, but an IDE is antithetical to it's performance capabilities. BTW, I'm in the market for IDE recommendations.
  - josteink 9y ago
    Atom is known to be slow. That doesn't make all electron-based applications slow.
    - Can_Not 9y ago
      Actually 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 9y ago
        I 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 9y ago
      Atom 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 9y ago
        Good 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 9y ago
        From 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.

auvi 9y ago

What's wrong with an Electron app? I am curious.

8draco8 9y ago
They are slow, unoptimised , massive memory and cpu hogs. Here is the best example https://www.theregister.co.uk/2017/03/23/cursor_devours_cpu_cycles_ms_code_editor/ https://www.theregister.co.uk/2017/03/23/cursor_devours_cpu_...
Philipp__ 9y ago
You can check out some of my previous comments on my profile. I think we have discussed & covered it extensively here on HN. :)
Can_Not 9y ago
My opinion is that an advanced text editor or IDE should be written in a low level language to be light weight and fast. Everytime I try atom it performs so bad and slow that I need to switch back to sublime. I even have a probably unfair paranoia bias against editors written in Java because it might be slower than one written in C. Electron has a lot of great uses, but an IDE is antithetical to it's performance capabilities. BTW, I'm in the market for IDE recommendations.
- josteink 9y ago
  Atom is known to be slow. That doesn't make all electron-based applications slow.
  - Can_Not 9y ago
    Actually 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 9y ago
      I 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 9y ago
    Atom 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 9y ago
      Good 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 9y ago
        From 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.