[disillusion]

I think it's interesting how debates about Electron inevitably end up with the arguments 'the developer wants X' vs 'the user wants Y'. However, there's one aspect a lot of people seem to overlook in their arguments: pragmatism.

The ideal application:

- uses almost no memory

- uses almost no disk space

- is extremely fast

- costs (next to) nothing

- and has all the features in the world

- presented in a manner that automatically shows the user only the exact features (s)he cares about

In the real world, we have to balance the project/product requirements. In the end, only these things matter:

- It yields a net profit (monetary or otherwise) for the company or owner

- It has (and keeps) added value in comparison to similar software

- It's fun to design and develop in/for

- It has bugfixes and new features in a timely manner, without taking up too much development time

- It has a pretty, easy to use interface

- It's quick and snappy enough to run

Adding that all up, and developing in something like Electron is a no-brainer: mean time between iterations is faster, design and development is more fun and the end user has a product that is fast enough for their needs packed with features. Try that in any low level language or without control over the engine and you'll have to severely hamper one of these goals.

[sh4rk]

I disagree.

The ideal application:

- uses no memory

- uses no disk space

- is instant

- costs nothing

- and has all the features in the world

- presented in a manner that automatically shows the user only the exact features (s)he cares about

The real-world application, when the developers work for the customer and not for themselves:

- uses almost no memory

- uses almost no disk space

- is extremely fast

- costs next to nothing

- and has almost all the features in the world

- presented in a manner that automatically shows the user only the exact features (s)he cares about

[fb03]

I disagree.

Sadly, we need to balance features, performance and expectations with our own expectations about what kind of software we want to deliver.

I sincerely hate Electron and the whole ecosystem of bloated apps it enables BUT having matured a bit i can understand why it exists. People that hold the money want software out and want it fast and they don't care if the customer now needs almost 4 gigs of ram in their phone just to play music or browse the odd website.

A depressing state of affairs imho, specially for us "old folks" which enjoyed our software native and optimized as much as we could.

[johnday]

But developers do work for themselves...

[tobyhinloopen]

I feel like i've seen this argument before, for Java desktop applications

[Cthulhu_]

And in my experience those have never taken off - just like in-browser applets - because they were too slow. The only Java based desktop applications I can think of are IDEs to write Java with, and those are too slow.

[diegoperini]

This comment should be posted under each Electron vs The World discussion as a reminder by a bot.

Disclaimer: I hate Electron. (but really appreciate and admire its developers)

[sigi45]

Slack is Electron. Slack is installed on many laptops. Slack App just sucks and wastes real resources.

[rkangel]

Genuine question - why do people install the Slack App? I haven't in ages, I just use the web-app and am very happy.

[fedesilva]

At least for me, webapps are just 1 in a thousand tabs open in 500 browser windows (ok, I exaggerate a bit). For an app with it's own window I can just hit a shortcut and said app gets focus. Disclaimer, not an Elektron fan.

[fauigerzigerk]

Same for me. I'm so surprised that browser makers still haven't solved this particular problem in spite of all browsers now being multi process.

[ronsor]

use `chrome --app`

[fauigerzigerk]

That doesn't work on macOS.

[lojack]

Different screen share features only work in the app. I'd use the web app if all I needed was chat, but I'm on video calls and using screen share constantly.

[sigi45]

I use slack on my second screen.

[jamil7]

Pretty perfect summary and the reason why I pick native for side projects and electron for paid work (unless explicitly requested).

[fxfan]

> snappy enough to run > Electron is a new brainer

Not everyone on earth is a dev/gamer/video-editor. For regular people, electron is a cancer that needs to be nipped in the bud. Remember, 91% of the desktop on earth is Windows (meaning regular USD 300 machines). And of them I'd wager less than 10% fit have machines where electron is snappy (1.2K Thinkpads).

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

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

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

[faitswulff]

> Not everyone on earth is a dev/gamer/video-editor. For regular people, electron is a cancer that needs to be nipped in the bud.

That's not how I expected that sentence to end. I don't think regular people are nearly as concerned with performance as the groups you listed are. Regular people are probably using Electron via Slack for work and if it's slow and bloated it's ultimately not their problem. Even a few seconds delay won't cost them anything when it's still a faster replacement for email.

