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