[w0utert]

>> What the earth needs is a better cross platform native GUI framework. NOT electron.

I always like to use VSCode as an example. It's a tool a use on a daily basis, and I like almost everything about it. It's also a poster-child for a good Electron application, maybe one of the best around. Add to that I completely understand why it was made using Electron, and why it might not have existed in this form (available, up-to-date, and feature-complete on all platforms, regularly improved, etc) at all if it wasn't because of Electron.

But it's not.snappy.enough.

Even though large performance-sensitive parts of it like the editor buffer data structures etc are (AFAIK) implemented natively, the whole user experience is actually quite bad. It's sluggish, inconsistent, it's full of random glitches, and everything feels like an insane amount of effort went into putting more and more lipstick on various parts of a pig to hide that the whole thing is like a house of cards and sluggishness and instability hides around every corner.

I feel a little sad that so many developers defend Electron so vehemently, pretending that it's 'ok', 'fine' or even 'very good' for end users, because it's not. I fully agree it's great for the people (and mostly the companies making money off the people) who develop commercial stuff with it, because it obviously saves a shit-ton of money if you want to deploy something across the 3 major platforms.

All of this is completely unrelated to the end-user experience though, who typically uses just one platform at a time and couldn't care less if the application they are using is also on some other platform. Or if they use it across multiple platforms, how many extra UI devs where needed to make native UI's for each of them.

Any developer who knows how freaking fast modern computers are and why should, when completely honest, should feel ashamed that something like Slack or VSCode is made in a way that makes it so sluggish and memory-hungry, and that we now all accept this because it's cheaper to develop that way, and the applications are (supposedly) 'snappy enough to run'

[sime2009]

> Even though large performance-sensitive parts of it like the editor buffer data structures etc are (AFAIK) implemented natively

Actually they are not. The search in VSCode uses an external exe writing in Rust, but that is about it as far as custom native code goes.

Atom though did add some native code data structures.

Claims that VSCode is "inconsistent, it's full of random glitches" doesn't match my experience at all. It's solid. Maybe it could be faster, but I find its speed acceptable and regularly run it on a laptop with an Intel i3 CPU.

[xtracto]

For someone coming from the Eclipse/Netbeans or Rubymine world, VSCode feels super snappy to me. I love it.

[GordonS]

> I always like to use VSCode as an example...

Agreed, it's a great example of why Electron exists, but also a great example of an Electron app done well - I've used other Electron apps that have far fewer features, yet feel sluggish and/or are incredible memory hogs.

> But it's not.snappy.enough.

I also use VSCode on a daily basis (on Windows), and TBH I don't find it any less snappy than native IDEs such as Visual Studio or Rider, or indeed native text editors such as Notepad2.

> the whole user experience is actually quite bad. It's sluggish, inconsistent, it's full of random glitches

Similarly, I just don't have this experience - I find it both consistent and performant.

Do you use it on Windows, or another platform?

[w0utert]

One of the standard replies I get when I complain about VSCode being sluggish is that it's not worse or even better than Visual Studio on Windows. That might be true, I don't use Visual Studio so I wouldn't know, but it's an argument that's completely unrelated to Electron. For me that's just whataboutism.

I would rather compare VS code to a regular editor with syntax highlighting, autocomplete and a few bindings to quickly kick off tasks, because that's essentially what it is. Could be Emacs, Vim, Sublime, etc. That's how I use VS Code, so that's what I compare it to. That said, for example XCode or CLion also feel faster, and I consider those way more feature-heavy than VS code.

>> Do you use it on Windows, or another platform?

I'm using VSCode on Linux, on a moderately sized C++ code base with the Microsoft IntelliSense LSP extension. I realize that some of the annoyances I experience are because of the C++ LSP stuff, which is still in preview, but it definitely isn't contained to just that. I sometimes also use VS code on macOS for JavaScript and Python projects, and even though it's a little better there, it's still nowhere near a good native editor. The weird glitches I experience are present on both platforms, and I've had a fair share of them. Keyboard input freezing for some seconds, buffers not updating when files changes, shortcuts not firing, drawing/refresh errors, just to name a few.

[GordonS]

> I would rather compare VS code to a regular editor with syntax highlighting...

So, Visual Studio is somewhat sluggish, but Rider is not. I also mentioned Notepad2, which is a native text editor - I find VSCode just as snappy as that.

> I'm using VSCode on Linux, on a moderately sized C++ code base with the Microsoft IntelliSense LSP extension

I haven't used it on Linux, or at all with C++. I've used it on Windows and MacOS, for Typescript, JavaScript and Cordova projects, as well as for note taking (because I find it as fast as a text editor, yet much more fully featured).

