I noticed that somethimes when you press TAB at the beginning of a line, it can take about 1s for the TAB to appear on the screen.
VS Code uses 13% CPU when idle due to blinking cursor rendering
251–260 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#252Earlier quoted context omitted.
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/
I agree that tiobe is more established, especially as they look to companies being involved and to the job market. One of the reasons why I am interested in Javascript is that many people are learning it, even non-developers. Think about people without education.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#253Earlier quoted context omitted.
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...
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.
The abstraction layer has only remained the same visually, and only for a loose definition of "visually."
In the "good old days" the user interface was 640px x 480px (original VGA[1], skipping past the original MDA, CGA, and Hercules graphics cards[2] since they predated "modern" GUIs). Then it was expanded to 800x600, etc. The programs of those days were hard-coded to the graphics adapter resolution. If a program did not support the graphics adapter you had, you had to run your GUI in lower resolution compatibility mode. Sometimes it didn't work at all.
In lower resolution compatibility mode, the program's display got uglier and uglier as the screen resolution went up.
The abstraction layer today is adaptive and high DPI. Since the abstraction layer abstracts away the actual display resolution, programs (generally) can take advantage of the resolution that is available on a given display without change, allowing a program to run on small hardware displays (phone/tablet form factor) up to mega 4K++ displays, looking better and better as the screen resolution goes up.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#254It 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…
By making a text editor out of web technologies, you can reuse all the web ecosystem the web has, and enjoy also its customizability. For instance I wanted to be able to display PDFs directly in VSCode. I went to look for a plugin, and there was one. People simply used "pdf.js" to integrate PDF support in VSCode. Because it is web based it should have been straightforward to do. Doing the same with native technology…
That depends on all the code running locally...
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#255Just another day in the Electron universe. My personal favorite is resource waste of another variety: Slack and WhatsApp using multiple gigs of RAM for unbelievable basic (which is their selling point) chat apps.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#256It 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/e…
Cocoa has its issues, but I find it much more pleasant to use than anything based on front end web tech despite that. I find myself wishing I could use it on Windows and Linux.
I find many of the frustrations people have with desktop Cocoa come from the bizarre need to reinvent the wheel with a custom UI theme. If you stop fighting the system and instead go with a native look with well chosen accents, life is much easier. Native can look great with a little attention to detail.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#257Earlier 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.
Except that the abstraction layer for the user has remained the same. This is absolutely not true. Going to windowing GUIs from character-mode DOS was a massive usability improvement. No more exotic ctl-alt-function key combos (or control-control sequences for WordStar users like me). Going from desktop apps to webapps changed the abstraction layer of how we access and share documents. No more installing software on…
>No more installing software on the desktop
At least VS Code has to be installed. It is a plus for Google Docs & Co, but not universal. And in most cases, instead of installing you now have to create an account.
>Docs are available on every computer we log into. Multiple people can edit the same document.
Those features are completely independent from the platform the application uses. Those features are commonly implemented in web apps because for a long time they had no other choice, but cloud storage and collaborative editing can be equally well implemented in a destop application.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#258Yesterday 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.
With a decent implementation, a progress bar will run at 60 fps no problem. You don't need react for a simple progress bar either, just check no unnecessary is done (probably just need to update the width on an element) and use requestAnimationFrame if you receive updates at very high rate.
I admit I'm not familiar with frontend development.
I used this template https://github.com/secondtruth/startmin
I noticed that boostrap progress bar is a div,
https://www.w3schools.com/Bootstrap/bootstrap_progressbars.a...
that's why I guess updating it triggers dom update.
I'm still looking for a solution.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#259Earlier quoted context omitted.
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…
VS Code and Atom aren't really comparable for performance. VS Code is much, much smoother and closer to the experience of Sublime. > or example latest StackOverflow survey, showed that Notepad++, Vim and Sublime combined are used much much more than VScode and Atom combined By this metric Notepad++ and Visual Studio (not Code) are the best editors because they topped out of every category (except Vim for Sysadmin / D…
You should also sum all the procentages of Intellij based IDEs there, then VSCode is one place down
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#260It 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…
We have a lot of native GUI text editors. Gedit, Geany, Kate, and Notepad++ are free options, and then you have Sublime Text as a proprietary one. They all support plugins and extensions, they are all super efficient in CPU usage, etc. The thing is they aren't new, and because they are all C/C++ codebases developers wanting to add new features to text editors don't want to touch C++98 / ANSI C code from two decades a…
> when you consider the time investment to develop the infrastructure of a text editor today vs just using Electron, the time investment
...is exactly the same. No matter what gui toolkit you use, you still need to develop the infrastructure. Electron doesn't know how to handle keyboard and mouse events, it doesn't have a text buffer implemented, has no understanding of different text encodings, how to parse different languages, and draw different colored text accordingly, or format it, etc.