Electron gets a lot of hate, but I think people generally are looking at the wrong thing when focusing on memory usage, ask yourself why it’s so important to so many organizations.
The number one cost at most companies, is humans. Before electron what did you have for cross platform development? Java was there, but that never really took off for embedded UI inside the browser, and the browser became the primary target for most businesses in the last ten years.
Electron allows small teams to focus their most costly investment on developing toward one product being developed across many platforms.
I use electron apps that give a consistent experience, on macOS and Linux (not personally Windows, obviously as well), and then the same web app on Firefox, Chrome and Safari across those same platforms with the addition of my phone.
Yes, that comes at the cost of running a full browser, but it’s a logical choice when optimizing for the diverse computing landscape of today.
"Looking at the wrong thing" is a matter of perspective. As a user, I couldn't care less that you saved money by writing a bloated web app. I care about the resources I have, which includes my own time, energy, money, computer, battery etc. In those terms, there are clear disadvantages to Electron based software.
The incentives are all messed up due to how we pay (or don't) for software; this is similar to how it's much easier to waste viewer's battery and bandwidth showing adverts than it is to charge them money.
Isn't this mainly because of the OS builders? MS, Apple, and Google? The only cross platform GUI system they all support at this point is browser based UIs. And given that developers basically any UI dev practically needs to target the web now, I don't see why this is surprising.
We seem to be blaming developers, but developers are just dealing with an ecosystem where this is the best common denominator. There's another comment in this thread, that points out that Electron is only 5 years old, and there is a lot of opportunity for performance and system utilization improvement.
IMHO if we want this to be better, then the OSes should make this easier and more performant for developers, and by extension, then their platforms will out perform and outsell the others.
My basic point there being that losing a small number of users due to these concerns is probably worth it.
I don't want to come across as someone who's hyper-defensive of Electron. I hate the fact that such a bloated piece of software has become the standard means for supporting cross-platform development. At the same time, I really don't see other viable options at this point in time.
I'm curious though, is there something you would recommend instead that meets these requirements with a single codebase (~90% shared code): target all major platforms (macOS, Windows, Linux) and target all major browsers (Chrome, Safari, Firefox, Edge, IE), (edit: and how could I forget, all major phone browsers) with nearly identical UI/UX?
There is no such thing and I would argue there shouldn't be. The notion that you could use a "nearly identical UI/UX" across a desktop application, a mobile application and a web page invariably leads to horrible results. The usecases are just too different. The only reason people pretend otherwise is laziness and cost cutting - a context in which Electron seems reasonable as well, to the horror of technically literate users everywhere.
What might be reasonable, at least for applications that aren't performance sensitive, is asking for a cross platform solution between desktop OSes and a different one across mobile platforms. Those exist, as you well know.
> There is no such thing and I would argue there shouldn't be
It's one thing to not want to use Electron app, it's another to say no one should use them. It rubs me the wrong way. There are a lot of things I'd never use, but they don't rile me to that level.
> The only reason people pretend otherwise is laziness and cost cutting - a context in which Electron seems reasonable as well, to the horror of technically literate users everywhere.
"Laziness and cost cutting" is just your label for trade-offs you don't agree with. That would apply to cross-platform Java/Swing apps or Gnome. The "technically literate" users don't have to worry about business considerations and engineering tradeoffs - the authors do. If memory usage is such a big deal, then the market will self-correct, I was told it's a meritocracy.
> It's one thing to not want to use Electron app, it's another to say no one should use them. It rubs me the wrong way. There are a lot of things I'd never use, but they don't rile me to that level.
The reason this trend riles me so much is that we now have companies like Slack, which easily have enough resources to do an efficient desktop app on any platform they choose, releasing utter garbage that, far from merely wasting memory, takes up ridiculous amounts of CPU time (and therefore battery time and energy) to do the simplest things (like render emoji, or even a blinking cursor). The aggregate waste of resources is mind boggling, and we've gone far past the point where Electron was solely used as a quick solution for very resource constrained companies or single devs.
> "Laziness and cost cutting" is just your label for trade-offs you don't agree with. That would apply to cross-platform Java/Swing apps or Gnome. The "technically literate" users don't have to worry about business considerations and engineering tradeoffs - the authors do. If memory usage is such a big deal, then the market will self-correct, I was told it's a meritocracy.
It certainly does apply to Swing apps, Qt, Gnome, etc. I've always considered all three of those frameworks ludicrously bloated, by the way, but Electron has far exceeded my worst nightmares in that regard.
I'm not sure who told you the market is a meritocracy or why you believe it, but I don't see much evidence for that view, personally.
> My basic point there being that losing a small number of users due to these concerns is probably worth it.
Again, this is the developer's perspective. As a user, I don't care at all how many others use my email client or text editor. What's more important to me is that it doesn't suck, especially on my personal computer which isn't quite as tricked out as the computer I use at work.
My point is as previously stated: there are multiple perspectives on this. For me as a user there is absolutely no benefit to the developer using Electron. I don't care if it took a million man years to put together; I care about my own resources. I'm not arguing with your perspective, just arguing that it's just that, one perspective, and that users aren't "looking at the wrong thing" when they complain about the result being crap.
> At the same time, I really don't see other viable options at this point in time.
Electron is five years old. Surely, developing a cross platform application was viable before that? Seems like an ironic statement considering that the larger part of Electron is Chromium, a cross platform GUI application predating Electron. There are plenty of libraries and frameworks that abstract OS specific stuff with regards to GUI, networking, file system handling etc.
> I'm curious though, is there something you would recommend instead that meets these requirements with a single codebase (~90% shared code): target all major platforms (macOS, Windows, Linux) and target all major browsers (Chrome, Safari, Firefox, Edge, IE), (edit: and how could I forget, all major phone browsers) with nearly identical UI/UX?
For one, your web app could be just that: a web app. There's no reason to have multiple copies of chromium running and littering your disk when you already have a browser.
Second, these UIs that look consistent across all platforms probably make the designers happy, but for the user (or at least me, personally) it is better if the interface is consistent with the design conventions of the platform it's running on.
But no, I don't really have an alternative to suggest if those are your goalposts. Targeting multiple platforms is just one of those things you have to suffer through with some consideration if you don't want your application to be a bloated webapp-bundled-with-a-browser.
> I'm curious though, is there something you would recommend instead that meets these requirements with a single codebase (~90% shared code): target all major platforms (macOS, Windows, Linux) and target all major browsers (Chrome, Safari, Firefox, Edge, IE), (edit: and how could I forget, all major phone browsers) with nearly identical UI/UX?
That is ridiculous comment to start with. You might as well say that something's name has to start with an 'E' ends with 'n' and is 8 letter word and developed by Chrome browser team.
If it were not a software, I think it would right in category of 'blame the victim'. Seems you really believe it is users problem that they do not upgrade their phones and computers every couple of years.
Is it, really? Let's drop the web as one of the platforms we don't want to target. There are some reasonable options left, but when you add the web in, and just limit that to the major browsers, your requirements for support just got extremely more complex. Why do you want to target the web? because in general, that's the easiest place for user acquisition and on-boarding of a product.
And where did you get this: "Seems you really believe it is users problem that they do not upgrade their phones and computers every couple of years." This is a decision people need to make in how they target certain users. If your target user base has limited compute available, limited bandwidth, limited memory, etc., then of course you need to build software that meets your business requirements.
There are no victims here, there are users, potential users, and former pissed off users who've gone elsewhere. These are all business decisions you need to make as a developer. If you target Electron and by doing so piss off all your users and they ditch your software, then you screwed up. But I only see VSCode gaining in usage, even Slack being a horrible memory hog, they're still gaining customers.
In a nutshell, there are companies that are being very successful with this, success is hard to argue with, as much as you might dislike the way it's being achieved.
It's not quite that simple though, because plenty of high profile apps have gone through large rewrites from native to Electron. Skype is probably the biggest offender here, taking an app that was actually quite good and turning it into a steaming pile of crap.
Alternatively, we've got closed systems like Slack that are slowly and pervasively getting rid of open systems like IRC.
I'm really not sure that there's an engineering time advantage in taking a reasonably solid existing piece of software and rewriting it in Electron. Is the technical debt really that large?
Really, I think the problems we have are political, and not technical. I include things like NIH syndrome in that group.
I think there's an inevitable undeniable need some something like Electron, but it needs to be well supported and ubiquitous.
Before Electron there was xulrunner, whose main purpose in life was to be the cross platform application layer of the Firefox web browser.
Even though it was officially an unreleased "technology experiment", xulrunner was successfully used both internally at Mozilla to develop Thunderbird and Sunbird, and externally to develop other cross-platform desktop apps like TomTom Home, Uploadr, Nightingale, Songbird, Miro, Joost, Lotus Notes, etc.
But xulrunner was never as fully fleshed out and widely used as Electron, and Mozilla was never serious enough about supporting xulrunner as a platform for other applications, for it to be viable in the long term.
It never caught on and became a standard, and now it's obsolete.
>XULRunner is a "technology experiment", not a shipped product, meaning there are no "official" XULRunner releases, only stable builds based on the same code as a corresponding Firefox release.
>Mozilla stopped supporting the development of XULrunner in July 2015.
In order to solve the problem of every application shipping with its own web browser, there needs to be ONE standard Electron shell that can run all those simple apps and even the advanced ones, and apps need to be able safely include their own native code extensions.
Many people developing Electron apps explicitly and legitimately WANT their app to include the whole web browser, just so they don't have to expend any effort supporting other browsers.
Electron needs to mature and become stable enough that there can be one global install that runs all apps.
But that requires long term support, and a big enough well funded team working on it full time.
Just as all the successful corporations who built on top of OpenSSH have an moral obligation to support its developers, I think successful companies making money by shipping big fat Electron apps today have a moral obligation to support the development of a standard Electron shell.
I remember XULRunner, but never used it. Do you know if it was any lighter weight, or how much so, than Electron?
> I think successful companies making money by shipping big fat Electron apps today have a moral obligation to support the development of a standard Electron shell.
I agree completely. The issue that I mainly see, with the possible exception of Linux, it's a drop in the bucket of number of users (and has it's own issues GDK vs. QT/KDE), the main adversaries have traditionally been the OS builders. They actively seem to be intentionally creating a walled garden model.
Yes, ever since computers became "fast enough" developers have traded user's efficiency for their own. It's faster to write, but slower to run. The difference is that it's written once but run thousands or millions of times each day. It's distributed waste of resources, and it adds up.
The conservation of developer's time (and company money) at the expense of the users' time and money is the epitome of an externality. It's clear that we'd all be a bit better off if user's time was valued more. But who's going to pay to make that happen?
The users. If a person wants something, they buy it; if they don't, they don't; and if they didn't, they didn't.
A very simple and straightforward model of action. Yet it has fueled almost every major non-military-funded technological advancement since at least the Industrial Revolution, inclusive.
(And if you consider the military a very special customer who has been graciously granted the disposal of the entire nation's profits ... then they are no exception after all.)
Users could easily pay a few cents more to hire that competent dev to optimize, but there's a massive information problem that keeps the option from showing up.
> The number one cost at most companies, is humans. Before electron what did you have for cross platform development?
Why does development have to be cross platform?
If you are a startup with a small team, and you truly only have two or three developers, then I can understand this desire. I totally understand the "this was my side project" or "we're just four people in a garage" arguments. I get it.
But most products people complain about are from billion dollar corporations that could easily handle having totally different codebases for 4+ platforms clients, (with way more total lines, but only a little bit more complexity and cost) than one single cross-platform super-client. Humans are not expensive to these companies, and we're only talking about adding a few more.
From my own personal experience, writing a native Java Android version and a native Windows UWP C# version of the same app, the effort + maintenance of those two codebases combined was only a little bit more effort than writing one HTML+JS+Electron-ish project that spits out an Android and Windows version. Native code just isn't that difficult if you spend a little bit of time learning their APIs (I would argue it's actually simpler than modern web frontend).
I understand why companies choose Electron instead -- and I've even had to do so myself at times, I get that. It's great for small projects or low-budget projects or internal-only uses, etc.
But it's not unreasonable for people to complain a little bit when these large hyper-popular billion-dollar services (like Slack or Spotify or Twitter) cheap out a bit on their software in that way.
Electron started as an experiment that took off with quite a bang, and all told it's still pretty new. I think there's a lot of efficiency work to be had, but it's stunning how easy it makes building GUIs.
I use VSCode (electron based) on a flight cross country regularly. I generally have enough power for the flight (4-5 hours), without much problem.
The memory usage hasn’t been bad enough for me to notice it stealing resources from other apps that need it. I don’t think most users notice.
I’m not talking about you. It’s clear this is a big deal to you, and so I assume you don’t use any electron apps. I think that’s a gamble most companies would make, losing a small number of users, to have the potential to gain many more.
I think with Slack, the computational workload is just network I/O and rendering text and images. With VS Code, in addition to rendering text, there is code linting and compilation, which is more intensive.
I'm a React fanboy, but no. VS Code is definitely written on top of Electron, and as far as I know the codebase is entirely custom rather than using any kind of JS SPA framework.
I generally agree with this. And maybe WASM will offer some new options here, such that native code can now target the browser. That will give us different options for targeting all platforms, possibly allowing for a world where cross platform development doesn’t come at the cost of memory and performance.
Compared to some of the Adobe products I have to use, 500MB would be a dream.
There was a time when I couldn't have two Adobe products like Photoshop and Illustrator open at the same time. They would just continue to hoard resources until my machine locked up and I had to reboot.
Even today I have a fairly robust system (i7 processor, 16GB of RAM and a 3GB Video card) and running multiple programs still makes all my fans kick in and start whining at me.