Honestly, I've been using VSCode for a long time now, and I've never encountered any of the glitches you mentioned. Just did a totally scientific straw poll of co-workers, who say the same. You sound unsure, but I wonder if it is due to an extension you have installed?

[renox]

Vim or Vim + YouCompleteMe? Because comparing VSCode which analyze your codebase with Vim alone isn't a fair comparison. My take: I prefer very much VSCode to Eclipse or CLion (Linux on large C++ codebase). As for Vim, I've never managed to configure it in a way that I can use ctags and multiple tabs as simply as I can do it in an IDE.

[markn951]

>But it's not.snappy.enough.

I was following you until this line... In general I agree about Electron though probably not to the same degree as you. But for me VSCode runs amazingly well; I think the only thing that tops it is Sublime (and I vastly prefer VSCode's interface and features). Not saying that what you said isn't your experience, but you should know it's not everyone's experience.

[arghwhat]

VSCode is worlds faster than Atom. However, relative to any native editor (Sublime Text, Gedit, GVim, Notepad++, Notepad itself, ...), VSCode ranges from anywhere between "sluggish" to "... is it frozen?". Now, I agree that how big the difference is, and how big a problem that becomes is subjective, but the presence of the difference itself is not.

A good example being opening a new window. This is something I do semi-often to edit something out-of-context that shouldn't taint my current workspace. Under anything from Notepad to Gedit or Sublime Text, this task has no perceivable latency. Under VSCode, however, it is so uncomfortably slow that I actively try to avoid it, and instead use Gedit for these editing tasks. This is a significant downgrade in workflow compared to Sublime Text.

So, why do I use it? Well, features. However, what must be made very clear is that none of the features I use in VSCode exist as a result of Electron. Terminal panes and the better Go/Rust integration has nothing to do with Electron, and are within areas of difficulty that I could have added it myself over a weekend had Sublime Text been open source. But it's not, so I can't.

Electron is cancer.

[pault]

I wish we could stop calling software we don't like "a cancer". It's hyperbole and detracts from the conversation, IMO. The phrase "x is a cancer" is a cancer. :)

[arghwhat]

s/is cancer/is an awful framework that significantly and irreparably degrades user experience, stability and performance of any application written with it/g

I find the term to be quite fitting here. The use has spread to an absurd degree, meaning that there is a large change that everyone is running one or more instances of this framework at any given time, and use of this framework not only harms UX, but also brings down the machine it runs on through resource consumption. Well, maybe "pandemic disease" is better than "cancer".

When everything uses something like Electron, you the ability to simple chose to avoid it. Like a disease, Electron is that you involuntarily get subjected to, and as such, would prefer to see eradicated.

(And yes, yes, we should improve the experience of making cross-platform native apps, but due to Electron, no one is even trying anymore outside of mobile.)

[ulisesrmzroche]

What are the specs on your computer? How old is it? HDD?

[arghwhat]

My work machine that I used as reference here (my personal machines are similar, and suffer from similar sluggishness):

Intel Core i7-8700 @ 3.2GHz (12 threads, Coffee Lake)

64 GB 2666MHz DDR4 RAM (4x Kingston KHX2666C16/16G)

SAMSUNG MZVLB512HAJQ 512GB NVMe PCIe SSD

GPU is just the built-in UHD Graphics 630

Opening a new window takes presents a blank, black window that has more and more UI glitch in over a 2 second period. This is very frustrating for as a file-open delay when doing quick small edits. Gedit, on the other hand, does it in the time it takes to make the "fwoosh" opening animation (which can supposedly be disabled for faster start).

And for the record, there are no specs bad enough that a text editor should have a noticeable delay to open.

[ulisesrmzroche]

I dunno bout the graphical glitches but I run it on a machine far less beefier than yours (MacBook Air early 2014) and it runs fine for web dev on blogs and static sites and writing blog posts and small scale projects even with a bunch of plugins installed.

The only time vs code got unbearable to use for me was on this iMac late 2013 with an HDD drive I got on Craigslist a month ago but once I upgraded to SSD it was like a whole new computer, even running VMs and Kubernetes, VScode runs real nice working on large scale enterprise apps.

But yeah your computer sounds strong enough to handle any IDE so specs not the problem.

[KaoruAoiShiho]

Going from Sublime to VSCode felt intolerably slow. I think Sublime is much better but the trillion dollar company is too much to fight against I guess, the community for VSCode is too big now.

[tcrow]

I have been a big fan of VSCode for a while now even enthusiastically recommending it to my fellow colleagues but lately it has been VERY sluggish to the point where I am about ready to ditch it and go back to something like Sublime 3. I love the editor but the performance definitely leaves a lot to be desired.

[oceanswave]

I find that VSCode outperforms Visual Studio in ‘snappiness’ where Traditional VS lags greatly occasionally on editor input... as far as random glitches go, VS is shite in that dept.