Live data from Hacker News

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

github.com

191–200 of 801 posts

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

#191
post #37

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…

Why? With JavaFX where you can customize it using CSS it looks nice, and you don't need to use a scripting language to do it.

Why use JavaFX when you can change the CSS in a web app which is indistinguishable?

Here's a easy way to get a job done but people refuse to do it because of philosophical/ideological indoctrination. ex. the world is made of objects therefore our languages and how we build software should now mirror it.

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

#192
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.

[deleted]

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

#193

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…

> Wouldn't it be better to make native application

Actually there are such editors. I use vim instead of vscode or atom. And I think my installation of vim is slower then vscode because of some plugin that I've not found yet.

Applications like vscode very useful because they help to find performance and other bugs in browsers. Same way as browser improved when gmail and sites like this appeared.

I would support appearance of IDEs, large games, VR, image and video editors in browsers as they help improve web platform.

If you don't like it, just use other option. It could be faster, but may be not. Not sure that vscode is slower then visual studio for most tasks.

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

#194
post #124

Earlier quoted context omitted.

100% of vim users will tell you that their vim setups also have code completion, debugging, linting, etc...

Sure, but I won't pretend that adding those features doesn't add some significant resource usage and some occasional slowdown.

>doesn't add some significant resource usage

If by "significant" you mean less resources than opening a blank tab in Atom.

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

#195
post #108

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…

As someone who is literally building a IDE in Electron, the biggest reason is JavaScript itself. If you look to the stackoverflow yearly overview, you can observe that JavaScript is currently the most used language. Also do not forget about all the integrations you could do with for example devtools. An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Thin…

The SO survey (while super interesting!) conflates "most used" with "most asked about on Stack Overflow"; I'm skeptical of anyone who claims to know which programming language is the most popular. The TIOBE index, which has its own problems, has Javascript coming in 8th, with the top 4 being Java, C, C++ and C#; my experiences and my confirmation bias suggest that's more accurate.

https://www.tiobe.com/tiobe-index/

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

#196
post #108

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…

As someone who is literally building a IDE in Electron, the biggest reason is JavaScript itself. If you look to the stackoverflow yearly overview, you can observe that JavaScript is currently the most used language. Also do not forget about all the integrations you could do with for example devtools. An additional feature is that you can run the IDE in the web browser, so that you can have an online code editor. Thin…

JavaScript is literally the reason I would avoid a platform. It's only the de facto language for the web because you can't directly run any other language across different browsers. With web apps being so popular, having a low barrier to entry, and being "quicker" to provide half-assed cross platform apps, it's no wonder JavaScript is technically so popular. Hopefully, web assembly or something similar can change that. But then again, web browsers weren't meant to host proper applications.

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

#197

Earlier quoted context omitted.

VS Code IS a viable option. I use it daily basis and works great.

I tried it too... Wasn't satisfied with performances. I used to install Atom every 2,3 months, when VSCode got released I then tried installing it every few months in place of Atom. I still do, but I always uninstall after few hours of using it. It has many good ideas implemented well, but still not worth switching and sacrificing all of the performance for nice git and debugging interface.

[deleted]

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

#198

Earlier quoted context omitted.

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art... Yes, I know, he's still around...

[deleted]

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

#199

Earlier quoted context omitted.

Except that the abstraction layer for the user has remained the same. The extra abstraction layers you're talking about are invisible to the user... while our GUIs are slower, and our processors faster. It feels like, after 30 years, we should be able to have our GUI cake and eat it, too.

Where are the Michael Abrash's of today teaching people how to write tight, fast code? Seems a lost art... Yes, I know, he's still around...

Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.

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

#200

Earlier quoted context omitted.

Emacs takes 8-15 seconds to open on my new i7. That matters when I just want to do quick edits. Vscode takes 3.

For me Emacs opens up in about 2 seconds and it's ready to go and print text input in scratch buffer. I am on 2015 MacBook Pro 13" with i5.

That's been my experience as well, although that's still too slow for my tastes as a vim user.

But I definitely don't ever recall it being 8 seconds, that feels like either an exaggeration or someone working on a potato.

Post reply on HN