In Defense of Electron
dev.to
dev.to
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.
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?
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.
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.
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.
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).
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.
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!"
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.
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.
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.
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.
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.
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.
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...
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.
It's not the same type of app as Spotify or Slack, but is comparable to VSCode.
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.
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.
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"?
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.
Maya (the high end 3D animation package) switched to Qt a few years ago.
It's a powerful and memory-efficient IDE written in C#/Mono.
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.
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.
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.
> 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).
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.
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.
A Tcl/Tk app packaged with StarKit would be better and consume literally one-tenth of the resource, and quite possibly one-hundredth.
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.
[edit]
Here's a commercial application with a Tk gui that shows cross-platform screenshots:
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.
I'm pretty sure this is making the opposite case you intended.
It's only 4 MB and handles tens of thousands of Slack messages in one chat without lag.
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 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.
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"
"... 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.
/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.
I have a MacBook with a decent battery life until I run electron apps, then I have a MacBook with crappy battery life.
It has nothing to do with 'laziness'. You ignored the entire 'The Business Case' section of the article.
react native for desktop
Use JavaFX with JS running on the JVM?
Far smaller runtime, far better performance.
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
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.
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.
No, I don't think many development companies have reduced the common features of codebases in 3 different languages to libraries yet.
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!
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.
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.
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.
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.
I really want to know the use cases you're talking about, because, to me, nothing could be further from the opposite.
Yeah, all those pesky actual metrics...
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.
So the bloat is actually bigger than running multiple instances of Chrome.
That was a reasonably effective use of a common runtime and resource.
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.
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 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?
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.
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.
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.
Someone should do a modern WxWidgets type library using modern APIs and that works with modern C++ (C++11 at least), Go, and Rust.
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.
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.
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.
1: https://smile.amazon.com/s/ref=sr_nr_p_n_size_browse-bin_2?f...
Uh... 4 GB is the prevailing standard for the average user PC.
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.
After all, it is just a text editor, not like a hot technology that your boss will force down your throat, right?
The issue is not with atom, it is with the inefficiency that electron based apps bring.
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.
Doesn't hog memory and you can build business logic in javascript.
this is a shameless self-plug! :-)
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.
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.
Apps that are a battery hog aren't an option.
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 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.
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"?
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."
* 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.