23 ms·

In Defense of Electron

64 points by bhalp1 9y ago

rmrfrmrf 9y ago
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.
- rcarmo 9y ago
  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.
  - Jtsummers 9y ago
    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.
  - rmrfrmrf 9y ago
    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.
TAForObvReasons 9y ago
> 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"
- simplify 9y ago
  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).
- akkartik 9y ago
  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.
- j45 9y ago
  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.
- corndoge 9y ago
  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.
gatlinnewhouse 9y ago
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.
- wlesieutre 9y ago
  > 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.
- allover 9y ago
  > 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.
  - Can_Not 9y ago
    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.
    - ttoinou 9y ago
      react native for desktop We're all waiting for that silver bullet
api 9y ago
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.
- pfooti 9y ago
  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.
  - zargon 9y ago
    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.
- 9y ago
santaclaus 9y ago
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.
daenney 9y ago
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.
- andrewfong 9y ago
  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.
  - hex13 9y ago
    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?
- j45 9y ago
  Agreed. Developers make the mess in their architectural decisions, not so much the tooling.
- laythea 9y ago
  If a motorcycle owner install's an ashtray on his/her motorcycle, is it the ashtray's fault?
  - mamcx 9y ago
    Is the fault of the developer that use it, the developers that build it, the ones that proclaim is a good tool, electron, node, html, css, javascript and the rest of the industry.
randomsofr 9y ago
But, Atom hangs up like crazy when opening big projects or big files, that doesn't happen on Sublime for example.
- santaclaus 9y ago
  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...
cmiles74 9y ago
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.
_ar7 9y ago
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.
- cmiles74 9y ago
  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.
  - rmrfrmrf 9y ago
    > 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.
    - cmiles74 9y ago
      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
owebmaster 9y ago
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.
maxxxxx 9y ago
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?
- Jare 9y ago
  If I have a Java GUI app running on my system, Electron apps become the least of my bloat concerns.
  - maxxxxx 9y ago
    IS that true? Java is not great but Electron seems really bad.
  - kuschku 9y ago
    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.
  - ionised 9y ago
    My experience of using both is that Electron apps are far worse.
Yhippa 9y ago
> 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.
- SwellJoe 9y ago
  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.
- joe5150 9y ago
  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?fst=as%3Aoff&rh=n%3A172282%2Cn%3A541966%2Ck%3Aquad-core+laptop%2Cp_n_feature_fourteen_browse-bin%3A2057441011%2Cp_36%3A-60000%2Cp_n_size_browse-bin%3A2423841011&keywords=quad-core+laptop&ie=UTF8 https://smile.amazon.com/s/ref=sr_nr_p_n_size_browse-bin_2?f...
rcarmo 9y ago
I read the business case section and... I got the rationale right up to the point where it says "You can just pass the cost down to your customers" and compared it to my feelings regarding delivering quality solutions. 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.
- vvanders 9y ago
  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?
  - Jtsummers 9y ago
    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.
ttoinou 9y ago
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
sullichin 9y ago
Crazy that the people posting here would have a computer from 2010 with 4GB of RAM.
- rmrfrmrf 9y ago
  MacBook Air (I think it's 2013) with 4GB is still chugging! Runs Electron apps fine.
- sevensor 9y ago
  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."
  - matthberg 9y ago
    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?
    - sevensor 9y ago
      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.
j45 9y ago
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.
Jtsummers 9y ago
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. Focusing on the first part: Why would you be making the same changes 6 times? 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. 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. If you're one, solitary, person, you aren't a team. Just like there's no army of one, despite the pervasive recruiting posters and videos years ago. 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
- agentultra 9y ago
  Maybe https://github.com/Widdershin/positron 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.
  - Jtsummers 9y ago
    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.
harisvs-code 9y ago
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 https://github.com/harisvsulaiman/agenda-realtime
devrandomguy 9y ago
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.
- rmrfrmrf 9y ago
  We're declaring Electron dead now?
  - devrandomguy 9y ago
    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.
agentultra 9y ago
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.
- Jare 9y ago
  > 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.
scarface74 9y ago
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.
spacelizard 9y ago
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?
hzhou321 9y ago
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?
- pyre 9y ago
  I think that Slack is the top-offender in the "people love to complain about it" camp (for Electron apps), not necessarily Atom.
- matthberg 9y ago
  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.
  - hzhou321 9y ago
    That makes sense. It was not obvious from reading the article and comments. Thanks.
  - aeorgnoieang 9y ago
    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.
mahyarm 9y ago
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.
jaas 9y ago
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.
- theandrewbailey 9y ago
  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.
  - ithilglin909 9y ago
    But "the army you have" could also be the dev team you have..
    - pantalaimon 9y ago
      It's usually easier to employ someone than to give each of your costumers a new computer though.
      - ithilglin909 9y ago
        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.
    - mixedCase 9y ago
      If the dev team you have is competent enough to write JavaScript, then they can spend a couple of afternoons playing around in QML.
b123400 9y ago
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"?
ocdtrekkie 9y ago
"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.
christophilus 9y ago
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/ http://www.red-lang.org/
iffycan 9y ago
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.
coldtea 9y ago
>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...
coldtea 9y ago
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).
matthberg 9y ago
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.
Glyptodon 9y ago
Running Atom on my machine seems to use maybe 600MB with a project open, am I missing something?
zmix 9y ago
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.
jitl 9y ago
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.
- MaymayMaster 9y ago
  What is your product so that I know in advance to completely avoid it?
