In Defense of Electron(dev.to)
dev.to
In Defense of Electron
https://dev.to/bitario/in-defense-of-electron
156 comments
> Electron is a crutch. A crutch that people resort to because it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else, but, worse still, a _debilitating_ crutch that, unless you know what you are doing (and I daresay that is something people should be looking into) delivers overly bloated, resource-guzzling apps that wreck usability, battery life and (most visibly) RAM in _any_ OS.
See, the other word for crutch is " force multiplier". And in one sense, the crutch is for the almost comically broken state of cross platform UI toolkits. GTK+ is inadequate and hard to use. KDE not only mandates language choices and tooling but also offers only marginal improvement.
Every "good" and widely praised xplat GUI toolkit is either custom built for a browser or IN a browser. Apple's toolkit gets praise, but is hardly crossplatform. Microsoft is starting to ship an option, but it's not well cooked yet.
It's one thing to note the problems with electron. It's another entirely too imply it has genuine competition. As far as I can tell, it does not.
See, the other word for crutch is " force multiplier". And in one sense, the crutch is for the almost comically broken state of cross platform UI toolkits. GTK+ is inadequate and hard to use. KDE not only mandates language choices and tooling but also offers only marginal improvement.
Every "good" and widely praised xplat GUI toolkit is either custom built for a browser or IN a browser. Apple's toolkit gets praise, but is hardly crossplatform. Microsoft is starting to ship an option, but it's not well cooked yet.
It's one thing to note the problems with electron. It's another entirely too imply it has genuine competition. As far as I can tell, it does not.
It does if you are willing to step out of the "let's do everything in HTML and JS" echo chamber - hence my mentioning there is no alternative for quick and dirty apps.
The definition of this as an "echo chamber" is itself a value judgment that denies fair debate. Is Qt better? Can it deliver better outcomes with more tooling flexibility? I think not.
While someone else labors for something "slow and clean" to invert your analogy, Electron itself is improving. And many electron apps can be cleanly hosted on a browser environment, which further puts them out of reach.
What's interesting to me is that for every successful cross-platform app I can name, it has a custom UI (and in some cases custom runtime) engine around it. That's great if you have the engineering capacity to swing it. I'm not sure many do.
I wish we had a great, open source cross platform GUI toolkit that didn't mandate the use of C++. I don't think it's easy to suggest using C++ is reasonable for the vast majority of app devs. It's increasingly specialist even in its main domains.
And I'm not in that "let's use JS" echo chamber. Look at my submissions to see where my affiliations lie. I just cannot deny those folks can pull off better looking, better specified, and more accessible products for a fraction of the total effort.overrides this. I refuse to handwave that away.
While someone else labors for something "slow and clean" to invert your analogy, Electron itself is improving. And many electron apps can be cleanly hosted on a browser environment, which further puts them out of reach.
What's interesting to me is that for every successful cross-platform app I can name, it has a custom UI (and in some cases custom runtime) engine around it. That's great if you have the engineering capacity to swing it. I'm not sure many do.
I wish we had a great, open source cross platform GUI toolkit that didn't mandate the use of C++. I don't think it's easy to suggest using C++ is reasonable for the vast majority of app devs. It's increasingly specialist even in its main domains.
And I'm not in that "let's use JS" echo chamber. Look at my submissions to see where my affiliations lie. I just cannot deny those folks can pull off better looking, better specified, and more accessible products for a fraction of the total effort.overrides this. I refuse to handwave that away.
Can you think of a Qt or, heaven help you, Xamarin-whatever based app that is really that much strikingly better than something like VS Code, as user interface and experience? OS X app, to narrow it down a little. I can't.
Convenient you pick VS Code as your bar, given it's probably the one acceptable Electron app anyone can think of.
Meanwhile, I can think of a dozen native apps that behave better than Slack or Spotify or Atom, just to name a couple of obvious examples.
Meanwhile, I can think of a dozen native apps that behave better than Slack or Spotify or Atom, just to name a couple of obvious examples.
It's not only convenient, it's entirely deliberate. I don't think comparing bad Electron apps to bad anything-else apps is going to be interesting or informative to anyone.
Sure, but the least you can do is compare averages. IME, the average Electron app is a memory hogging piece of battery exhausting garbage. Cherrypicking outliers to make the case is, to say the least, misleading.
It's neither cherrypicking nor misleading. 'Compare averages' is your idea, I honestly don't understand why that's interesting at all. Much more interesting (and sensible) - here's an app that represents the current state of 'peak Electron'. What's a 'peak Qt' app?
There are much better things to complain about in my pick of Electron apps. Here's one - VS Code is a highly specialized app from a field in which users are perfectly ok with highly non-native UI. Sublime, IntelliJ IDEA, NetBeans, Emacs, Eclipse, etc are all deeply non-native yet popular. So that's a bit unfair but hey, there are Qt-based dev tools out there as well. But again, I'd be happy with any example of a non-shitty (UI/UX-wise) Qt app.
There are much better things to complain about in my pick of Electron apps. Here's one - VS Code is a highly specialized app from a field in which users are perfectly ok with highly non-native UI. Sublime, IntelliJ IDEA, NetBeans, Emacs, Eclipse, etc are all deeply non-native yet popular. So that's a bit unfair but hey, there are Qt-based dev tools out there as well. But again, I'd be happy with any example of a non-shitty (UI/UX-wise) Qt app.
I'd be happy with any example of a non-shitty (UI/UX-wise) Qt app.
Maya (the high end 3D animation package) switched to Qt a few years ago.
Maya (the high end 3D animation package) switched to Qt a few years ago.
[deleted]
It's neither cherrypicking nor misleading. 'Compare averages' is your idea, I honestly don't understand why that's interesting at all. Much more interesting (and sensible) - here's an app that represents the current state of 'peak Electron'. What's a 'peak Qt' app?
Uh... the entire KDE Desktop Environment and surrounding ecosystem? Of those, KDevelop and Krita are both fully cross-platform.
I've listed many others in other comments.
Frankly, I think you're either choosing not to look, or moving the goalposts in order to rule out perfectly fine examples of native cross platform apps that aren't written in glorified web browser.
Uh... the entire KDE Desktop Environment and surrounding ecosystem? Of those, KDevelop and Krita are both fully cross-platform.
I've listed many others in other comments.
Frankly, I think you're either choosing not to look, or moving the goalposts in order to rule out perfectly fine examples of native cross platform apps that aren't written in glorified web browser.
We were talking about cross-platform apps so 'The entire KDE Desktop' doesn't count. All of the ones you listed are awful on OS X (and VLC's main UI is, I think, native) and don't seem to have any UI advantage over Electron apps. Which answers the question raised upthread - 'why don't people writing x-platform apps just use Qt'. One good reason is because it doesn't appear to produce better apps.
I know at companies I've worked for the split-license for Qt caused concern. This was pre-Electron (although I seriously doubt it would have been in contention). They went with another toolkit and a few years, after conferring with their lawyers or whatever, decided to move everything to Qt.
> We were talking about cross-platform apps so 'The entire KDE Desktop' doesn't count.
The entire KDE desktop runs on Windows. So it does count.
> One good reason is because it doesn't appear to produce better apps.
So an order of magnitude lower RAM and CPU usage doesn't count as "better"?
The entire KDE desktop runs on Windows. So it does count.
> One good reason is because it doesn't appear to produce better apps.
So an order of magnitude lower RAM and CPU usage doesn't count as "better"?
> So an order of magnitude lower RAM and CPU usage doesn't count as "better"?
Depends on the absolute values. In and of itself, it's not better if it doesn't noticeably improve ux. Applications are for users. They're not vying for space in a VM, so up to the point where they don't impact a normal user's workload on a representative machine: no it doesn't count for much.
Depends on the absolute values. In and of itself, it's not better if it doesn't noticeably improve ux. Applications are for users. They're not vying for space in a VM, so up to the point where they don't impact a normal user's workload on a representative machine: no it doesn't count for much.
I can't think of any acceptable Qt or Xamarin apps period, which is the real point of comparison here. The fact that VS Code is acceptable is truly surprising and represents a victory not only for Electron but the whole concept of cross-platform apps.
Then you're not thinking very hard. I'm too bored of this discussion to look at Xamarin, but for Qt, just looking at the Wikipedia page and cross-referencing with my experience with them, we have: VLC, Stellarium, VirtualBox, Telegram, Google Earth, LyX...
So, a majority of apps that set up a window then use their own internal renderer? Except Telegram and Lyx.
Fair enough, but this is hardly representative of the sort of things Electron does well. What's more, Lyx and Telegram aren't exactly famous for being accessible apps.
It's very difficult for me to envision why someone wants to work 4x harder on an app to cut the memory footprint from 2g-4g (much of which is actually shared with the browser you've probably got running anyways) to 1g.
People demand respect for less able hardware, but I use Electron on 8 year old computers without complaint. And all I can hear in this is the emacs vs vi stuff again.
Fair enough, but this is hardly representative of the sort of things Electron does well. What's more, Lyx and Telegram aren't exactly famous for being accessible apps.
It's very difficult for me to envision why someone wants to work 4x harder on an app to cut the memory footprint from 2g-4g (much of which is actually shared with the browser you've probably got running anyways) to 1g.
People demand respect for less able hardware, but I use Electron on 8 year old computers without complaint. And all I can hear in this is the emacs vs vi stuff again.
From those two I use VLC and VirtualBox. And while they work fine, I don't think they are great showcases for good GUIs. E.g. the VLC guis scaling is quite bad on my 4k screen. The same applies also for the version QT creator which I have installed (but that's not a very recent one, maybe the current one is better).
To be fair: I have seen various good QT apps, but most of them were not standard desktop apps. Instead they used fullscreen QML for highly custom user interfaces. That seemed to work well, but I think JS/HTML5 would do the same.
To be fair: I have seen various good QT apps, but most of them were not standard desktop apps. Instead they used fullscreen QML for highly custom user interfaces. That seemed to work well, but I think JS/HTML5 would do the same.
The scaling issue is more a problem of Windows than it is Qt, per se. And, good news, they're fixing it in the next major version!
That seemed to work well, but I think JS/HTML5 would do the same.
With the same memory footprint and CPU utilization? I highly doubt that...
That seemed to work well, but I think JS/HTML5 would do the same.
With the same memory footprint and CPU utilization? I highly doubt that...
Sure, but the trade-off is a lot more developer time. "Twice as long" seems generous, and certainly Electron makes accessibility easier.
I work in visual effects. Large companies (Disney, DreamWorks, ILM, Weta) are all Linux based, while small shops are Windows or Mac. So much of the software is cross platform in order to be relevant (usually Linux first). Maya, Nuke, Houdini, rv, and a bunch more. All of the smaller tools and utilities in open source projects are either Qt or PyQt. Maya, Nuke, and Houdini all had their own in-house toolkits, but migrated to Qt. They all have fairly custom UI requirements, require high performance, and need high end things like accurate color and GPU acceleration.
It's not the same type of app as Spotify or Slack, but is comparable to VSCode.
It's not the same type of app as Spotify or Slack, but is comparable to VSCode.
MonoDevelop aka Xamarin Studio aka Visual Studio for Mac
It's a powerful and memory-efficient IDE written in C#/Mono.
It's a powerful and memory-efficient IDE written in C#/Mono.
Sublime text?
Sorry, but the alternative to using Electron isn't JavaFX or Qt or Xamarin. It's nothing. People weren't writing cross-platform desktop apps before Electron. For that reason alone, Electron is great.
>People weren't writing cross-platform desktop apps before Electron.
Perhaps you weren't there, but they did. By the tons.
Heck, take something like Sublime Text, that pisses on Atom on all performance metrics, and is coded by a SINGLE person for 3 platforms.
Perhaps you weren't there, but they did. By the tons.
Heck, take something like Sublime Text, that pisses on Atom on all performance metrics, and is coded by a SINGLE person for 3 platforms.
To be fair, you can't run Sublime Text as a web app which makes sense for it. But something like a note taking app might want to be available as both a web app and a desktop app. Slack does something like this. In practice, though, very little code written for Electron will run in a browser.
>But something like a note taking app might want to be available as both a web app and a desktop app.
Access as a web app is much less needed in the era were everyone has not just a computer, but also their smartphone with them at all times -- it can just be a regular native mobile app.
But even if access as a web app is needed, the web version shouldn't be imposed on all other platforms just because it is the lowest/easiest common denominator for the devs.
Access as a web app is much less needed in the era were everyone has not just a computer, but also their smartphone with them at all times -- it can just be a regular native mobile app.
But even if access as a web app is needed, the web version shouldn't be imposed on all other platforms just because it is the lowest/easiest common denominator for the devs.
A lot of us just want to re-use our redux/vuex files. React native and nativescript do this for mobile (much closer to native than Cordova). I haven't seen an equivalent solution for desktop. Most of the options are "stuck with one platform" or "write and maintain a second/third/fourth copy of your software"
> In practice, though, very little code
> written for Electron will run in a browser.
I think many things could run in a browser. All GUI, whole visual layer could run in a browser (maybe except system menus, but they could be recreated in HTML/CSS). All business logic also could run in browser.
Of course there are some other things won't run in browser, for example file system access (but this could be emulated by some kind of virtual file system). Or native NodeJS extensions (if application uses these). Or some system calls.
But these parts (not-compatible with browser) should be isolated from the rest of application and either ported somehow into the browser or just disabled in the browser version.
What I see is something else - projects are written in sloppy way, with bad architecture, where there is no respect for Single Responsibility Principle whatsoever. They are just written in non-portable way (it's matter of architecture rather than technology).
> written for Electron will run in a browser.
I think many things could run in a browser. All GUI, whole visual layer could run in a browser (maybe except system menus, but they could be recreated in HTML/CSS). All business logic also could run in browser.
Of course there are some other things won't run in browser, for example file system access (but this could be emulated by some kind of virtual file system). Or native NodeJS extensions (if application uses these). Or some system calls.
But these parts (not-compatible with browser) should be isolated from the rest of application and either ported somehow into the browser or just disabled in the browser version.
What I see is something else - projects are written in sloppy way, with bad architecture, where there is no respect for Single Responsibility Principle whatsoever. They are just written in non-portable way (it's matter of architecture rather than technology).
People weren't writing cross-platform desktop apps before Electron.
Oh. Wow.
Are we really at the point where people are rewriting history that profoundly in order to justify Electron?
Let's see... on my computer, right now, I have installed the following cross-platform desktop applications, none of which are built with Electron:
1. Chrome itself
2. Firefox
3. IntelliJ
4. Vim
5. LibreOffice
6. LyX
7. Gimp
8. VLC
9. Steam
10. VirtualBox
11. Ardour
And that's just off the top of my head.
Oh. Wow.
Are we really at the point where people are rewriting history that profoundly in order to justify Electron?
Let's see... on my computer, right now, I have installed the following cross-platform desktop applications, none of which are built with Electron:
1. Chrome itself
2. Firefox
3. IntelliJ
4. Vim
5. LibreOffice
6. LyX
7. Gimp
8. VLC
9. Steam
10. VirtualBox
11. Ardour
And that's just off the top of my head.
To be fair, Steam uses a custom version of Chromium Embedded Framework, which is basically morally equivalent to Electron insofar as embedding a browser to implement cross platform guis.
I don't believe that's correct.
Steam is built using a custom GUI framework:
https://developer.valvesoftware.com/wiki/VGUI_Documentation
Yes, they embed Chromium for rendering web content, but the application itself is not rendered by Chromium.
Steam is built using a custom GUI framework:
https://developer.valvesoftware.com/wiki/VGUI_Documentation
Yes, they embed Chromium for rendering web content, but the application itself is not rendered by Chromium.
[deleted]
So what's your answer to Visual Studio Code then?
I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?
I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?
> So what's your answer to Visual Studio Code then?
Sublime Text, Kate, Notepad++ if you're looking for the same low learning curve or Vim/Emacs if you have experience or are willing to learn either.
Two days ago I finally snapped when I was refactoring a codebase that required me to have 4 VS Code windows open.
Together with my regular browser I was eating 12 GB of RAM and I had no VMs open as I often do. The system ran slow as dirt despite having an FX-8320 (not a new chip, but it's no slouch and it's still an 8-core), an SSD and 4 more GB of RAM to spare.
That's just downright unacceptable.
> I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?
Excuse my french, but come the fuck on. I was 11 years old when I grabbed a copy of Visual Basic 6 because "I wanted to be a 1337 haxxor" and was able to drag and drop buttons and text inputs into an empty dotted window, bang them together a bit, copy paste some code from forums and have them working to some extent with no programming knowledge.
You're treating JavaScript programmers as if they're mentally deficient just because many of them are new to the industry and don't know tools that aren't fashionable. If they grabbed Qt Creator and QML docs they would be producing lightweight apps in no time.
Sublime Text, Kate, Notepad++ if you're looking for the same low learning curve or Vim/Emacs if you have experience or are willing to learn either.
Two days ago I finally snapped when I was refactoring a codebase that required me to have 4 VS Code windows open.
Together with my regular browser I was eating 12 GB of RAM and I had no VMs open as I often do. The system ran slow as dirt despite having an FX-8320 (not a new chip, but it's no slouch and it's still an 8-core), an SSD and 4 more GB of RAM to spare.
That's just downright unacceptable.
> I see Electron as opening up desktop development to developers who previously wouldn't have the been able to do it. Should we gatekeep just because developers don't have the resources to do a proper native app?
Excuse my french, but come the fuck on. I was 11 years old when I grabbed a copy of Visual Basic 6 because "I wanted to be a 1337 haxxor" and was able to drag and drop buttons and text inputs into an empty dotted window, bang them together a bit, copy paste some code from forums and have them working to some extent with no programming knowledge.
You're treating JavaScript programmers as if they're mentally deficient just because many of them are new to the industry and don't know tools that aren't fashionable. If they grabbed Qt Creator and QML docs they would be producing lightweight apps in no time.
And yet… they don't.
You could continue arguing against the mounting evidence that Qt apps simply don't perform as well in the marketplace as Electron apps seem to be doing, or you could accept that perhaps one of your assumptions is wrong.
Having used a few Electron apps on macOS, I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren, the software version of the uncanny valley. Even VS Code, the first editor I've actually liked since the original TextMate, somehow doesn't feel out of place (despite being themed uniquely).
There was a list posted earlier of popular cross-platform Qt apps, and most of them (VLC, Google Earth, VirtualBox) share a common theme: they're effectively a thin UI around mostly non-Qt content. I'd be surprised if more than 5% of VLC's use isn't double-clicking a video, watching it, and closing the window (perhaps with some scrubbing around the content). Most of a user's interaction with VirtualBox is with the operating system inside of it. And Google Earth (isn't that dead?) has little toolkit-based UI inside of it, with most of the space reserved for flying around the planet's surface.
Don't you think it's telling that the most popular cross-platform Qt apps are the ones with the least amount of Qt UI?
On the other hand, popular Electron apps like VS Code and Slack are almost entirely about interacting with the UI itself. In the brief window of time Electron has been out, it's resulted in more popular cross-platform apps of this vein than Qt has in the 25+ years of its existence.
"Are I out of touch? No, it's the other developers who are wrong!"
You could continue arguing against the mounting evidence that Qt apps simply don't perform as well in the marketplace as Electron apps seem to be doing, or you could accept that perhaps one of your assumptions is wrong.
Having used a few Electron apps on macOS, I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren, the software version of the uncanny valley. Even VS Code, the first editor I've actually liked since the original TextMate, somehow doesn't feel out of place (despite being themed uniquely).
There was a list posted earlier of popular cross-platform Qt apps, and most of them (VLC, Google Earth, VirtualBox) share a common theme: they're effectively a thin UI around mostly non-Qt content. I'd be surprised if more than 5% of VLC's use isn't double-clicking a video, watching it, and closing the window (perhaps with some scrubbing around the content). Most of a user's interaction with VirtualBox is with the operating system inside of it. And Google Earth (isn't that dead?) has little toolkit-based UI inside of it, with most of the space reserved for flying around the planet's surface.
Don't you think it's telling that the most popular cross-platform Qt apps are the ones with the least amount of Qt UI?
On the other hand, popular Electron apps like VS Code and Slack are almost entirely about interacting with the UI itself. In the brief window of time Electron has been out, it's resulted in more popular cross-platform apps of this vein than Qt has in the 25+ years of its existence.
"Are I out of touch? No, it's the other developers who are wrong!"
>You could continue arguing against the mounting evidence that Qt apps...
Let me stop you right there since from then on you're thinking with an incorrect assumption. I'm not talking about Qt Widgets; I'm talking about QML.
And I've already hinted at why we aren't seeing an explosion of QML apps: Electron is front-end development with desktop APIs. This is something JS developers already do. On top of that, it's currently fashionable. QML isn't.
It's easy to see why: QML has existed for a while, took some time to mature and it's not as good for making native looking apps as other traditional toolkits, therefore it never enjoyed widespread popularity among desktop developers outside of KDE and embedded development (an area where you need performance but don't have an an established HIG to follow).
Therefore, it's normal for webdevs to not have even heard of QML or to confuse it with regular Qt widgets.
> "Are I out of touch? No, it's the other developers who are wrong!"
So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa.
> I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren
I hope you can see why I believe misinformation is the problem behind this epidemic. QML offers the exact same approach to theming, giving you simple primitives to create widgets of your own design without the need for an unholy mess of HTML, CSS and a JavaScript framework; just a tiny bit of QML in a file and you have your own component rendered on a 3D accelerated scene graph with the option to add JavaScript for complex logic.
And I actually happen to have an example to back my words up.
Here: https://github.com/grigio/borderless-camera is an Electron app the author posted on a programming subreddit a while ago. Take a look at the source code, build toolchain and so on; the usual.
I made this as a response to the criticism he got about the high resource consumption for a seemingly trivial app: https://gitlab.com/mixedCase/qml-borderless-camera I invite you to take a look at the app.qml file. That is the entire source code.
Let me stop you right there since from then on you're thinking with an incorrect assumption. I'm not talking about Qt Widgets; I'm talking about QML.
And I've already hinted at why we aren't seeing an explosion of QML apps: Electron is front-end development with desktop APIs. This is something JS developers already do. On top of that, it's currently fashionable. QML isn't.
It's easy to see why: QML has existed for a while, took some time to mature and it's not as good for making native looking apps as other traditional toolkits, therefore it never enjoyed widespread popularity among desktop developers outside of KDE and embedded development (an area where you need performance but don't have an an established HIG to follow).
Therefore, it's normal for webdevs to not have even heard of QML or to confuse it with regular Qt widgets.
> "Are I out of touch? No, it's the other developers who are wrong!"
So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa.
> I'll offer a (mostly poorly-informed) opinion: Electron is the first cross-platform toolkit I've seen that has resulted in apps that don't feel out-of-place like their other cross-platform brethren
I hope you can see why I believe misinformation is the problem behind this epidemic. QML offers the exact same approach to theming, giving you simple primitives to create widgets of your own design without the need for an unholy mess of HTML, CSS and a JavaScript framework; just a tiny bit of QML in a file and you have your own component rendered on a 3D accelerated scene graph with the option to add JavaScript for complex logic.
And I actually happen to have an example to back my words up.
Here: https://github.com/grigio/borderless-camera is an Electron app the author posted on a programming subreddit a while ago. Take a look at the source code, build toolchain and so on; the usual.
I made this as a response to the criticism he got about the high resource consumption for a seemingly trivial app: https://gitlab.com/mixedCase/qml-borderless-camera I invite you to take a look at the app.qml file. That is the entire source code.
> QML... is not as good for making native looking apps as other traditional toolkits.
In disagreeing with me, somehow you've essentially re-argued my own thesis.
It's not just about looking as good (although that's certainly a component), it's also about acting like native apps. Electron apps for whatever reason, in my experience, don't have this problem. Slack feels like a native app. VS Code feels like a native app.
> So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa.
I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point.
> And I actually happen to have an example to back my words up.
It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface.
Qt apps haven't taken off because, while they may be easier for developers to build, they are worse for users to use (by a metric I'm leaving poorly-defined for the simple reason that I lack a good definition). Easier to develop but worse for users is not a good selling proposition.
In disagreeing with me, somehow you've essentially re-argued my own thesis.
It's not just about looking as good (although that's certainly a component), it's also about acting like native apps. Electron apps for whatever reason, in my experience, don't have this problem. Slack feels like a native app. VS Code feels like a native app.
> So before this post you didn't even know what QML is but already took the moral high ground to disregard me as grumpy grandpa.
I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point.
> And I actually happen to have an example to back my words up.
It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface.
Qt apps haven't taken off because, while they may be easier for developers to build, they are worse for users to use (by a metric I'm leaving poorly-defined for the simple reason that I lack a good definition). Easier to develop but worse for users is not a good selling proposition.
> it's also about acting like native apps. Slack feels like a native app. VS Code feels like a native app.
I'm not sure if you're arguing as if this is powered by some sort of black box powered magic no one could understand?
Electron is just a website, the Node APIs and a couple of facilities from Gtk, like menus. You have access to these things or equivalents in QML. You would know this if you had bothered to learn what it actually is.
> I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point.
You're literally searching for a couple of terms in Google half-guessing what some of the words mean and thinking you now understand Qt.
Qt is a big set of libraries.
Qt widgets is a traditional widget toolkit that powers things like VLC, Google Earth and VirtualBox. It's software-rendered and exclusively programmed through C++. It's a subset of Qt.
QtQuick is a different subset, that is powered by a 3D-accelerated scenegraph, can be programmed from QML, JavaScript and C++ and has primitives both for native-like widgets (QtQuick Controls 1) and simpler, more performant primitives (QtQuick Controls 2) that allow you to do everything you can do in a website with the DOM and CSS.
You can mix and match subsets, which is part of the beauty of Qt, but each of those have completely different purposes.
> It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface.
Fine. Have a VS Code prototype just for you, made in under an hour:
https://i.imgur.com/RPr6VMS.png
Some of it is functional, like tabs and menu. Sidebar and file tree is mere decoration waiting to be connected to logic. But there's your magical "native feel" interface in QML.
Ah, and if you were to actually complete the prototype, you could probably rip off the rich text editing component from the Kate text editor (written in Qt widgets) and still be able to use it from QtQuick. Meaning you get syntax coloring, auto complete and many other things for free, if you wanted to.
Here's the code: https://gitlab.com/mixedCase/poc-qml-vscode
If you have the dependencies installed, you build it with qmake -o Makefile qml-vscode.pro && make
Enjoy.
I'm not sure if you're arguing as if this is powered by some sort of black box powered magic no one could understand?
Electron is just a website, the Node APIs and a couple of facilities from Gtk, like menus. You have access to these things or equivalents in QML. You would know this if you had bothered to learn what it actually is.
> I spoke to Qt, and QML is literally the "Qt Modeling Language". It renders elements using Qt Quick. I'm not entirely sure how switching the mechanism for defining your Qt interface from code to a markup language invalidates my point.
You're literally searching for a couple of terms in Google half-guessing what some of the words mean and thinking you now understand Qt.
Qt is a big set of libraries.
Qt widgets is a traditional widget toolkit that powers things like VLC, Google Earth and VirtualBox. It's software-rendered and exclusively programmed through C++. It's a subset of Qt.
QtQuick is a different subset, that is powered by a 3D-accelerated scenegraph, can be programmed from QML, JavaScript and C++ and has primitives both for native-like widgets (QtQuick Controls 1) and simpler, more performant primitives (QtQuick Controls 2) that allow you to do everything you can do in a website with the DOM and CSS.
You can mix and match subsets, which is part of the beauty of Qt, but each of those have completely different purposes.
> It's unbelievable to me that you responded to my post about how the most popular Qt apps are the one with the least Qt interface, with an example of a Qt app you wrote (using QML) that literally has no interface.
Fine. Have a VS Code prototype just for you, made in under an hour:
https://i.imgur.com/RPr6VMS.png
Some of it is functional, like tabs and menu. Sidebar and file tree is mere decoration waiting to be connected to logic. But there's your magical "native feel" interface in QML.
Ah, and if you were to actually complete the prototype, you could probably rip off the rich text editing component from the Kate text editor (written in Qt widgets) and still be able to use it from QtQuick. Meaning you get syntax coloring, auto complete and many other things for free, if you wanted to.
Here's the code: https://gitlab.com/mixedCase/poc-qml-vscode
If you have the dependencies installed, you build it with qmake -o Makefile qml-vscode.pro && make
Enjoy.
How does Electron open up desktop development to developers? If they were already developers, how were they unable to use any of the many free (or inexpensive) development environments out there?
For macOS, XCode has been free for as long as I've been using Macs (2006). For Linux, it's essentially all free. For Windows, yeah, it used to be expensive but setting aside full-fledged Visual Studio, there were lots of options that were either free or cheap.
Just because we have a huge influx of developers who only know or want to use JavaScript doesn't mean my laptop battery, memory, and CPU need to cry every time I open up a note taking app.
For macOS, XCode has been free for as long as I've been using Macs (2006). For Linux, it's essentially all free. For Windows, yeah, it used to be expensive but setting aside full-fledged Visual Studio, there were lots of options that were either free or cheap.
Just because we have a huge influx of developers who only know or want to use JavaScript doesn't mean my laptop battery, memory, and CPU need to cry every time I open up a note taking app.
The answer might surprise you: I work for Microsoft and use Code daily.
I like it and appreciate the relentless tweaking the team has been doing to wrestle down the Electron bloat (hence one of the parentheses above), but it's not immune to it -- on my desktop Mac (a 7-year-old mid-2010 Mac mini with 8GB of RAM) I routinely have to kill it and fire up TextMate or vim instead.
On a 4GB Surface Pro 4 (which is closer to the average I mentioned) I can usually only run Edge, Code, Chrome and the native mail app before things start slowing down -- and by that I mean that every individual app is fast a few seconds after I switch to it, but swapping has begun in earnest and moving to and fro between docs, code and testing lags enough for me to start getting frustrated -- at which point I usually fire up vim inside the Linux subsystem.
As an aside, I don't have Slack (or any other Electron app but Code) installed anywhere -- I just use the most lightweight browser on any platform to get at that kind of thing.
I like it and appreciate the relentless tweaking the team has been doing to wrestle down the Electron bloat (hence one of the parentheses above), but it's not immune to it -- on my desktop Mac (a 7-year-old mid-2010 Mac mini with 8GB of RAM) I routinely have to kill it and fire up TextMate or vim instead.
On a 4GB Surface Pro 4 (which is closer to the average I mentioned) I can usually only run Edge, Code, Chrome and the native mail app before things start slowing down -- and by that I mean that every individual app is fast a few seconds after I switch to it, but swapping has begun in earnest and moving to and fro between docs, code and testing lags enough for me to start getting frustrated -- at which point I usually fire up vim inside the Linux subsystem.
As an aside, I don't have Slack (or any other Electron app but Code) installed anywhere -- I just use the most lightweight browser on any platform to get at that kind of thing.
Visual Studio Code is not written by "developers who previously wouldn't have the been able to do it" but by highly expert developers at Microsoft, paid full time for that.
Amateurs can and do write plugins for it of course, mainly because JS is easy and popular and with huge already existing npm libs to leverage.
But take something like Sublime Text, coded by a single person, multiplatform, with tons of plugins too (though less, since it depends on Python), and with very fast performance.
An ST that had a few more hands, and a few more exposed UI controls for plugins would absolutely trump VSCode in all aspects -- especially if it embedded V8 for JS plugins to work there too (not Chrome/Blink/Electron: just the JS engine like it does with Python).
Amateurs can and do write plugins for it of course, mainly because JS is easy and popular and with huge already existing npm libs to leverage.
But take something like Sublime Text, coded by a single person, multiplatform, with tons of plugins too (though less, since it depends on Python), and with very fast performance.
An ST that had a few more hands, and a few more exposed UI controls for plugins would absolutely trump VSCode in all aspects -- especially if it embedded V8 for JS plugins to work there too (not Chrome/Blink/Electron: just the JS engine like it does with Python).
What about desktop developers who know better to spend months developing something that can be built in weeks to solve a problem, and then determine if further action is needed?
Its understandable if native developers will lean towards advocating for native apps, and non-native app developers don't.
There's lots of folks however, who can comfortably do both and may believe value is just not in performance up front, but solving problems that add and create value.
Its understandable if native developers will lean towards advocating for native apps, and non-native app developers don't.
There's lots of folks however, who can comfortably do both and may believe value is just not in performance up front, but solving problems that add and create value.
Agreed. That's why I developed a lightweight native client for Slack, Skype and others:
https://eul.im
It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.
https://eul.im
It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.
it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else,
A Tcl/Tk app packaged with StarKit would be better and consume literally one-tenth of the resource, and quite possibly one-hundredth.
A Tcl/Tk app packaged with StarKit would be better and consume literally one-tenth of the resource, and quite possibly one-hundredth.
To make a good case with TK is necessary to have something alike Bootstrap or anything that look good.
I will love to have a good Widget for multiplatform (and hopefully including iOS) but most toolkits have terrible looks. That alone is a turn-off.
I will love to have a good Widget for multiplatform (and hopefully including iOS) but most toolkits have terrible looks. That alone is a turn-off.
I know it's a bit subjective, but I find default-skinned TK apps to be much better looking than the average electron app.
[edit]
Here's a commercial application with a Tk gui that shows cross-platform screenshots:
https://installbuilder.bitrock.com/
[edit]
Here's a commercial application with a Tk gui that shows cross-platform screenshots:
https://installbuilder.bitrock.com/
I looked at the screenshots. That looks just like every piece of software made in the 90s before UI design became a thing people paid attention to.
I'm pretty sure this is making the opposite case you intended.
I'm pretty sure this is making the opposite case you intended.
But the TK website not show it. Is very ugly!
This is a important point. Maybe TCL/TK is amazing but need better press to show of.
Is TK available to iOS/Android? How crazy a "TK React Native" could be?
I ask because I have a potential project where cross-platform is important and wish a good toolkit to use.
This is a important point. Maybe TCL/TK is amazing but need better press to show of.
Is TK available to iOS/Android? How crazy a "TK React Native" could be?
I ask because I have a potential project where cross-platform is important and wish a good toolkit to use.
Sadly it's not been ported to iOS that I'm aware of, which makes it a non-starter if you care about mobile.
Actually, I've been teaching my kids to write simple Tkinter apps. :)
I think we too easily conflate Electron and apps based on Electron. If you take the Electron demo app, you won't notice it. It has no impact on your machine whatsoever. Plenty of Electron based apps though have abysmal performance and a negative impact on battery life etc. I've also come across a few that behave like proper citizens. A lot of what makes people frustrated with Electron based apps isn't actually caused by Electron, but what people have layered on top of it.
I think it was with Slack recently that someone noticed they actually ship the dev build of their JS code. Which would explain a thing or two about its performance and resource usage.
I think it was with Slack recently that someone noticed they actually ship the dev build of their JS code. Which would explain a thing or two about its performance and resource usage.
This. Atom kills my CPU fan, but VSCode is pretty quiet.
I also noticed that Slack was significantly more performant when I went from being on 5 different Slack teams to just one. Which suggests that there might be something related to how Slack handles background chat updates.
I also noticed that Slack was significantly more performant when I went from being on 5 different Slack teams to just one. Which suggests that there might be something related to how Slack handles background chat updates.
I never understood why to run Slack as desktop app if Slack can be run in a browser with the same GUI and features. Am I missing something?
Agreed. Developers make the mess in their architectural decisions, not so much the tooling.
> Electron’s dream world would be one where every computer user had a luxurious amount of ram. But I think this world is fast approaching. Do we wait till then to begin taking advantage of a plentiful world, or do we start planning now?
While it's great to imagine this future world where everyone is running supercomputers, you ignore the overwhelming majority of potential users who aren't running "a 2016 MacBook with 16GB ram". For those not at the cutting edge, many Electron apps are painful to use.
To put it differently, not everyone replaces their computer every year. It may take a long time before everyone "catches up"
While it's great to imagine this future world where everyone is running supercomputers, you ignore the overwhelming majority of potential users who aren't running "a 2016 MacBook with 16GB ram". For those not at the cutting edge, many Electron apps are painful to use.
To put it differently, not everyone replaces their computer every year. It may take a long time before everyone "catches up"
Yes, and they might be running "a 2011 MacBook with 4GM ram", like me :) I haven't had a compelling reason to upgrade, but apps like slack and atom are really trying to force it. Fortunately there are still apps that care about memory and performance (thank you, Sublime).
Not to mention the gravity-like tendency for apps to grow in memory requirements as machines grow in memory. It's disingenuous to pretend Slack will be snappy on a 16GB machine by the time everyone has it. Microsoft has run out the clock on that particular fallacy.
I have a 2016 16gb mbp and I cannot run two Ubuntu vms, chrome and Slack in 4 teams all at the same time. It is slow and even opens the OOM killer from time to time. And you can forget linking a large project when Slack is open, even with gold.
8 GB seems to be the minimum norm, and I think the main reason I have 16 is to keep an unreasonable amount of tabs open, because it's 2017.
The entire defense/post boils down to this line:
"... I ought to be more concerned with where the trend in memory is going rather than where it has been."
The problem with this line of argument is that it never ends. Developers who accept this line of argument are always aiming five years down the road, and thus always delivering a poor or substandard experience to their current users.
Your future users are not real, and if you're always targeting future users you're never targeting real people.
"... I ought to be more concerned with where the trend in memory is going rather than where it has been."
The problem with this line of argument is that it never ends. Developers who accept this line of argument are always aiming five years down the road, and thus always delivering a poor or substandard experience to their current users.
Your future users are not real, and if you're always targeting future users you're never targeting real people.
It's kind of like "You go to war with the army you have"- I mean, your code runs on computers people have, not the ones you wish they had.
But "the army you have" could also be the dev team you have..
It's usually easier to employ someone than to give each of your costumers a new computer though.
Sure, but my point is that if you just don't have the resources to develop natively, Electron may allow you to "go to war" when you otherwise couldn't.
If the dev team you have is competent enough to write JavaScript, then they can spend a couple of afternoons playing around in QML.
Ahhhhh yes. When people post claims about it's terrible performance they're concerned about how the computer feels.
/s
No. When it comes down to it. Electron hogs and drains a user's laptop battery, which in turn affects their user experience. How hard is that to understand?
Not everyone has a Macbook with decent battery life. Some people don't like Macs, don't like Apple, or simply can't afford one.
If you program with a concern for perform and battery life, it'll run well on a Mac as well as an old computer.
If you code lazily with Electron, some people will notice: a drop in battery life, and a slowing down of their computer's responsiveness.
It's pretty simple really. Code for the lowest common denominator of your target audience.
/s
No. When it comes down to it. Electron hogs and drains a user's laptop battery, which in turn affects their user experience. How hard is that to understand?
Not everyone has a Macbook with decent battery life. Some people don't like Macs, don't like Apple, or simply can't afford one.
If you program with a concern for perform and battery life, it'll run well on a Mac as well as an old computer.
If you code lazily with Electron, some people will notice: a drop in battery life, and a slowing down of their computer's responsiveness.
It's pretty simple really. Code for the lowest common denominator of your target audience.
> Not everyone has a Macbook with decent battery life.
I have a MacBook with a decent battery life until I run electron apps, then I have a MacBook with crappy battery life.
I have a MacBook with a decent battery life until I run electron apps, then I have a MacBook with crappy battery life.
> If you code lazily with Electron [...] It's pretty simple really.
It has nothing to do with 'laziness'. You ignored the entire 'The Business Case' section of the article.
It has nothing to do with 'laziness'. You ignored the entire 'The Business Case' section of the article.
I think OP was implying that you could code in a non-lazy way while using electron. For example, a lazily coded app would use too many frameworks (e.g. jQuery + jQuery UI + angular 1, 3 http clients, 3 underscore forks) and bad coding practices (many memory leaks and unnecessary duplication, no optimization attempts, team never learned the language, shipping dev builds with extra debug tools to production). Maybe electron isn't as bad as the bad apples draw it down to be. Personally, I'm still interested in something like react native for desktop.
react native for desktop
There is this: https://github.com/ptmt/react-native-macos
And also this (cross-plat React Native for Windows/iOS/Android): https://github.com/Microsoft/reactxp
> Personally, I'm still interested in something like react native for desktop.
Use JavaFX with JS running on the JVM?
Far smaller runtime, far better performance.
Use JavaFX with JS running on the JVM?
Far smaller runtime, far better performance.
OP was not implying that (see the rest of their comment).
The casual dismissal of the complaints from their customers really rubs me the wrong way. For sure, technical people know what Electron is and many have a bias against it. But the bias isn't irrational, it's driven by very real needs.
The author is right in that a non-technical person won't know what Electron is and when their computer becomes slow and hot or runs out of battery more quickly, they will not know where to lay the blame. They might think, as many members of my family love to tell me, that their computer battery is just "way too old" and "never lasts long", or that Windows "is so slow, is Linux any faster?"
I can run a couple of Electron applications and I do often. My office uses Slack, so I run that all the time. There are a couple others I need here and there and when they are all running at the same time, my laptop gets warm, the fan switches into high gear and soon I'm reaching for a power adapter. If I'm at an airport or traveling I can decide that I'm not running these applications and lengthen my battery life.
Electron is a compromise and I understand that. What I wouldn't be keen on is a situation where everything I do is an Electron app. Someone had a nice resource monitor that looked really neat, but it was an Electron application. I liked the look but I can't afford to add that application to my power/memory/CPU budget just 'cause it looks cool.
My point is this: I don't think it's a good idea to simply sweep away a segment of customer complaints because those customers happen to know what Electron is and notice the effects on their machines. As more Electron apps come to market, literally fewer will be able to share a customer's laptop or workstation. Atom and VS Code have already staked out some critical ground, their customers simply will not give them up. That leaves that much less room for other Electron apps and given the speed with which these apps are appearing, that space is going to be crowded and contentious.
The author is right in that a non-technical person won't know what Electron is and when their computer becomes slow and hot or runs out of battery more quickly, they will not know where to lay the blame. They might think, as many members of my family love to tell me, that their computer battery is just "way too old" and "never lasts long", or that Windows "is so slow, is Linux any faster?"
I can run a couple of Electron applications and I do often. My office uses Slack, so I run that all the time. There are a couple others I need here and there and when they are all running at the same time, my laptop gets warm, the fan switches into high gear and soon I'm reaching for a power adapter. If I'm at an airport or traveling I can decide that I'm not running these applications and lengthen my battery life.
Electron is a compromise and I understand that. What I wouldn't be keen on is a situation where everything I do is an Electron app. Someone had a nice resource monitor that looked really neat, but it was an Electron application. I liked the look but I can't afford to add that application to my power/memory/CPU budget just 'cause it looks cool.
My point is this: I don't think it's a good idea to simply sweep away a segment of customer complaints because those customers happen to know what Electron is and notice the effects on their machines. As more Electron apps come to market, literally fewer will be able to share a customer's laptop or workstation. Atom and VS Code have already staked out some critical ground, their customers simply will not give them up. That leaves that much less room for other Electron apps and given the speed with which these apps are appearing, that space is going to be crowded and contentious.
This would mean hiring a total of six experienced
developers. Let’s ignore the madenning tediousness of
having to make every minor change six times on six
different platforms, and focus instead on the costs.
With an average salary of $150k (probably more for the
hard to find like Mac developers), and ignoring the
massive cost of finding and hiring these developers,
that’s a total of $900,000 in development costs every
year.
And Mac developers hard to find? From what I keep reading here, MacBook Pros are the development machine to have. I can't imagine that it's so hard to find a Mac developer as this post suggests.
As a one-person team deploying on all these platforms,
even the most minor change will take at minimum three
development days, one for each codebase.
I'm glad Electron is letting you produce yet another note taking app. We need more of those. I hope it goes well. But please, please, please: I'm tired of my battery dying before I finish one cup of coffee at the coffee shop because of these inefficient apps.
Will someone, please, make Positron, the anti-Electron. It needs to be as portable as Electron (ideally), but based on a better runtime and language. Hell, Elixir is popular, let's go with that. You'll get great concurrency from the start, and hot code loading, and a decent language
> Hell, Elixir is popular, let's go with that. You'll get great concurrency from the start, and hot code loading, and a decent language
Just a comment on that: Different use-cases have different solutions. While the Erlang/Elixir model might work great for servers we gained the knowledge that a singlethreaded event-driven model seems to work best for user interfaces, because they are very stateful things. Multithreaded user-interface technologies (which is what Erlang would be - even though you have actors instead of threads) have afaik never worked out. Javascript however embraces the singlethreaded event-driven model up to the point where no shared-memory parallelism is possible - which works well for user interfaces. You don't even can't have the error anymore that some callbacks runs from another thread than expected (which is a typical error in GUI implementations in Java and C#).
And another remark: If the main goal of the change is to improve performance and resource usage, I also don't think Elixir would bring us forward. The erlang VM isn't a super-high performance environment, most likely electron/node/V8 is faster.
Just a comment on that: Different use-cases have different solutions. While the Erlang/Elixir model might work great for servers we gained the knowledge that a singlethreaded event-driven model seems to work best for user interfaces, because they are very stateful things. Multithreaded user-interface technologies (which is what Erlang would be - even though you have actors instead of threads) have afaik never worked out. Javascript however embraces the singlethreaded event-driven model up to the point where no shared-memory parallelism is possible - which works well for user interfaces. You don't even can't have the error anymore that some callbacks runs from another thread than expected (which is a typical error in GUI implementations in Java and C#).
And another remark: If the main goal of the change is to improve performance and resource usage, I also don't think Elixir would bring us forward. The erlang VM isn't a super-high performance environment, most likely electron/node/V8 is faster.
> Is your code so tightly coupled between logic and display that you haven't reduced the common features to, essentially, libraries at this point? Separation of concerns is not a novel concept.
No, I don't think many development companies have reduced the common features of codebases in 3 different languages to libraries yet.
No, I don't think many development companies have reduced the common features of codebases in 3 different languages to libraries yet.
Different platforms, not languages, per the posted article.
Of course it's hard to combine multiple languages into a single library set, but if you're dealing with multiple languages you're often already dealing with multiple applications anyways and not combining them into one singular application. Or you've figured out FFI and can deal with the multiple language issue that way, in which case, wait, you have libraries in other languages!
Of course it's hard to combine multiple languages into a single library set, but if you're dealing with multiple languages you're often already dealing with multiple applications anyways and not combining them into one singular application. Or you've figured out FFI and can deal with the multiple language issue that way, in which case, wait, you have libraries in other languages!
> Different platforms, not languages
The article mentions iOS development in Swift, Android development in Kotlin, and web development in Javascript.
> Or you've figured out FFI and can deal with the multiple language issue that way, in which case, wait, you have libraries in other languages!
As I said, not many development studios do that.
The article mentions iOS development in Swift, Android development in Kotlin, and web development in Javascript.
> Or you've figured out FFI and can deal with the multiple language issue that way, in which case, wait, you have libraries in other languages!
As I said, not many development studios do that.
Maybe https://github.com/Widdershin/positron
A real contender to Electron is going to have to ship a runtime or libraries that support the DOM and all of the APIs a browser like Chrome already ships along with a Javascript engine.
Maybe if we could break those all up into cross-platform shared libraries it could be done.
A real contender to Electron is going to have to ship a runtime or libraries that support the DOM and all of the APIs a browser like Chrome already ships along with a Javascript engine.
Maybe if we could break those all up into cross-platform shared libraries it could be done.
It only has to support the DOM and web technologies if we decide it needs to be compatible with web technologies. That's not actually needed for a cross-platform toolkit like this.
Regarding your link, it's for JavaScript -> Android Native.
I found another project that was an Electron-compatible effort on top of Gecko. I haven't done much other searching for things based on the name, honestly Positron just popped into my head while reading the original article so I used it here.
Regarding your link, it's for JavaScript -> Android Native.
I found another project that was an Electron-compatible effort on top of Gecko. I haven't done much other searching for things based on the name, honestly Positron just popped into my head while reading the original article so I used it here.
I think in order to compete with Electron and the developers who use it you will need to support the web technologies and APIs it has.
My question would be what's the alternative? Cross platform native apps rarely look as good, and would require entirely new code bases and different sets of developers. Sure electron sucks for users, but what's the business incentive to ship native apps other than to satisfy the minority of users who are even aware electron saps so many resources?
I think that for whomever is developing using electron in most cases the desktop versions of the apps wouldn't even exist if electron wasn't a thing. Also, just as a side note, electron apps are so _easy_ to develop. I don't know if any other platforms that target desktop are as simple, but I might just be out of the loop.
I think that for whomever is developing using electron in most cases the desktop versions of the apps wouldn't even exist if electron wasn't a thing. Also, just as a side note, electron apps are so _easy_ to develop. I don't know if any other platforms that target desktop are as simple, but I might just be out of the loop.
I'm a dreamer, I know it, but I still would like some kind of easy-to-use, developer friendly cross-platform UI toolkit. I used to do Swing development and, eventually, I learned to appreciate it. I understand why more people aren't jumping on the Swing train at this point but I have to say, the UI provided by Swing was less restrictive than the one provided by Electron.
Something in between would gain traction, I think, as Electron developer's run up against the hard edge of the kinds of UI Electron apps will allow.
Something in between would gain traction, I think, as Electron developer's run up against the hard edge of the kinds of UI Electron apps will allow.
> the UI provided by Swing was less restrictive than the one provided by Electron.
I really want to know the use cases you're talking about, because, to me, nothing could be further from the opposite.
I really want to know the use cases you're talking about, because, to me, nothing could be further from the opposite.
Warning: this video is old, lengthy, poorly paced and rather dull so feel free to click ahead. Still, it demonstrates a reasonably complicated Swing application that looks somewhat like a native Mac OS X application. The video was put together around 2003 so the look and feel is pretty dated. But the interface is fairly complicated and it does get feedback to the customer as soon as they get data out of range, etc.
https://youtu.be/r_lTGoTscos
https://youtu.be/r_lTGoTscos
Have you tried JavaFX? It is awesome to work with.
>Even more, anti-Electron posts are usually filled with charts and tables, along with screenshots of Activity Monitor with memory and CPU usage, outlining the evilness of the framework and why it must be stopped at all costs.
Yeah, all those pesky actual metrics...
Yeah, all those pesky actual metrics...
One question that seems to go unacknlowedged around rapid development tools like Electron is: Does it trivialize work that others think are much harder?
A lot of devs have studied native app development before doing some amount of web development, or in this case mobile html app development.
By learning the technical natures of native app development perhaps a little too soon, devs can miss out on the incredibly deep lessons you can learn from rapidly iterating and solving customer problems, because most customers do not care what something is built in.
There's no question Electron (like anything) could be better in some ways, however, for it's strengths in ease and ability to test a solution with the market (and discover it's more than good enough), are toolsets like Electron really that bad?
There is a path to justify native apps in my mind, a path that when possible to go through tools like react, react-native, electron to build working solutions, is valid, and fine. The need to optimize the speed and performance, say in a native application.
A lot of devs have studied native app development before doing some amount of web development, or in this case mobile html app development.
By learning the technical natures of native app development perhaps a little too soon, devs can miss out on the incredibly deep lessons you can learn from rapidly iterating and solving customer problems, because most customers do not care what something is built in.
There's no question Electron (like anything) could be better in some ways, however, for it's strengths in ease and ability to test a solution with the market (and discover it's more than good enough), are toolsets like Electron really that bad?
There is a path to justify native apps in my mind, a path that when possible to go through tools like react, react-native, electron to build working solutions, is valid, and fine. The need to optimize the speed and performance, say in a native application.
I don't mind writing the core of my software in platform specific C / C++ but I really like the idea of using web technologies for the UI + manipulating data in JSON for software IO (thus having a minimal JS engine). Does anyone know of a good middle ground ? I need CSS, VueJS and SVG. From what I read on the internet all I found is to link myself to the libchromiumcontent library
http://www.chromium.org/developers/content-module
http://www.chromium.org/developers/content-module
Yes, Chrome is a memory hog, but that's nothing new. The thing is, Chrome still runs just fine on the laptops-of-old with 4 gigs of memory. I've always just assumed that Chrome likes to use whatever memory it can find (which, for people with a lot of memory who only browse the web, is probably what they want). Acting like these Electron apps are un-useable without supercomputers is silly.
Actually, each Electron app ships with its own version of Chromium, and if you have multiple apps running you will have multiple instances of _approximately_ the same runtime, but zero shared resources across apps - no shared executable segments, no shared RAM, nothing.
So the bloat is actually bigger than running multiple instances of Chrome.
So the bloat is actually bigger than running multiple instances of Chrome.
Sounds like these apps are built with security and portability in mind ;). Seriously, though, this seems like an implementation issue that can/will improve over time. I can see the case where, yeah, if your users care about what your stack looks like and they refuse to use Electron apps, then sure, use something else (same goes if your users are laptop-heavy users with concerns about battery life). Some devs don't have those constraints and that's where Electron can fit in.
Electron apps need to take the route that Eclipse used and uses. Eclipse is a resource intensive Java application (though it feels much better these days than when I first used it 12 or so years ago). One runtime, with a mechanism for installing new "views" and such. Some applications were delivered as complete Eclipse runtime downloads plus the custom additions, but usually you could just download those custom parts directly into your Eclipse runtime.
That was a reasonably effective use of a common runtime and resource.
That was a reasonably effective use of a common runtime and resource.
What I find interesting is that in AAA game development performance is treated as a budget. You can write in a cross-platform engine but the tradeoff... is performance. It's always performance.
And yet we can port games to almost every platform conceivable when the code is appropriately architected.
Somehow this reality of programming eludes desktop and enterprise developers.
And yet we can port games to almost every platform conceivable when the code is appropriately architected.
Somehow this reality of programming eludes desktop and enterprise developers.
> when the code is appropriately architected
This has a substantial cost. Many games today make this tradeoff as soon as they can. Loading times is often the first victim, but in mobile you see it everywhere, even simple 2D puzzlers that can't hit 60 fps and still burn battery like crazy.
This has a substantial cost. Many games today make this tradeoff as soon as they can. Loading times is often the first victim, but in mobile you see it everywhere, even simple 2D puzzlers that can't hit 60 fps and still burn battery like crazy.
I really hope red-lang[1] or something like it takes off. We really need a quick (to develop), performant, aesthetically pleasing cross-platform GUI story. I hope Red accomplishes that.
[1] http://www.red-lang.org/
[1] http://www.red-lang.org/
In my view Electron is a total innovation killer. You can only use web controls, no custom controls. It's a nice way to start an app but you soon hit a wall because you can't do much performance tuning because you don't own most of the code.
I know there are no good multi platform UI kits but there but Electron seems a really bad direction from a technology point of view to me. Maybe we should give Java another go?
I know there are no good multi platform UI kits but there but Electron seems a really bad direction from a technology point of view to me. Maybe we should give Java another go?
If I have a Java GUI app running on my system, Electron apps become the least of my bloat concerns.
Why?
Let’s compare the electron-based Minecraft launcher with Minecraft itself.
The download is 400MB vs 11MB (+the 60MB JVM runtime)
The RAM usage is 300-600MB vs. 256MB
I mean, I don’t see how electron comes out ahead in this (and it only runs the damn launcher, not the actual game).
Java definitely is the least of your worries. And with JavaFX you can even use the web APIs for UI.
Let’s compare the electron-based Minecraft launcher with Minecraft itself.
The download is 400MB vs 11MB (+the 60MB JVM runtime)
The RAM usage is 300-600MB vs. 256MB
I mean, I don’t see how electron comes out ahead in this (and it only runs the damn launcher, not the actual game).
Java definitely is the least of your worries. And with JavaFX you can even use the web APIs for UI.
IS that true? Java is not great but Electron seems really bad.
My experience of using both is that Electron apps are far worse.
I saw a post called "Electron is flash for the desktop" a while back. I think that's basically true but the rationale is different.
Flash was a way to get true high performance dynamic content on the web before high performance JS, HTML5, and stuff like React. It was a way to be ahead of your time on the web.
Electron on the other hand is more of a fuck you revolt against the desktop.
It's 2017. Desktop computing paradigms are over 30 years old. Yet if I want to write a desktop app I still have to write the f'ing UI at least three times: Windows, Mac, and Linux/BSD. It's not just different APIs either. It's totally alien paradigms: different languages, different ways of specifying a UI, and different API paradigms. This would be defensible if these desktop UIs were substantially different, but they are not. The difference does not justify the divergence under the hood at all.
Qt is the other big cross platform competitor to Electron, but it's also a complete re-implementation of the UI, is almost as heavy, and is in some ways less modern and feature rich. The web has such a huge user base that it's always up to date and always has the latest stuff, while Qt languishes with its own weird way of doing things.
WxWidgets was my favorite past attempt in some ways. Its APIs are ugly and horribly outdated but at least it tried to use native widgets everywhere and look and feel native.
React Native is a neat idea but you still have to drag in a complete JavaScript runtime so you are nearing Electron levels of bloat there.
Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.
Flash was a way to get true high performance dynamic content on the web before high performance JS, HTML5, and stuff like React. It was a way to be ahead of your time on the web.
Electron on the other hand is more of a fuck you revolt against the desktop.
It's 2017. Desktop computing paradigms are over 30 years old. Yet if I want to write a desktop app I still have to write the f'ing UI at least three times: Windows, Mac, and Linux/BSD. It's not just different APIs either. It's totally alien paradigms: different languages, different ways of specifying a UI, and different API paradigms. This would be defensible if these desktop UIs were substantially different, but they are not. The difference does not justify the divergence under the hood at all.
Qt is the other big cross platform competitor to Electron, but it's also a complete re-implementation of the UI, is almost as heavy, and is in some ways less modern and feature rich. The web has such a huge user base that it's always up to date and always has the latest stuff, while Qt languishes with its own weird way of doing things.
WxWidgets was my favorite past attempt in some ways. Its APIs are ugly and horribly outdated but at least it tried to use native widgets everywhere and look and feel native.
React Native is a neat idea but you still have to drag in a complete JavaScript runtime so you are nearing Electron levels of bloat there.
Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.
Qt is absolutely not "almost as heavy" in memory or CPU time. Maybe in disk space.
It also allows customization at several abstraction levels, which is what makes it more flexible than most of the competition.
This is absolutely correct. It may be better in quantifiable end-user metrics to have different native desktop apps for every user. However, it is far worse in developer cost to write those apps in native frameworks. The trade-off being made is not native vs electron, it's electron vs nothing at all.
No, it's not electron vs. nothing. It's one good single-platform application vs. one terrible cross-platform application. If you don't have resources for developing on multiple platforms, it is OK to choose one.
> Yet if I want to write a desktop app I still have to write the f'ing UI at least three times: Windows, Mac, and Linux/BSD.
Vendors and developers do not have the same interests. Developers want to maximize the market for their skills. Vendors want to lock you in, and are perfectly happy to waste your time and harm your career to do it.
Vendors and developers do not have the same interests. Developers want to maximize the market for their skills. Vendors want to lock you in, and are perfectly happy to waste your time and harm your career to do it.
Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.
That modern WxWidgets library would be just Electron in everything but name (because you want people to use it, so you'll have to support what people already know, which is html+js) and people would abuse the abundance of resources on modern desktops just the same. Electron itself is not the problem. Awful usage of Electron is the problem. I would say Electron is the desktop equivalent of PHP. It lets people who don't know why signed left shift can invoke undefined behaviour and don't care if their code is indented with a mix of spaces and tabs, i.e. people who aren't the minutiae perfectionists that native APIs require them to be, to write dumb GUI apps in something that isn't tied to Microsoft's whims and has a learning curve reminiscent of a kiddie pool.
What we need is some better linters, profilers, &c integrated in development environments used to write Electron apps, to help and inform the authors of how to write the most performant GUI possible. People won't write GUI using VisualC 6 + MFC ever again, I see it as best to just meet them halfway.
What we need is some better linters, profilers, &c integrated in development environments used to write Electron apps, to help and inform the authors of how to write the most performant GUI possible. People won't write GUI using VisualC 6 + MFC ever again, I see it as best to just meet them halfway.
Our react native apps are around 10 - 15 mb in size once bundled, which is hardly bloated.
> But advanced development machines of today are the entry level computers of tomorrow.
I've been waiting for years for a cheap laptop with 4-8 GB RAM that's got a quad-core processor for development and light gaming. It seems those machines are always north of $600. If anybody has suggestions of what to do without going used I'd love to hear them.
I've been waiting for years for a cheap laptop with 4-8 GB RAM that's got a quad-core processor for development and light gaming. It seems those machines are always north of $600. If anybody has suggestions of what to do without going used I'd love to hear them.
I got a refurb Dell gaming laptop from Dell Outlet with 16GB of RAM, an i7 CPU, a 4k 15.6" touchscreen display, and an nVidia GT960M GPU for about $695; that was with a 20% or 25% off coupon, but those come up pretty regularly. It's a beast and plays games well. Surely, you can find something reasonable for under $600, with spec requirements as modest as the ones you've listed.
My Dell isn't a nice machine, by any means...it's a standard plastic job, but when I've bought higher end models in the past, they haven't lasted significantly longer than cheapo consumer models, so I just accept the cheap feel of the thing and save the $500+ that better builds cost.
It runs Linux very well today, though it didn't when I bought it, but that was due to video drivers, which would have been true of any device with a 4k display and the GT960M GPU.
And, on the subject of Electron, I started using Atom at the same time I got this new machine. It runs fine, alongside Firefox with a gazillion open tabs, Thunderbird with a hundred thousand emails in the inbox, and a Gnome terminal with a dozen or so tabs.
My Dell isn't a nice machine, by any means...it's a standard plastic job, but when I've bought higher end models in the past, they haven't lasted significantly longer than cheapo consumer models, so I just accept the cheap feel of the thing and save the $500+ that better builds cost.
It runs Linux very well today, though it didn't when I bought it, but that was due to video drivers, which would have been true of any device with a 4k display and the GT960M GPU.
And, on the subject of Electron, I started using Atom at the same time I got this new machine. It runs fine, alongside Firefox with a gazillion open tabs, Thunderbird with a hundred thousand emails in the inbox, and a Gnome terminal with a dozen or so tabs.
There are quite a few laptops meeting those specs on Amazon right now, and some of them don't look bad [1].
1: https://smile.amazon.com/s/ref=sr_nr_p_n_size_browse-bin_2?f...
1: https://smile.amazon.com/s/ref=sr_nr_p_n_size_browse-bin_2?f...
"The computer industry has been stuck on 8GB for what seems like far too long, but a 16GB standard reality is imminent, if not inevitable."
Uh... 4 GB is the prevailing standard for the average user PC.
Uh... 4 GB is the prevailing standard for the average user PC.
Having specialized in the web stack, it really pains me to see this fail. However, it is unreasonable and counterproductive to expect end user devices to continually increase in computing power and memory.
The future, for most users, is in smaller, cheaper, more deeply integrated devices, not in faster stronger devices. Just look at the smart watches of today, the AR kits of tomorrow, the joule-thief powered IoT devices that don't require a power connection. This is where we are headed, not towards epic gaming rigs for everyone.
I can only hope that in time, we will develop more efficient native implementations of the DOM, even if that means a major breaking change. IMO, the web layer is well suited to bridging the divide between vastly dissimilar hardware platforms, especially as the number of unique platforms explodes into a lush jungle of diversity and ubiquity.
The future, for most users, is in smaller, cheaper, more deeply integrated devices, not in faster stronger devices. Just look at the smart watches of today, the AR kits of tomorrow, the joule-thief powered IoT devices that don't require a power connection. This is where we are headed, not towards epic gaming rigs for everyone.
I can only hope that in time, we will develop more efficient native implementations of the DOM, even if that means a major breaking change. IMO, the web layer is well suited to bridging the divide between vastly dissimilar hardware platforms, especially as the number of unique platforms explodes into a lush jungle of diversity and ubiquity.
We're declaring Electron dead now?
Failing is not dying, it is just a painful phase of growth and change. At least, that's how I choose to view my own failures.
I don't use atom, but I don't understand why it needs to be defended or why people would attack it in the first place. If you don't like atom, like me, then don't use it. Is it deep down that you are really envying people using atom as their daily driver while you can't (do the same comfortably)?
After all, it is just a text editor, not like a hot technology that your boss will force down your throat, right?
After all, it is just a text editor, not like a hot technology that your boss will force down your throat, right?
I think atom is just a prevalent example of an election app. I for one dislike it and use sublime text instead, but not all electron based apps are as replaceable. Slack, another electron based app, is an example. It is something that bosses force down everyone's throats.
The issue is not with atom, it is with the inefficiency that electron based apps bring.
The issue is not with atom, it is with the inefficiency that electron based apps bring.
That makes sense. It was not obvious from reading the article and comments. Thanks.
Why would anyone that needs to use Slack not be able to use the web version? I don't even need to use Slack, but I use the web version, and its because I didn't like the desktop one. But I still think using Electron is a reasonable tradeoff for developing a cross-platform desktop app.
I think that Slack is the top-offender in the "people love to complain about it" camp (for Electron apps), not necessarily Atom.
How practical is react native for writing desktop / mobile apps from the same javascript codebase? I know the mainline has android / ios ux outputs and there are forks that have osx & windows outputs.
How does it compare to electron? From what I understand, react native is just a javascript vm + native UX libs.
I've also heard that react native isn't as much of a priority anymore at facebook.
How does it compare to electron? From what I understand, react native is just a javascript vm + native UX libs.
I've also heard that react native isn't as much of a priority anymore at facebook.
I feel like there is an economics PhD thesis on Electron apps and the tragedy of the commons (battery life and ram) waiting to be written.
The main issue I have with the article is that it invalidates all attempts at efficiency because the author's computer can run the apps, and future computers can run the apps. That excludes a vast percentage of the consumer market, while excusing bad developer behavior that barely keeps up with the pace of technological development.
But, Atom hangs up like crazy when opening big projects or big files, that doesn't happen on Sublime for example.
This is usually an issue with syntax highlighting. Turn off syntax highlighting and VS Code, for instance, can load pretty large files. Why most Electron based editors don't implement better syntax highlighting engines is beyond me...
I have been experimenting with a hybrid desktop app building technique for past few days.
Doesn't hog memory and you can build business logic in javascript.
this is a shameless self-plug! :-)
https://github.com/harisvsulaiman/agenda-realtime
Doesn't hog memory and you can build business logic in javascript.
this is a shameless self-plug! :-)
https://github.com/harisvsulaiman/agenda-realtime
TL;DR: One man’s “this is fine” is another’s raging house fire.
I use the same spec’d computer as the author, but I regularly quit Slack when I notice my fans spin up or my other apps swapping. Usually the culprit is a GIF in Slack burning 100% of a core or my entire organization’s thousands of channels bloating my working set. Either way, a restart is in order.
I think the fixed-size 100mb RAM cost of a typical Electon app is lamentable, but a non-issue with 16gb RAM + virtual memory + SSD.
If I ever need to write a desktop app, I’ll still use Electron — I’m not going to learn QT or Tk, or force my team to do the same.
I use the same spec’d computer as the author, but I regularly quit Slack when I notice my fans spin up or my other apps swapping. Usually the culprit is a GIF in Slack burning 100% of a core or my entire organization’s thousands of channels bloating my working set. Either way, a restart is in order.
I think the fixed-size 100mb RAM cost of a typical Electon app is lamentable, but a non-issue with 16gb RAM + virtual memory + SSD.
If I ever need to write a desktop app, I’ll still use Electron — I’m not going to learn QT or Tk, or force my team to do the same.
What is your product so that I know in advance to completely avoid it?
As someone who produces an Electron-based app, I was curious what my energy use was as reported by Activity Monitor.
Avg Energy Impact:
- 14.08 Google Chrome
- 3.01 Docker (for Mac)
- 2.55 Sublime Text
- 2.04 Slack
- 2.03 Terminal
- 0.28 Mail
- 0.20 My Electron app (which hasn't been open all day, so this number is definitely wrong)
Some of those surprise me.
Those who complain about Electron being a hog are right. But it's not like there's nothing that can be done about it. I'm sure there are optimizations that could be made to reduce resource usage. Firefox recently improved memory usage. With enough demand, I'm sure Chrome could, too.
Avg Energy Impact:
- 14.08 Google Chrome
- 3.01 Docker (for Mac)
- 2.55 Sublime Text
- 2.04 Slack
- 2.03 Terminal
- 0.28 Mail
- 0.20 My Electron app (which hasn't been open all day, so this number is definitely wrong)
Some of those surprise me.
Those who complain about Electron being a hog are right. But it's not like there's nothing that can be done about it. I'm sure there are optimizations that could be made to reduce resource usage. Firefox recently improved memory usage. With enough demand, I'm sure Chrome could, too.
Why is Electron still such a memory hog? Wasn't the Chromium Content module supposed to dramatically reduce footprint by only providing the bare minimum to render a web page?
Even if computers are getting better, faster, and coming with more memory, battery technology isn't improving by leaps and bounds.
Apps that are a battery hog aren't an option.
Apps that are a battery hog aren't an option.
How can the author think that it's normal for regular people to have 16GB of RAM?
The case of not being important to use GBs of RAM can be made if the app is Atom and it's a tool for developers, but regular people still have 2GB of RAM, not 16 or even 8.
The case of not being important to use GBs of RAM can be made if the app is Atom and it's a tool for developers, but regular people still have 2GB of RAM, not 16 or even 8.
We should start treating this like a cultural issue. The PC existed for a generation before there was a real Internet, and at that point all apps were desktop apps -- CLI, GUI or otherwise. Then the web came along and it sucked. Then Gmail came along and showed it didn't have to suck, and further that you could build real applications on the web using JavaScript. Then a truly insane number of people learned JavaScript and JavaScript only, and since JavaScript only ran on the web they only built web apps with it.
The vast, vast majority of new, young programmers only know JavaScript, or maybe they know JavaScript and a "backend" language like Ruby, Python, or PHP, but that's less likely now post-node.
The vast, vast majority of cool, new tech needs to be built by programmers, and because of cultural reasons (young people are cool!) and business reasons (young people are cheap and otherwise exploitable!), those programmers are new, young programmers.
And so if your app now needs to be a desktop app, and you have a bunch of new, young programmers who are only really conversant with JavaScript, which UI framework will you use:
- Qt. Sure you can use Qt Quick, but it doesn't really run on the web and your engineers have almost certainly never used it.
- Electron. Sure it's objectively bad, but it runs everywhere you care about and your engineers can start today.
Or, if it's easier, look at it from the perspective of a young JS dev. They know JS; they're good at building SPAs; they have an app idea; .......they're probably building it in JS.
The arguments against Electron all boil down to "the web is a shitty application platform and JS is a shit language". You can't expect JS devs to cop to that, especially with the web as successful as it is.
I'm -- if you can't tell by my vaguely grouchy tone -- not an Electron fan. But my side fucked up. We let a gross blob of inefficient, JavaScript-running C++ code (that we charitably refer to as "the browser") become the platform of the future. We designed it in the worst ways, either in 10 days or by committee, and we didn't take it seriously ever. And it's only now that our jobs force us to use web apps that we suddenly give a shit, and for some reason we feel like none of this is our fault.
All I can really say is grousing about it just feels like deflection. Let's just try and not mess the next one of these up.
The vast, vast majority of new, young programmers only know JavaScript, or maybe they know JavaScript and a "backend" language like Ruby, Python, or PHP, but that's less likely now post-node.
The vast, vast majority of cool, new tech needs to be built by programmers, and because of cultural reasons (young people are cool!) and business reasons (young people are cheap and otherwise exploitable!), those programmers are new, young programmers.
And so if your app now needs to be a desktop app, and you have a bunch of new, young programmers who are only really conversant with JavaScript, which UI framework will you use:
- Qt. Sure you can use Qt Quick, but it doesn't really run on the web and your engineers have almost certainly never used it.
- Electron. Sure it's objectively bad, but it runs everywhere you care about and your engineers can start today.
Or, if it's easier, look at it from the perspective of a young JS dev. They know JS; they're good at building SPAs; they have an app idea; .......they're probably building it in JS.
The arguments against Electron all boil down to "the web is a shitty application platform and JS is a shit language". You can't expect JS devs to cop to that, especially with the web as successful as it is.
I'm -- if you can't tell by my vaguely grouchy tone -- not an Electron fan. But my side fucked up. We let a gross blob of inefficient, JavaScript-running C++ code (that we charitably refer to as "the browser") become the platform of the future. We designed it in the worst ways, either in 10 days or by committee, and we didn't take it seriously ever. And it's only now that our jobs force us to use web apps that we suddenly give a shit, and for some reason we feel like none of this is our fault.
All I can really say is grousing about it just feels like deflection. Let's just try and not mess the next one of these up.
Imagine if Mitch Kapor haven't siphoned tons of money into a BS open source calendaring app that was doomed from the start, but into a useful open source cross platform UI toolkit (and that's not Qt).
With xulrunner we had something very similare to Electron, albeit much smaller, less hoggish. Too bad, Mozilla never ever took XUL further, despite many people (many in Intranets) asking for an IDE.
I think it absolutely makes sense in business, making low quality product is fine especially when users are nontechnical, they just don't know which app is slow. Though as a developer, I cannot be proud of myself for making low quality electron apps, there is no craftsmanship to be proud of.
Moreover, if the argument of "it is slower but it costs less to make so it's ok" makes sense, then will people start mining bitcoin with client's computation power because it's "cheaper"?
Moreover, if the argument of "it is slower but it costs less to make so it's ok" makes sense, then will people start mining bitcoin with client's computation power because it's "cheaper"?
Running Atom on my machine seems to use maybe 600MB with a project open, am I missing something?
Crazy that the people posting here would have a computer from 2010 with 4GB of RAM.
I have such a machine. It's a netbook. It does a great job running Arch Linux. It dual-boots Windows 7, but Windows 7 long since became unbearably slow and I've stopped using it. Sway and urxvt are very snappy, however. Kakoune never lags -- I see my keystrokes right away, even with syntax highlighting turned on. It also starts instantly. Even emacs runs pretty fast, although it feels a little heavier. But Atom? Forget it. It starts five electron processes and pegs the CPU. pacman -Rsc atom.
The thinking espoused by the article is rooted firmly in the last decade: "Moore's law will allow us to invest no effort in writing efficient software."
The thinking espoused by the article is rooted firmly in the last decade: "Moore's law will allow us to invest no effort in writing efficient software."
It's off topic, but how is sway? I have an old netbook with an Intel i3 processor, which I'm setting up with arch (because it's the only thing that the computer can support, thanks to the blatant neglect of efficiency from the ideas of this article). Think it's worth a shot?
Sway is good, and constantly improving! I'm mostly to the point where I forget I'm not running i3. There are a couple of things that might keep you on i3, however:
* Nvidia. I have not had the best of luck running sway on nvidia systems, even using nouveau. This situation is evolving, so things may have gotten better. I've had no problems with amd or intel graphics.
* Your display manager. I boot to the console and type "sway" if I want a graphical session. I've seen display managers get a bit confused by sway -- the display manager's cursor hangs around for the duration of the sway session, or the display manager crashes when sway exits. I haven't tried all of the options, but I've had issues with both gdm and sddm. Hard to blame sway for this, but at the same time it means you have to take your pick between sway and your display manager.
* Nvidia. I have not had the best of luck running sway on nvidia systems, even using nouveau. This situation is evolving, so things may have gotten better. I've had no problems with amd or intel graphics.
* Your display manager. I boot to the console and type "sway" if I want a graphical session. I've seen display managers get a bit confused by sway -- the display manager's cursor hangs around for the duration of the sway session, or the display manager crashes when sway exits. I haven't tried all of the options, but I've had issues with both gdm and sddm. Hard to blame sway for this, but at the same time it means you have to take your pick between sway and your display manager.
Huh, a shame about the display manager issues, and thanks for the gdm & sddm warning, I was about to go use them since they apparently recognized sway (https://wiki.archlinux.org/index.php/Sway#Using_a_display_ma...), but I'll keep looking.
As for Nvidia, no worries with the little old netbook, it's integrated Intel graphics.
I wouldn't totally dismiss gdm and sddm -- my issues could be peculiar to my hardware, the versions available at the time, and so on. As long as you've got a fast internet connection, it's only 10-15 minutes to try each one. YMMV, as they say! Just be ready to hold down the power switch if things go badly. (For reference, I'm using sway on a netbook with one of AMD's integrated offerings, maybe Llano? I haven't tried a DM on that machine.)
My laptop is a 2008 MacBook Pro with a 2.4Ghz Core 2 Duo and 4G RAM. It's perfectly fine for running R Studio, Emacs, Python, Excel, Safari and VirtualBox with 1 or 2 VMs. Yet a trivial Electron app will make it crawl with the fan spinning like a jet about to take off.
MacBook Air (I think it's 2013) with 4GB is still chugging! Runs Electron apps fine.
Thanks to the very absence of Javascript from this site, people can post here even if they have 4MB of RAM. And that is a very good thing.
If the critics of Electron keep rising, like JS, I'm also planning to invest more on it. JavaScript has been paying great dividends to me despite all the bashing.
Electron is a crutch. A crutch that people resort to because it's effectively impossible to write quick and dirty cross-platform desktop apps in anything else, but, worse still, a _debilitating_ crutch that, unless you know what you are doing (and I daresay that is something people should be looking into) delivers overly bloated, resource-guzzling apps that wreck usability, battery life and (most visibly) RAM in _any_ OS.
I don't have 16GB of RAM everywhere. Statistically, NOBODY does, in the sense that the average user (who is not, usually, a developer or a power user) is probably using a Windows PC with 4GB of RAM where a _single_ Electron app can take up over half of system resources.
And I find the initial premises laughable. Whenever I ran Slack on my 16GB MacBook Pro, battery life took a nosedive - visibly so. JavaFX apps like Nightcode are far more efficient (but I digress and am probably summoning a few trolls).
So no, I don't think Electron is defensible. It is _marginally_ defensible if you want to get an MVP out, or if your real desktop app is still in the works. Excusing it by saying it will cost you more to hire someone who knows how to do cross-platform development in something like Qt or Xamarin and deliver a more efficient, higher quality product is not an excuse, it's a cop-out.