[toyg]

The irony of talking about "regular people" and then using Slack as somebody "regular people" actually use.

"Regular people" are likely to encounter electron by using Telegram or Whatsapp on the desktop, or some recent MS product like Skype. Whether they care or not about bloat, I don't know. I know those chat programs used to have annoying problems with cut & paste and not supporting basic assistive technology (i.e. the "emoji keyboard"), but I have to admit they got better with time; if those fixes have made it upstream to Electron, then things are improving. They are still horribly opaque to native OS services like sharing facilities and whatnot, but it looks like OS developers themselves are throwing all that away these days, so...

I expect the real issue Electron might never solve is real support for more advanced assistive tech for the visually-impaired and other disabled people. That stuff barely works with traditional desktop tech as it is. Obviously that has never been an obstacle in the market at large, it mostly plays a part in public-procurement processes.

[AnIdiotOnTheNet]

As usual, "regular people" means whatever the poster needs it to mean in order for their argument to make sense. It's a straw man.

[sorenjan]

> "Regular people" are likely to encounter electron by using Telegram or Whatsapp on the desktop

Telegram is written in C++ and uses Qt. Maybe you're thinking of Discord?

https://github.com/telegramdesktop/tdesktop

[FiddlyPack]

Electron has a leg up in this regard long term, insomuch as the web is a platform that folks using assistive tech often use, Chromium is a reasonable target for assistive web technologies, and Electron apps have a higher chance of using accessible semantic building blocks by default.

Now, in practice? Yeah, not so good right now.

[chupasaurus]

Telegram Desktop is a Qt-based app and it doesn't run everything on top of QtWebEngine.

[fxfan]

How many non-devs (equivalent to the group of RAM < 6GB) use slack?

[fedesilva]

About 6k+ people use it in my org - the vast majority are not devs.

[eyko]

I work with a few organisations and small teams that use slack to communicate. They're campaigners, marketing types, logistics, finance, HR, and overall general staff working for businesses and organisations. I was also attending some university lectures recently (on history) and the class had a slack account which we were invited to join if we had any questions or needed support.

You also don't need to focus on Slack. Skype is an electron app. How many people use Skype to connect with their family?

[Ari_Ugwu]

For what it's worth I used VSCode as a ARM build on a Chromebook with crouton. It was fine. I think it cost me $150 used.

> cancer that needs to be nipped in the bud.

Come on with the hyperbole. Electron is effectively (nipped) as it is most usually just the shortest path to giving apps a persistent offline option outside of the browser sandbox. I don't know of _any_ electron app that isn't also a dedicated web app. VSCode is embedded as an editor in a few online code sandboxes.

Electron apps will almost certainly be replaced with PWA akin to the MS strategy. Shared run time, distributed via a 'store' of some kind, etc. It's an arc that we are in the middle of.

I get it, the world needs a better solution. However there isn't one. There isn't even a #2 best option. Electron's success is just the industry's continued failure.

You'd think Google would be close with Flutter, but Flutter doesn't run in the browser. So, fail.

Are there any options you'd suggest using _over_ Electron?

Every couple months an electron thread pops up and gets the same bashing.

The world very much needs electron and that's why it exists. jQuery was the same way forever. People just complained _constantly_ that we should be advancing the spec and using built in calls. That jQuery was some sort of bloated misstep. Well, we're still waiting for web components to be standardized more than 15 years later.

So as I understand it, people that don't like electron would rather us use _nothing_. Thus providing _no_ stepping stone to what should rightfully come next.

I see the same thing with electric cars. They aren't perfect _now_ so why invest in them at all? Why even explore an avenue that could lead to other innovations if it isn't _perfect_ out of the gate? 91% of the world population don't even own cars!

[fxfan]

Why would you upvote me if you didn't agree with me?

QT is what i would suggest over electron

[Ari_Ugwu]

Did I up vote you? Likely because your post was provocative and got me to engage.

[ericol]

Also, in the third world things are moving towards machines running celeron / atom CPUs, with 4GB of memory and 32 GB of hard drive space.

Out of experience can tell you 32 GB is a space that can be killed rather fast.

[jw14]