camgunz 9y ago
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.
nkkollaw 9y ago
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.

64 points by bhalp1 9y ago

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.

rcarmo 9y ago
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.
- Jtsummers 9y ago
  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.
- rmrfrmrf 9y ago
  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.

TAForObvReasons 9y ago

> 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"

simplify 9y ago
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).
akkartik 9y ago
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.
j45 9y ago
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.
corndoge 9y ago
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.

gatlinnewhouse 9y ago

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.

wlesieutre 9y ago
> 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.
allover 9y ago
> 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.
- Can_Not 9y ago
  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.
  - ttoinou 9y ago
    react native for desktop We're all waiting for that silver bullet

api 9y ago

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.

pfooti 9y ago
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.
- zargon 9y ago
  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.
9y ago

santaclaus 9y ago

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.

daenney 9y ago

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.

andrewfong 9y ago
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.
- hex13 9y ago
  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?
j45 9y ago
Agreed. Developers make the mess in their architectural decisions, not so much the tooling.
laythea 9y ago
If a motorcycle owner install's an ashtray on his/her motorcycle, is it the ashtray's fault?
- mamcx 9y ago
  Is the fault of the developer that use it, the developers that build it, the ones that proclaim is a good tool, electron, node, html, css, javascript and the rest of the industry.

randomsofr 9y ago

But, Atom hangs up like crazy when opening big projects or big files, that doesn't happen on Sublime for example.

santaclaus 9y ago
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...

cmiles74 9y ago

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.

_ar7 9y ago

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.

cmiles74 9y ago
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.
- rmrfrmrf 9y ago
  > 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.
  - cmiles74 9y ago
    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

owebmaster 9y ago

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.

maxxxxx 9y ago

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?

Jare 9y ago
If I have a Java GUI app running on my system, Electron apps become the least of my bloat concerns.
- maxxxxx 9y ago
  IS that true? Java is not great but Electron seems really bad.
- kuschku 9y ago
  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.
- ionised 9y ago
  My experience of using both is that Electron apps are far worse.

Yhippa 9y ago

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

SwellJoe 9y ago
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.
joe5150 9y ago
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?fst=as%3Aoff&rh=n%3A172282%2Cn%3A541966%2Ck%3Aquad-core+laptop%2Cp_n_feature_fourteen_browse-bin%3A2057441011%2Cp_36%3A-60000%2Cp_n_size_browse-bin%3A2423841011&keywords=quad-core+laptop&ie=UTF8 https://smile.amazon.com/s/ref=sr_nr_p_n_size_browse-bin_2?f...

rcarmo 9y ago

I read the business case section and... I got the rationale right up to the point where it says "You can just pass the cost down to your customers" and compared it to my feelings regarding delivering quality solutions. 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.

vvanders 9y ago
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?
- Jtsummers 9y ago
  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.

ttoinou 9y ago

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

sullichin 9y ago

Crazy that the people posting here would have a computer from 2010 with 4GB of RAM.

rmrfrmrf 9y ago
MacBook Air (I think it's 2013) with 4GB is still chugging! Runs Electron apps fine.
sevensor 9y ago
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."
- matthberg 9y ago
  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?
  - sevensor 9y ago
    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.

j45 9y ago

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.

Jtsummers 9y ago

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. Focusing on the first part: Why would you be making the same changes 6 times? 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. 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. If you're one, solitary, person, you aren't a team. Just like there's no army of one, despite the pervasive recruiting posters and videos years ago. 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

agentultra 9y ago
Maybe https://github.com/Widdershin/positron 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.
- Jtsummers 9y ago
  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.

harisvs-code 9y ago

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 https://github.com/harisvsulaiman/agenda-realtime

devrandomguy 9y ago

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.

rmrfrmrf 9y ago
We're declaring Electron dead now?
- devrandomguy 9y ago
  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.

agentultra 9y ago

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.

Jare 9y ago
> 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.

scarface74 9y ago

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.

spacelizard 9y ago

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?

hzhou321 9y ago

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?

pyre 9y ago
I think that Slack is the top-offender in the "people love to complain about it" camp (for Electron apps), not necessarily Atom.
matthberg 9y ago
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.
- hzhou321 9y ago
  That makes sense. It was not obvious from reading the article and comments. Thanks.
- aeorgnoieang 9y ago
  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.

mahyarm 9y ago

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.

jaas 9y ago

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.

theandrewbailey 9y ago
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.
- ithilglin909 9y ago
  But "the army you have" could also be the dev team you have..
  - pantalaimon 9y ago
    It's usually easier to employ someone than to give each of your costumers a new computer though.
    - ithilglin909 9y ago
      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.
  - mixedCase 9y ago
    If the dev team you have is competent enough to write JavaScript, then they can spend a couple of afternoons playing around in QML.

b123400 9y ago

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

ocdtrekkie 9y ago

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

christophilus 9y ago

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/ http://www.red-lang.org/

iffycan 9y ago

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.

coldtea 9y ago

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

coldtea 9y ago

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

matthberg 9y ago

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.

Glyptodon 9y ago

Running Atom on my machine seems to use maybe 600MB with a project open, am I missing something?

zmix 9y ago

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.

jitl 9y ago

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.

MaymayMaster 9y ago
What is your product so that I know in advance to completely avoid it?

camgunz 9y ago

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.

nkkollaw 9y ago

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.