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…
There really isn't much competition though. Sublime is commercial. Many people don't like emacs or vim. Most other editors are confined to one OS (Notepad++, Kate, etc). When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.
VS Code uses 13% CPU when idle due to blinking cursor rendering
601–610 of 801 posts
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#602I'm reminded of this classic: https://github.com/npm/npm/issues/11283 NPM had a progress bar that was so fancy that it slowed down installation time (basically its only job) by ~50%. Hilarious. My mantra here is, if you find yourself thinking about implementing a fancy loading spinner/progress bar, it would be more productive to just spend that time making it unnecessary - speed up your shit! Obviously that doesn't a…
This reminds me of one of my favorite old tech stories. A long while back (seems like this was the late 90s or early 2000s) I was working on a script that did some data processing on a remote machine. It had to loop through a bunch of text log data and generate some reports. Being as that I had no idea if the script was actually working until it completed awhile later, I decided to put in a neat little ASCII spinner…
On the same project I discovered that "System.Envireonment.NewLine" was a relatively expensive call on c#, caching the result of that property was another 50% cut to CPU.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#603Earlier quoted context omitted.
Luckily there are a few people that still care, just look at the response Handmade Hero has gotten.
Those videos on data oriented design were also very interesting: https://github.com/taylor001/data-oriented-design The thing is, using C++ instead of React for mobile development of a simple application would probably make me miss deadlines... So we just stick to whats popular.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#604Earlier quoted context omitted.
There really isn't much competition though. Sublime is commercial. Many people don't like emacs or vim. Most other editors are confined to one OS (Notepad++, Kate, etc). When it comes to a full featured, modern editor that works quite well out of the box on most modern OSes, I struggle to come up with any answer other than VS Code.
What's wrong with using Sublime? Quite possibly the best text editor I've ever used. It's snappy, elegant, and it has a boatload of features.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#605Earlier quoted context omitted.
Also compare Google Docs with Microsoft Word and LibreOffice cold start up time. You will see 2-3 seconds is fast and the two mentioned are not even loaded from a remote resource...
Excel loads in ~1 second...and doesn't have UI lag after it does. Try working with large data sets in Google Docs and you'll have that 2-3 second lag time with _every_ operation you perform.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#606Earlier quoted context omitted.
I have the same experience on my pretty slow laptop. Granted, my projects aren't big, but I would take vs code over sublime any day. Interestingly, atom feels much slower compared to both.
That's because, unequivocally, atom is slower. https://pavelfatin.com/typing-with-pleasure/
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#607Earlier 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? Ugh, reddit's standard, snarky response: "you do realize... right?" There's simply no way to get around the fact that by and large, many in-browser apps are poorly performant by any modern standard. To me, it seems like there's a faction within the…
The benefit is to their paymasters, as they get to extract rent (either directly or via ads) without having to contend with software pirates because the actual software logic is sitting pretty in a server cluster somewhere. Effectively we are back to the world of time-share terminals.
This realization that always-connected apps might be joined by disconnected apps is emphasized when looking to markets across the world. There are more disconnected people in the world than always-on, high-speed, low-latency connected. There is a burgeoning middle class characterized by sporadic, low-speed, high-latency connections, who are willing to spend some money online, for those times they make it online. They might spend pennies each today, but whoever captures those markets is addressing billions of underserved online customers. I'd take a billion $0.01 payments a day any day.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#608Earlier quoted context omitted.
Best bit is that X11 runs really well these days -- responsive, fast, reliable. Emacs runs great, gitk, xterm, xosview, mplayer window manager, even Firefox is alright. Renoise, Maya, Blender too. Not to mention network transparency when I need it. It's a great environment to get my work done, and 3x hi res displays is the stuff I dreamt of 15 years ago. So it's a good job we're about to throw it all out and start ag…
> Not to mention network transparency when I need it You realize that no X client draws like this nor has for 20 years right? They all use xshm to upload pixels so this "network transparency" is just buffer copying over the network. Not entirely different from a texture upload to a GPU. > So it's a good job we're about to throw it all out and start again, eh folks? Yes, by those of us who have been working on the sam…
You seem to be misinformed. Of the applications I mentioned, the main ones (gitk, xterm, emacs, xosview) are not doing that; seen clearly by analysing the X traffic.
Of course, some of these could be built with an optional Qt front-end, in which case I would not be surprised.
So you stated clearly "all" applications (for "20 years") which is provably incorrect; and I home in on this because it's a recurrence of another 'well, you never had it before' argument (that really might be better directed at the decaying state of X11 client toolkits)
X11 isn't perfect, I have no doubt something better can be engineered (especially if it involves those who worked on X11). But people are missing the point that to replace X11 is a different matter from designing a better one. It involves acknowledging those who are quietly and successfully using X11 on a daily basis for the majority of their work and existing applications -- not telling us how wrong we are.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#609Earlier quoted context omitted.
If you learn React, you can write for web, multi-platform desktop and (native) mobile, with React Native. Same can't be said for Qt or WPF. Also the Qt community is minute compared to the JS community, that is significant.
"If you learn how to build doghouses, you can build skyscrapers, bridges, and nuclear power plants." Use the right tools for the job. Trying to shoehorn everything into "the web" makes everything just as shitty as the web.
i wonder if this expression constitutes a thought-terminating cliché.
Re: VS Code uses 13% CPU when idle due to blinking cursor rendering
#610Earlier quoted context omitted.
For those who missed it, n-gate satirizes some HN posts, to the delight of all: http://n-gate.com/hackernews/
Oh my god... n-gate is pure gold!