Over the years we've had many cross platform GUI frameworks. Both native (wxWindows, SWT) and non-native (Swing, Qt). Everyone was trying for "better".

There have always been questions of adoption, stability, fidelity of the user experience and others.

Meanwhile web apps have kept chugging along and browsers have gotten better and better.

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

I contend that "native" is irrelevant. People are "native" web users. They use web based interfaces daily. A browser based UI is the "cross platform native" (whatever that means) GUI.

It can be fast (if you do the work, which may involve firing up external processes) it can be beautiful it can look native and it can deliver great user experiences.

It's not the GUI framework we wanted, but it's the one we deserve :)

[baldfat]

> Not everyone on earth is a dev/gamer/video-editor. For regular people, electron is a cancer that needs to be nipped in the bud.

My 10 year old netbook runs RStudio? Discord works great on my 10 year old Dell 2nd screen computer. What doesn't run VSCode?

[finnthehuman]

>What doesn't run VSCode?

Last week was the first time my 2015 XPS laptop started swapping too hard to get any meaningful work done, and that was because I jumped onto a project with a vscode workflow.

Technically it can run vscode fine. But only if it's exclusively vscode.

So now I'm working in my editor of choice most of the time, and then closing all my open applications whenever I need to use the vscode extensions.

[baldfat]

Something is seriously wrong with your machine if ti is having issues running VSCode.

[bitwize]

Qt isn't good enough for you? These days it's even scriptable with JavaScript.

[jasode]

To add some fyi... a lot of Qt experts recommend you restrict the usage of Javscript to the QML layout of GUI controls and data binding. For business logic (especially cpu-intensive tasks), use C++.

Example of that "avoid Javascript" advice:

deep link: https://youtu.be/vzs5VPTf4QQ?t=30m55s

[bitwize]

Even then, you have great bindings like PySide (for Python) that allow you to build Qt apps without resorting to C++. And it will still be snappier, and easier on disk and RAM, than Electron.

[beaconstudios]

and until that exists?

[dspillett]

But also remember that those $300 machines are mostly used for next to nothing. For the vast majority of the time people with those machines will have a couple of social media apps open in browsers, a media player running, maybe a mail reader, and perhaps some simple casual game. They aren't going to be running the several apps of any sort, never mind Electron ones, so what does it matter that several Electron apps would make the machine grind into a swappy mess?

If the regular people expect anything modern to be snappy on those machines then they have been mis-sold to[1] and that isn't our fault as devs.

> What the earth needs is...

Then why don't you put a team together and make it, and gain the fame and fortune that comes from solving the matter?

> NOT electron

Nobody is forcing you to use Electron based apps. If you find them, or anything else, too slow then find an alternative that is in a native toolset or entirely browser based, or what-ever.

A key problem is that people want what the want, they want it now, they want it to work on their platform without needing specific version of anything else (i.e. a browser), and they want it free. If Electron allows the thing to be delivered now, in a cross-platform manner, and people aren't willing to wait or pay for the dev time to develop in something smaller/nippier, then Electron is what devs are going to use.

I remember similar arguments regarding VB way back when: people wanting something that started faster and used less RAM bitterly complaining, but not wanting to use alternatives that were available because they cost more. To my mind Electron has a very similar feel to VB back then: great for prototyping, but can be used to produce fuller solutions too if you are willing to accept the cost in speed and weight.

[1] Oh how I love having to explain that 32GB total storage isn't really enough for Win10, especially when that is slow eMMC and the machine is swapping to it on account of only having 2GB RAM, when the sales person[2] said otherwise.

[2] People don't seem to accept "well go ask the salesman to make Office fit and make it go fast for you, you obviously think he knows more than I do"[3] as a valid response...

[3] Heck, those diminutive laptops/tablets/black-boxes-to-plug-into-your-tv, that are still being actively sold as Win10 compatible, can't even install the latest Win10 updates without some technical jiggery-pokery.

[blablabla123]

>The ideal application:

>- and has all the features in the world

In this case it's okay if it uses up all disc and memory. Actually it can even cost something in this case because only one application is needed.

It should be open source though so users can audit it and fix bugs if required. You see, just by requiring consistency in the requirements, one can get very far. Optimizing for typical startup metrics is just one way to do things but not the only valid one.