Live data from Hacker News

VS Code uses 13% CPU when idle due to blinking cursor rendering

github.com

111–120 of 801 posts

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#111
Yesterday I wrote a webpage with a bootstrap template. The webpage has a progress bar that is updated in realtime by a websocket. The webpage is extremely slow. I guess every bit of progress bar update it rerenders the entire dom tree.

I don't think react would do much better, but I will have to try.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#112
post #40

It 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…

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.

You both do realize that similar arguments could have been made back in the day when moving from, say, command-line DOS applications to Windows API applications - right?

Ultimately, computing has always been one of abstraction from the lower "layers". Taken far enough, one could spuriously argue that if you aren't soldering together the flip-flops that make up your logic and memory, you just aren't being efficient...

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#113

It 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.

> it's impossible to ignore the benefits of cross-platform development

Performance & bugs/quirks. I'd much rather have performance.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#114

It 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…

Because Microsoft and Apple have both dropped the ball on their native UI toolkits. Right now I'm doing web frontend with TS+VueJS+nice CSS toolkit. Yes there's plenty of complaining to do about the fragile convoluted toolchain and crappy performance. But I still gladly take it over WPF (promising, abandoned for some reason) or Cocoa (feels a decade out of date). No major OSS community, no Material Design/Bootstrap/etc. toolkits, slow develop/run loop, no good UI automation, crappy/no inspection capacity, etc.

I don't need x-plat UIs, I just need a good UI toolkit period, and that's why I'm looking real hard at Electron for future desktop work.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#115
The amount of bad hacking that has to happen for NodeJS to work as a platform has said all I could ever want to possibly know about the quality of NodeJS developers: so pathetically in love with their trainwreck of a language that they would rather pile kludge upon hack upon kludge than to learn the language and environment most appropriate and most computationally efficient for the tasks at hand. Javascript devs would rather just throw JS at it

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#116
post #35

Earlier quoted context omitted.

> Wouldn't it be better to make native application Better in what way? The market has voted with their downloads, they don't agree that the problems with Electron apps are as bad as you feel that they are.

Are you kidding me? Look at the raw performances and benchmarks of Vim/Sublime/Emacs, compare it to VSCode and Atom and you will see. If you don't believe the numbers then use both side by side, open 250MB file in all of them and look at the screen. And I still see native editors used more (for example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and…

Clearly a lot of people don't care if their text editor is using "a lot" of memory or "doesn't benchmark well" because all they're doing is writing code and running it occasionally.

There's plenty of competition in this area, so if electron-based text editors have enough downsides, people will use something native (as your comment indicates). If that wasn't the case, and we could only choose from electron text editors, then we would have a problem.

I think we should look at performance and resource usage as features on the same level as other features. Those things have to be balanced against whatever else the tool is bringing to the table.

I used Atom for a while. But as my projects got bigger, I got to the point where I was bothered by its slowness, crashes, and choking on large files (not even that large, honestly). I find sublime much better in these areas, so I switched. Looks like a healthy ecosystem to me!

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#117

Earlier quoted context omitted.

well if you've ever built a cross platform native desktop application, you will appreciate Electron. Java Swing. Never again. edit: Do people downvoting even know what it's like building cross platform desktop applications using Java Swing? It's fucking awful, and that's a fact. Even the end result UI design look & feel is butt ugly. Sure you can spice things up with JavaFX but why? Do you not realize how masochistic…

Swing was at least meant to do UI. Web stack is not ; webapps are essentially a pile of ugly hacks on top of a document rendering engine, and it really, really shows - especially when you have webapps pretending to be native (e.g. webview-based apps on mobile). Also, for Java there's JavaFX (a de-facto standard UI toolkit for Java), which is very nice to work with.

And yet that hacked together document rendering engine manages to be less painful to use than the the current show of UI toolkits.

I think we'll get there eventually but until a native toolkit presents an interface as easy to use as the web developers are going to take the path of least resistance.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#118

Earlier quoted context omitted.

I think you have answered it yourself partly. Creating a highly configurable, UI/UX predictable cross plattform editor is not an easy task. If you start from scratch on a native platform you have to code a ton of code (pretty sure more than VSCode has) just to get started. Editors on web platforms can be modified with CSS, JS (or TypeScript like on VSCode), HTML. Try to be that configurable on a native platform... yo…

Pray tell, sir, have you heard of the Qt library? There is a whole world outside Javascript :)

So you think hacking QT libraries like this (and not from the outside, I mean internally) and using C++ would make a good community editor? http://doc.qt.io/qt-5/qtwidgets-richtext-syntaxhighlighter-e...

When using QT for a highly modular editor be prepared to code QT components from the lowest level. It's not like you take a QT widget and modify it on a simple way. Trust me.

If you think it is easy to code editors look e.g. at the people who write letters and their custom editor tool: Microsoft Word. Now look at the many competitors this program had and how many behave super speedy on all plattforms.

Re: VS Code uses 13% CPU when idle due to blinking cursor rendering

#120
post #88
post #40

Earlier 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.

Google Docs takes a good 2-3 seconds to spin up a UI on my i7. I doubt much of that time is spent building the DOM tree for the UI. Google Docs does a lot more than a simple text editing widget - there's a networked file system, a multi-user collaboration engine, a realtime notification system, etc that all get initialised. Instantiating all that over a network in 2-3 seconds is really fast.

...a whole 2-3 seconds!

Sometimes I think that comments like these arise out of not having experienced text-only rendering at 300 baud...

I know that's a generalization, and most likely unfair - but damn, today's phones, to this old man, are pocket super-computers (for that matter from my vantage point, an Arduino is a wonder, and a RasPi is utterly amazing)!

Post reply on HN