I simply cannot understand why Atom and VSCode are so popular. I get that they are extensible, but is that really worth the slowdown to you? If I need more features than a text editor, I use an actual IDE. Someone just posted some really embarassing benchmark numbers regarding this issue yesterday: https://github.com/jhallen/joes-sandbox/tree/master/editor-p... Note that Atom and VSCode are nearly 10x slower than all…
VS Code uses 13% CPU when idle due to blinking cursor rendering
61–70 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#62Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#63It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
> Yes.
WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD!
ohh.. a lot of plugins don't support linux and it doesn't build on BSD?
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#64Earlier quoted context omitted.
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
you can do all of this in Qt, too. Without the overhead of the inner platform effect.
The whole experience is important. For many, it's more important than the individual 'feature' of being light on resources.
I currently ignore the fact that VS Code is 'heavy' as text editors go, because it's so much lighter than e.g. Visual Studio, leaving me much more RAM free for some of the code I'm running to gobble up and use for its own ends.
I'd prefer lighter 'weight' - in terms of RAM and CPU usage - but I'm not tempted back to Sublime yet.
BTW I'm a vi person, so I'm using vi keybindings in VS, VS Code, Sublime - and anywhere else I can do so. I love Vim's speed, but I can't Get Stuff Done in it like I can in more modern editors. I mastered the keys, not the inbuilt windowing system, scripting language, etc.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#65Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#66Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#67Earlier quoted context omitted.
> easy to get started Yes. > cross platform support Yes. > Because you can write plugins in JS? Yes. --- As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
And that is OK for Notes or todo app, but text editor that is used by developers who tend to customize it with plugins and whatnot I think that is not viable option. But that's just my personal preference, maybe I am wrong...
There are a huge number of plugins for VS code. It's built to be plugin-centric - most functionality is a plugin.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#68It just doesn't go in my head that we are building text editors inside a web browser! I get it, there are many good use cases for Electron and it's easy to get started with cross platform support, but why is everybody going crazy about text editors in them? Because you can write plugins in JS? Wouldn't it be better to make native application, especially for code editors, where developers spend most of their time, whe…
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#69Earlier quoted context omitted.
Yep. I also can't wrap my head around the fact that we are now constructing buttons, drop-down boxes, tagged text boxes using dozens of nested layers instead of a native widget that writes directly to the screen. My 486 rendered UIs with nearly imperceptible lag. Google Docs takes a good 2-3 seconds to spin up a UI on my i7.
Would be better to compare it to transfer a state/screen over the wire/internet on 486 vs. doing the same nowadays ;)