On macOS, the alternative would be to use Fluid[1]. You can build mini-apps from a lot of websites and the footprint is very little. (No affiliation, just a happy user)
Unless I'm missing something, isn't that just wrapping the webpage in an embedded WebView? If so its basically doing the same thing as electron, except using Safari instead of Chrome and not giving the app any native API access.
This helps in 2 ways:
- Safari is less of a resource hog than chrome
- It avoids the huge 380 meg download of electron
But it doesn't solve the runtime problems. The app is still running inside a VM (safari), so its still going to be way slower than its native equivalent and it'll use way more memory. Also in a real browser background tabs get throttled in dozens of ways. But I bet none of that throttling happens via Fluid, because even background windows can be visible at any time on macos.
I'd be curious to see a quick comparison of CPU and RAM usage of slack-for-desktop and slack-in-fluid if anyone is willing to give it a whirl. I'd do it myself except I deleted slack after writing that blog post.
If you like Node.js and HTML/CSS, just have a node daemon running in the background with an HTTP server to your app! It's just like Electron, but without the CPU/RAM/Battery usage. You can even have binaries that stay open after a double-click and automatically open your browser to localhost:40023 (or whatever).
Seriously, if browsers supported an app:// URL which just ran a local site with special privileges and allowed for some custom branding Electron would be dead overnight.
if they'd be giving you access to the complete node.js ecosystem maybe.
With electron you can easily integrate native c++ libaries for high performance stuff or things that require hardware access. It's not like electron is just a webbrowser.
A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device).
Building Chromium/CEF requires several times more disk space and takes several hours on my new MacBook Pro. So I guess the answer is "not abnormally large".
Both your webpage and your docs are riddled with typos and the like. While it isn't indicative of code or project quality, it sure makes taking the project seriously a lot harder.
Seems an easy question. English is basically a/the global language. If you want a massive portion of the community to find the content inaccessible, making it available only in French is a good way to do so.
Hey, I think you're doing the right thing, in 1) asking for help from the community in an area where you feel lacking, and 2) by making it available to the best your ability. Many projects fail at one of those two, which dooms them to never have a community. Keep up the good work.
Well it depends on how much you have worked with a person who was still learning English. For me it highly depends on the kind of typos:
- They're vs Their and similar normally denote uneducated native English speaker. The code might still be okay, but these typos passing to production makes me check code quality in case some similar QA mistakes are passed in the code.
- Grammar mistakes normally show a foreigner for whom English is not the main language. A small example just in the first line, "to create apps, games that run" => "to create apps and games that run", but this is normally due to a different language constructions. Similar to graphical softwares => graphical software.
So, kudos for OP to write the documentation in a non-native language! (upon light investigation it seems the main writer is French and his coworkers fix typos from time to time).
> They're vs Their and similar normally denote uneducated native English speaker.
in germany only grammar nazi's would actually hate such things. they are too common, to say that only uneducated people do it.
people who write code and distribute code to the whole world are not writers, there is no need for "perfect" grammar and typos. i mean in my first application i've written quanity instead of quantity (inside the code), somehow it slipped in a lot of places, but i think many many people who will read the code would still understand it.
as long as the user interface is checked, i think it's okay if the readme/documentation has typos or grammar mistakes (on open source projects).
the most important thing is, is that people understand each other/understand what it's all about. which is just fine for nidium.
Really? I have seen it in many "comment sites" but rarely see it in technical documentation and blog posts. And I don't hate that at all! I'm just pointing out that someone who makes these kind of mistake is probably native and that a large number of these typos indicate that:
- The writer didn't do proofreading (or did it but is not aware of the mistake).
- It's made by a single person with no one else to check on the documentation.
Now while they are not technically a display of low code quality, they are normally indicative of low attention to detail and lonely programming, which is not the optimal situation for high code quality. For people using English as the second language I'm a lot more forgiving since they and their coworkers might not even know how to properly express some things due to translation issues (and not due to lack of proofreading/lonely programming).
In my experience when I'm doing proofreading of my own libraries I also catch ambiguous sentences, lacking documentation or examples and many other things that could be improved upon.
It may be less an issue for games, but I'd have to wonder about stuff like accessibility. While I agree that the web platform has many things that can likely be removed in a pure app platform, I have to think that there are also many pieces built up over the years that are important and would have to be rebuilt.
I've applaud the effort but I don't think I would use this over electron. Without HTML/css how do you make an interface? With canvas directly? I can't find any examples other than three.js stuff.
But I was hoping for something like Electron/Node.js with a different/smaller engine like Ducktape. There seems to be a Chakra version of Node.js so this should be possible in the future.
The only heavy weight in this constellation remains Chromium...
Then don't, it's really wasteful to have webdevs write desktop apps using Electron. I don't see a gain over using a webpage. I use slack this way and I don't see any problems.
No one would bother writing Electron app if there was no demand. Most users, (even tech savvy users) prefer using Electron Slack instead of keeping the webapp open in a browser.
Why not? People do native mobile apps despite those platforms being more or less at parity, while desktops are overwhelmingly just one platform. The tools to write cross platform mobile apps that aren't just a browser with lipstick (like xamarin) exist for both desktop and desktop.
Quite the opposite, they wanted to prevent vendor lock-in, so they pushed for standards like service workers and NaCL that eliminate the need for Chrome Apps.
But aren't those two only for getting better performance for web apps? Chrome Apps actually help getting a web app integrated into the OS, I don't see where (P)NaCl helps me with that.
I was just trying to look into this, I can't see a way for this to happen on a desktop, is my google-fu broken or is coming later. I was also looking for a desktop icon (or file or whatever).
Yep, I hate that all of these companies try to convert their applications from tabs to dedicated processes. It would be a huge deal breaker if Chrome Apps could become a thing and replace them. Now I have 4 different Chrome apps running on my computer.
My point was they could convert their web applications to Chrome Apps which has better native api support and experience if Chrome Apps could become a thing.
So I've liked what I've heard about Progressive web apps, but I was wondering if there is a solution for desktop? can you create a native icon that opens a new window with a PWA?
That's the entire rationale behind e.g. using python or php on the backend. Oh, the requests are IO-bound, we don't need to use a cumbersome language like C++ or Java to develop our backend, we'll just throw more cores at it if it gets too slow. Developer time will always be the first thing to be optimised, not least because the first to ship win and the first to ship is the one with the fastest development stack.
> If you want to use JS and react to make a native app, try react native instead.
Given the discussion of the recent ReactXP thread, I'm guessing most people don't realize you can do this today. React Native supports macOS [1] and UWP [2].
Edit: There's even some early work on Ubuntu support [3].
I'm probably in that camp too, I thought it was just for android and iOS still (even though I consider myself to keep up to date with these types of things).
You can also currently use React to share code across iOS [2], Android [3], UWP [4], macOS [5], web [6], VR [7] and a bunch of other stuff that is there mostly for fun (like React Hardware [8] and React Sketch.app [9]).
There's also experimental work on defining a set of primitives that works across all of these platforms [10].
I originally thought React Native was for all platforms, then I read their website and docs which made me realize it was only for mobile. That all went down a few weeks ago. Now, today, I find out I had it right the first time. How big a shortcoming is it of their website that it made me go away thinking it was something it wasn't when I had the right thing in mind?
Ubuntu support? Are you kidding me? Is Ubuntu an OS? Is it an UI tookit? So what in fact is React Native Ubuntu? Probably a React Native backend that displays the UI on Shuttleworth's ego.
I was about to call bullshit on the blog author, but I guess we are getting to that point. I've been hoping for a React or Vue-native version for desktop so that the Chromium in Electron could be avoided.
There still seems to be a big problem that Electron is addressing that these React Native solutions aren't bothered with: it seems that users need to have Windows 10 whereas if you look at the OS market share, Win 7 still has the most usage at almost 50%
I don't understand the React Native comparison. AFAIK, you can't build desktop applications with that, nor can you build mobile applications with Electron like you can with React Native.
A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience.
Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated parrot cartoon.
I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome does not cause any issues, as GIFs seem to be suspended when the window is not in view. CPU usage goes down to almost 0 when you switch away from your GIF-filled Chrome window. For Slack, however, it barely changes. A big shame.
(On that note, I wonder how much power is wasted by party parrots via CPU usage. Where I work at least one is almost permanently visible in any conversation as a reaction emoji, so it's probably not insignificant.)
I'm consistently blown away that stuff like this gets past testing.
Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs?
These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.
I think this thinking is exactly how it gets past testing. You could force every engineer to have a CPU meter, but that alone won't help; they'll ignore it, assume it was a coworker's change that made the usage higher, or just assume their CPU is high because of their 30 Chrome tabs currently open while developing.
A better solution would be to have CI monitor CPU usage so that increases/decreases could be monitored and reported over time/per commit.
You could force every engineer to have a CPU meter,
No, you should force every developer to have a shitty Core 2 Duo CPU from 10 years ago. A lot of devs are working on new shiny i7s and that will hide a lot of performance problems because it's a top end CPU. Do your testing on a cheap box and if it is still smooth then you can ship your product.
> These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.
Every bug looks egregious in hindsight; just because an app has one is no reason to assume the engineers who made it don't bother to test anything.
Also: that particular issue only hurt idle CPU usage, and the usage was something like 13% CPU usage IIRC. It wasn't exactly the kind of thing that sets off klaxons.
Most bugs are of the form "do X then Y then it doesn't work". These idle CPU bugs are reproduced simply by opening the application.
I accept that 13% idle usage is invisible for most developers - but that's a bit disappointing. I notice stuff like this just by idly glancing at my CPU meter from time to time. An app that's sitting on high idle usage sets off klaxons for me.
You're missing my point. All software has bugs; something always "makes it past test". Pointing at whichever bug did make it into production and saying "gosh those developers must not be testing anything" is silly.
I assume that's been patched; I just tested it and VS Code sat at about .01-.03% of CPU with a blinking block cursor (VSCode vim extension. Maybe it's better than the default I?).
I noticed a few moments after startup that the CPU usage jumped to the 5-7% range for a couple seconds, then it notified me that an update was ready (I assume it was downloading/checking/processing that update). I don't know if this is Electron, or just a general trend in desktop apps, but it seems to be getting a lot easier to update them. So when those pesky CPU/memory hog bugs are found, they can be quickly patched. As for the general trade off that comes with running an extra Chromium process, I suppose it's up to users/developers as to whether it is worth it in each case.
How can animating a few gifs (or a few hundred) even use a noticable fraction of CPU? It's small images blitted from memory to screen. I agree with the author. Get off my lawn.
I've noticed the same myself, and I'm a bit surprised Slack hasn't done the same trick some of the larger image hosts have and started converting gifs to videos. Those hosts did it to cut bandwidth costs, but it also helps users as a side effect.
(I continue to be amused that everyone records & shares gifs for "compatability" and "simplicity", but many of the places they're shared re-convert them into videos.)
I know nothing about how Electron renders GIFs, but can guarantee you that there's no world where 16x16 animation should take up 20% CPU. Suggesting that we should convert them to tiny videos is completely missing the point.
The problem is that in popular usage many GIFs are not 16x16. People are sharing high resolution GIFs that can weigh tens of MB, and rendering several of those at once (whether directly in Chrome or in Electron) is not a negligible amount of CPU. It shouldn't peg a core, of course, but it's definitely higher impact than videos of similar sizes, since video rendering is considerably more optimized for these cases than GIFs are.
The GIFs were significantly more complex than the single emoji that the parent comment mentioned. Actually, I think even a four-frame 48x48 gif is more complex than that "single animated parrot emoji" :-).
Well, back then we didn't have a composited desktop, so when the browser was out of view, no drawing was taking place. I kind of wish we would still have the option of programs just drawing directly to the screen rather than caching everything in private back buffers, but still use modern graphics techniques. I have a hunch that would actually be faster, since cpus have severely outpaced memory.
Post author here. I thought about that, but there weren't any visible animations playing when I took those measurements. And the 5% figure survived a restart of the client. Its possible there were gifs playing above-the-fold somewhere and reloading themselves, but if so I'd say thats a bug somewhere in the interaction between the 15-20M lines of code in slack, electron and chrome.
Its also worth noting that blog post is from a few months ago. Its possible the slack team has fixed the issue now. I wouldn't know because I deleted the slack desktop app and haven't looked back.
Comparing CPU usage % across machines (or even runs on the same machine) without know the p-state doesn't make for a good comparison. This is especially true if you're on a fairly new processor with wide frequency operation range, 5% @ 1.3Ghz != 5% @ 3.5Ghz
But they have responsibility as to what underlying tech they use. A responsibility they happily offload to someone else and go on their merry way -- and that's one of the big issues here.
I didn't use that app ever but I guess w/ or w/o a gif, it won't use much CPU when it's idle. When scrolling a page-like thing that's already rendered, also then it probably doesn't do much computations. What, at all times, will be overtly consumed is going to be memory space. That may cause battery drainage and general slowness in the OS due to swapping, and even quicker wear-out of storage hardware. AFAIK Chrome takes hundreds of MBs of memory just right after startup, with nothing open.
Very timely article. But I have been told to shut up and use Atom/VSCode/Slack like everyone else and upgrade hardware if software runs slow.
I find memory/cpu efficient applications not just useful but respectful to users specially when upgrading hardware is not possible due to financial or policy reasons.
We're also in an era when the speed of laptop and desktop CPUs has essentially stalled. Put another way, if our apps hog more resources there aren't necessarily faster machines we can buy.
Yes, this is extremely important to remember. The days of "who cares if we use a few extra bytes of RAM or a few extra CPU cycles here and there as computers will be twice as fast and have twice as much memory this time next year" are long over. And with the huge push for mobile and slim, portable computers, power efficiency is paramount as users really care about battery life. Yes, sure you can get a more powerful laptop than your nice, sleek, portable macbook air, but it's going to weigh 5x as much and the battery life will suck, especially if you actually use that power. People want to be able to use their CPU and RAM to run multiple applications efficiently, not waste it on a few laggy memory and CPU hogs.
I'm running VSCode and Slack on an 11" MB AIR with 8GB Ram (Early 2014). I'm not really seeing performance problems, even with about 40 tabs open on my Google Chrome. While I do occasionally see Slack occasionally popping up on my Activity Monitor, as a user I don't feel I've actually been negatively impacted by this.
That is why I do not use Slack for Desktop, and just keep a pinned tab of Slack open almost all the time. I also tend to reduce my usage of any Electron-based app because I want to better make use of my laptop resources in my development workflow requirements.
I feel like I agree with most what's said there, the same would apply to NW.js and the likes.
This should be a heads up for GUI developers to [re]consider Qt and QML. It made real progress in the last few months. and there are some nice bindings to it.
Meanwhile, we're still waiting for those "pro-native" people to give us better user experience.
I agree that Electron has its issue like having multiple copies of Chromium (and not Google Chrome).
Obviously native apps are better overall, but only if they provide a better UX. Being a vscode user, I don't know which native editor provides the same UX.
There are native editors reaching from very bare bones (vim) to medium like VS Code (Sublime) to full IDE (Visual Studio). All of those run native interfaces.
Emacs provides a better UX, Visual Studio (proper) provides a better UX, Sublime provides something close, although not as good. Slack's UX is incredibly basic. It's a couple of steps above a basic CRUD app. There are billions of IRC and XMPP clients ranging from toy to professional-quality, I use IRSSI, which is admittedly basic, but I find it hard to believe that there is no better native chat UX in existence than Slack's.
Why would a tech company not build its flagship product natively on the platforms where it runs? It seems like a generation drift: an obliviousness to the world outside of JS/web dev, and a general disregard for application performance.
Put simply: time to market. Experienced front-end devs with a designer on hand could put together the UI inside of a day, with a workable user experience.
Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release.
The proof is in Atlassian and Microsoft chasing after Slack on this. Very few people came forward to wave the "Let's just go back to IRC" flag.
It's shiny, new, you can drag and drop gifs and files into it, and it runs pretty swiftly (ignoring all of the obvious flaws). Most, especially less technical, users would find it a charm to work with. In my experience, they do -- and above all of the competitors.
The rest of your points are rather valid. But maybe its not so much obliviousness, as eagerness and impatience, and the reality of the market being as timely and pressing as it currently is. It's a race -- just like the telephone and the radio (for my point I'm ignoring the scale of impact here).
That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS.
> time to market
If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - and poor performance is a huge turnoff. Looking blingy and having all the features doesn't save an app with a 200ms lockup. or a 10% CPU at idle.
Agree, I think this is a combination of lack of imagination by developers who only know JS, and management who has bought the myth that cross platform development is 3x faster than making native apps.
I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript.
Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.
because they don't need to. Our phones and computers aren't where they were 10~15 years ago. The end user doesn't even notice if an app is native or running in Electron.
Given that constraint, time to market becomes crucial as the huge cross platform barrier is significantly reduced by Electron.
It's also a demographic shift. Young developer's aren't coding in Java peak world anymore. We haven't even reached peak Javascript yet.
Definitely a demographic shift. And maybe business smart: cheaper to hire and onboard web devs etc. But that doesn't mean the company and its product shouldn't be critiqued for its architecture (even more so because it is a software company).
It's a demographic shift of those entering the tech workforce. I can see someone is downvoting comments that doesn't agree with time to market being an important driver in influencing architectural decisions. This is someone who is very mature and well seasoned in Java architecture.
Software isn't just about making things fast as possible. You also have limited resources and have to make decisions on money in the bank, level of effort, engineer skillsets, competitive forces and market demand.
> I can see someone is downvoting comments that doesn't agree with time to market being an important driver in influencing architectural decisions. This is someone who is very mature and well seasoned in Java architecture.
Ah yes. Someone who downvotes you, which you assume to be about the time to market comment of your argument, must naturally be a person "who is very mature and well seasoned in Java architecture".
What does that even mean to be "well seasoned in Java architecture"?
It's not flash for the desktop, the author just wants to say something mean about electron cause he's angry.
The flash analogy doesn't hold in any way. "Well, flash was errr ummm BAD you know.... and this electron thing it's BAD too .... err umm SAME AS FLASH!
How much of all this nonsense is caused by devs using any and every JS library out there? We've seen this problem on the nodejs side before, and it's even more painful on the browser side. Sure, Slack almost certainly doesn't know all 15m LOC in Chrome, but they sure as hell should know every LOC in their JS, whether that's from in-house code or 3rd party libs.
Most users will never notice this, and if some problem is solved using Electron well then Electron solved the problem, life goes on. If you don't like an app or how it behaves then just don't use it.
I've been working on a hobby app for some years that is a modern refresh of an old idea. As the article exhorts (and just for funsies, it's just a hobby) I'm writing it using native code and to be conservative on resources.
Every place I need to render text or make a thing respond to a mouse click I need to manually do all my own text layout and event handling and so on. (The app is in a domain where it needs special rendering -- I can't just reuse a system widget or library like Qt for this.)
Meanwhile, people are making apps similar to mine on top of Electron and banging out features way faster than I ever could. If they want some popup to have some bold text, or use the GPU to animate, or properly handle Arabic text layout, they get it all for basically free, they just need to bang out some divs. I am jealous.
Well, the question is: Does your app run always like a daemon or just when you actually need it?
It can be fine to prototype in Electron, or to make tools in it. But if you're making a chat program or anything similarly long-lived, it's the worst decision you can make for your user.
"it's the worst decision you can make for your user"
- Is it? Because there are a lot of Slack users who don't care at all about your tradeoffs. Most of them don't even notice. We're just the unfortunate ones who do notice.
It's appropriate to call Chrome an OS-like platform, and it's quite convenient to ship apps with, but it's not "Flash for the desktop". As someone who is opposed to bloat but sometimes appreciates convenience, I think Electron is getting a bad rap here for something that was screwed up by the JS app developers.
Go to Electron's website and download the demo (called API Demos). It's 3 processes and consumes 0.0 CPU on idle. Is it super efficient space-wise for what it does? Certainly not. And RAM usage is a valid concern. But churning CPU cycles on idle is not Electron's / Chrome's fault. I also suspect that if an app is behaving grossly on Electron, it's probably a bad actor within a generic browser environment, too.
My recommendation would be to not ship simple web apps wrapped in this huge machine without a good reason. But there are good reasons to use Electron or NW. It's just a poor choice when all you need is a thin wrapper around your website.
Blog author here. Thats a fair criticism. I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that.
But I'd also argue that Flash could always be written to be efficient too. The problem with flash was never the little games people made. The problem was that one tab with a stupid punch-the-monkey banner add playing somewhere that would sit on 20% cpu even when the tab was in the background. I think Electron is similar, except in the desktop space. Well written apps seem to be able to keep CPU load down (although they still have a huge download and a huge RAM footprint). But there's been a running trend of noticing some dumb software running somewhere on my machine eating all my CPU. And in the last year or two its been an electron app, every time. Just like flash before it.
>I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that.
Gotta agree with the other response here. If you have shown that what would seem to be much larger and more CPU intensive applications have been able to reliably perform well, why suggest moving away from electron instead of suggesting that users learn how to use it correctly, or perhaps suggesting that electron better educate users on how to use it correctly?
I get the idea of Electron Apps having some hate for the performance. I mean if I have to open a large SQL file (> 250MB) and compare the performance between Atom and Sublime... well the difference will be day and night.
But there are a few differences between Flash and Electron that are not small. I mean the first thing is, Electron is open source in a open Standard, and have a fast development cycles to fix performance and security issues.
I think it's like a PHP situation. Electron is easy to use and sells itself as a cheap way to build apps, so this attracts lazy developers so we have a lot of problems, but that doesn't mean the technology is bad. But this is not a Electron problem, I mean web pages right now are heavy and slow for nor real reason. We need better fron-end developers.
I love VS Code, Hyper, and others, so maybe I'm biased, but I think Electron will be a interesting option to make desktop Apps something again.
Sorry I was vague, and yeah you're right they have never stooped.
I was thinking more in the Hype thing for new developers. You know like a small Renaissance in the Desktop UI/UX deparment, you know would be cool see beautiful desktop Apps in sites like Behance, Dribbble, etc spotting the first places, instead of the classic App with default OS UI or weird adapted ports of Mobile apps.
> I just ... don't care about your app enough to justify running more chrome instances
Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?
Electron has won out because key apps have opted to use it and decided that the trade-offs of user CPU and battery are worth some amount less than their productivity as developers. Yes, there are alternatives to developing native desktop apps in JavaScript (I'm not sure I've seen React Native used this way, but it probably exists somewhere out there.) People opt for Electron because it's holistic, battle-tested and easy to use.
I'm not excusing Electron's (many) flaws. There should be a concerted effort by the team to "disable" parts of Chrome that don't make sense for native apps, or at the very least let it be configurable. He's right, there's no reason Slack should have access to the GamePad API (or WebVR, etc.)
My overall point is that like everything, productivity of the end-user is always going to have some kind of trade-off with the productivity of the developer (or more specifically, the business considerations of the company.) Always. We don't write assembly anymore even though the apps would be a gajillion times faster than writing Electron-wrapped web apps.
Now, complaining that Electron/Slack/etc. are CPU/battery-hungry is completely valid and a good discussion to have, but you only get me to jump into the HN comments once you start delivering global developer edicts with no regard for the other considerations those projects have made.
> The other sad fact is that even most developers have no idea that this is even happening on their computers. They run slack but have no idea how hungry it is. As a developer its your responsibility to know this stuff.
I'm not sure I completely agree here, "responsibility" is a bit heavy of a word.
> Users: Please complain more about slow programs. Its 2016. We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish.
Wait, this is the first instance (edit- second, but mentioned in passing in the previous paragraph) the author mentions "sluggishness" as a metric. IMO sticking with measurable stats like CPU and battery life are better because you have no idea if someone other than yourself experiences or even perceives this sluggishness. What about non-developers at BigCo that only run Chrome, Slack, Spotify, and Word? Would they feel sluggishness? I would guess not, since I rarely experience it as a developer on a Macbook using Chrome, Slack and Atom. (Things only get dicey when I start doing Vagrant stuff.)
> Also all you web devs: Go learn C or Rust or something. Your program runs on a computer. Until you know how that computer works, you're doomed.
Doomed to have a successful career? I prefer being "doomed" then. (For the record, I do know
> And until then get off my lawn shakes fist.
Aaaaand there we go. Maybe next time don't bury the lede? :P
> Oh, and read this talk on the website obesity crisis. Its very funny. And very sad. And very true.
This is an entirely separate concern (and one I agree with.) Heavy web pages are heavy because they are multi-megabytes to download, not because their "installed" wrapper (Chrome) is hundreds of megabytes.
I don't think that apps necessarily chose it because of the reasons you mentioned. It is most definitely due to productivity, but there are ways to mitigate the CPU and battery usage -- I often have Spotify open on my Mac and it really doesn't use much CPU (often less than either Safari or Docker), and it doesn't suffer from poor performance most of the time. I would say that while Electron apps, as a whole, are generally worse than a native app, there are ways around the issues that plague some of them that depend on the developer(s). For example, VSCode and Spotify having pretty good performance and not hogging CPU, while Slack and Atom the opposite.
> Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?
I read Slack in emacs. I write code in emacs. I browse the web in emacs & Firefox. I play music via my phone's native Google Play Music client, although if I wanted to I could use emms, an emacs music-playing mode.
I have no desire to run some GUI-only, CPU-hungry, memory-ravenous, of-the-moment JavaScript nightmare of a program. My productivity as a developer is hindered by those things. I have no desire to write JavaScript: I'd rather write Lisp, or Go, or Python.
Yes, it's possible — and preferable! — to uninstall Slack, Atom, Chrome and Spotify. Try it today.
I find it interesting how many devs I have met in the last few years who seem so tied to GUI's... as a sysadmin who lives mostly on the cli, I never understood it.
Side note; many of said devs also used OSX instead of linux, maybe some correlation there.
Emacs is where it's at. Really, it's my main operating system. Email, org-mode, erc for IRC, RSS reader, editor, twitTER, eww (for some things like documentation), dired for folder management etc. Currently working on learning ledger.
"Using a free version of vi is not a sin but a penance."
This comment is semi-ironic to me because traditionally Emacs had the reputation of being bloated and slow compared to its competitors. Maybe in a few years hardware will similarly catch up to Electron?
Jokes on you, I don't use any of those things in the first place!
One serious nitpick with you though. "Heavy web pages are heavy because they are multi-megabytes to download...) In my experience, heavy web pages are heavy because of the dozens of scripts being run on the pages, often based on bloated frameworks. Running uBlock and NoScript in advanced, I see it all, and I immediately think less of any site trying to load more than 3 scripts. Often I come across sites trying to run 20+. That's why the web is heavy today, not because the sites are huge to download.
You're not wrong, but the article the author linked to[1] specifically deals with the problem of modern web page size bloat (which is why it feels out of place to the rest of the article, IMO.)
1,036 comments
[ 2.7 ms ] story [ 167 ms ] thread[1] http://fluidapp.com/
This helps in 2 ways:
- Safari is less of a resource hog than chrome
- It avoids the huge 380 meg download of electron
But it doesn't solve the runtime problems. The app is still running inside a VM (safari), so its still going to be way slower than its native equivalent and it'll use way more memory. Also in a real browser background tabs get throttled in dozens of ways. But I bet none of that throttling happens via Fluid, because even background windows can be visible at any time on macos.
I'd be curious to see a quick comparison of CPU and RAM usage of slack-for-desktop and slack-in-fluid if anyone is willing to give it a whirl. I'd do it myself except I deleted slack after writing that blog post.
Slack Electron: 4 processes, 56 MB + 355 MB + 64 MB + 29 MB = 504 MB
This is after signing in to one team, (janky) scrolling through a couple of channels and running for a few minutes.
Probably something like this: https://github.com/Microsoft/vscode/issues/22900 (not the cursor thing specifically, but something that feels lightweight, but isn't)
Which is probably fixable. I would guess Vscode is more code than Slack, and they were able to fix this, albeit with very good help from a customer.
Seriously, if browsers supported an app:// URL which just ran a local site with special privileges and allowed for some custom branding Electron would be dead overnight.
A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device).
Previous HN discussion : https://news.ycombinator.com/item?id=6314961
Is this abnormally large for a project like this?
- mozilla spidermonkey
- Google Skia
- ffmpeg
- portaudio
- leveldb
- OpenSSL
And various other stuff.
We're French and it's indeed hard for us to get this perfectly right and focusing on the project itself at the same time.
We're planning to move this to github in order to let the community help us on this.
english is the most spoken secondary language.
- They're vs Their and similar normally denote uneducated native English speaker. The code might still be okay, but these typos passing to production makes me check code quality in case some similar QA mistakes are passed in the code.
- Grammar mistakes normally show a foreigner for whom English is not the main language. A small example just in the first line, "to create apps, games that run" => "to create apps and games that run", but this is normally due to a different language constructions. Similar to graphical softwares => graphical software.
So, kudos for OP to write the documentation in a non-native language! (upon light investigation it seems the main writer is French and his coworkers fix typos from time to time).
in germany only grammar nazi's would actually hate such things. they are too common, to say that only uneducated people do it. people who write code and distribute code to the whole world are not writers, there is no need for "perfect" grammar and typos. i mean in my first application i've written quanity instead of quantity (inside the code), somehow it slipped in a lot of places, but i think many many people who will read the code would still understand it. as long as the user interface is checked, i think it's okay if the readme/documentation has typos or grammar mistakes (on open source projects). the most important thing is, is that people understand each other/understand what it's all about. which is just fine for nidium.
- The writer didn't do proofreading (or did it but is not aware of the mistake).
- It's made by a single person with no one else to check on the documentation.
Now while they are not technically a display of low code quality, they are normally indicative of low attention to detail and lonely programming, which is not the optimal situation for high code quality. For people using English as the second language I'm a lot more forgiving since they and their coworkers might not even know how to properly express some things due to translation issues (and not due to lack of proofreading/lonely programming).
In my experience when I'm doing proofreading of my own libraries I also catch ambiguous sentences, lacking documentation or examples and many other things that could be improved upon.
Also nidium focus on mobile devices.
Are the needs of specific applications (or games!) influencing the feature set of Nidium?
But I was hoping for something like Electron/Node.js with a different/smaller engine like Ducktape. There seems to be a Chakra version of Node.js so this should be possible in the future.
The only heavy weight in this constellation remains Chromium...
VSCode gets around this by running an npm node locally.
- using Electron: 1 month
- using QT: 2 years
(by reusing the chrome context, your memory usage wouldn't grow unnecessarily for each new slack/spotify/whatever you open).
To push Chrome OS (where they will still be available) and to vendor lock-in people with Android apps.
Progressive Web Apps is where it's at.
Not many of them are good though, as it's hard to bind C++.
If you want to work with Qt, C++ is really the best option. And not many people know that language well enough. They know JavaScript though ;)
Given the discussion of the recent ReactXP thread, I'm guessing most people don't realize you can do this today. React Native supports macOS [1] and UWP [2].
Edit: There's even some early work on Ubuntu support [3].
[1] https://github.com/ptmt/react-native-macos
[2] https://github.com/Microsoft/react-native-windows
[3] https://github.com/CanonicalLtd/react-native/blob/ubuntu/REA...
Do you know if they have anything for linux yet?
You can also currently use React to share code across iOS [2], Android [3], UWP [4], macOS [5], web [6], VR [7] and a bunch of other stuff that is there mostly for fun (like React Hardware [8] and React Sketch.app [9]).
There's also experimental work on defining a set of primitives that works across all of these platforms [10].
[1] https://github.com/CanonicalLtd/react-native/blob/ubuntu/REA...
[2] https://github.com/facebook/react-native
[3] https://github.com/facebook/react-native
[4] https://github.com/Microsoft/react-native-windows
[5] https://github.com/ptmt/react-native-macos
[6] https://github.com/necolas/react-native-web
[7] https://github.com/facebook/react-vr
[8] https://github.com/iamdustan/react-hardware
[9] https://www.npmjs.com/package/react-sketchapp
[10] https://github.com/lelandrichardson/react-primitives
I think the choice is obvious at this point, if the Windows version is complete and stable, I will start using it instead of Electron.
https://en.wikipedia.org/wiki/Usage_share_of_operating_syste...
I would love to use React but if this is not addressed, there's no way I'm ignoring 1/2 users in the Windows ecosystem.
Is that the case or am I wrong? Can you run these React Native forks on Windows 7?
EDIT: Win 7 usage might be higher than is widely reported
https://www.netmarketshare.com/operating-system-market-share...
Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated parrot cartoon.
I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome does not cause any issues, as GIFs seem to be suspended when the window is not in view. CPU usage goes down to almost 0 when you switch away from your GIF-filled Chrome window. For Slack, however, it barely changes. A big shame.
(On that note, I wonder how much power is wasted by party parrots via CPU usage. Where I work at least one is almost permanently visible in any conversation as a reaction emoji, so it's probably not insignificant.)
Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs?
These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.
I find them both extremely useful in finding when I'm running wasteful software (either written by myself or someone else).
https://github.com/artursapek/dotfiles/blob/master/battery.r...
https://github.com/artursapek/dotfiles/blob/master/.tmux.con...
A better solution would be to have CI monitor CPU usage so that increases/decreases could be monitored and reported over time/per commit.
No, you should force every developer to have a shitty Core 2 Duo CPU from 10 years ago. A lot of devs are working on new shiny i7s and that will hide a lot of performance problems because it's a top end CPU. Do your testing on a cheap box and if it is still smooth then you can ship your product.
Every bug looks egregious in hindsight; just because an app has one is no reason to assume the engineers who made it don't bother to test anything.
Also: that particular issue only hurt idle CPU usage, and the usage was something like 13% CPU usage IIRC. It wasn't exactly the kind of thing that sets off klaxons.
Most bugs are of the form "do X then Y then it doesn't work". These idle CPU bugs are reproduced simply by opening the application.
I accept that 13% idle usage is invisible for most developers - but that's a bit disappointing. I notice stuff like this just by idly glancing at my CPU meter from time to time. An app that's sitting on high idle usage sets off klaxons for me.
I noticed a few moments after startup that the CPU usage jumped to the 5-7% range for a couple seconds, then it notified me that an update was ready (I assume it was downloading/checking/processing that update). I don't know if this is Electron, or just a general trend in desktop apps, but it seems to be getting a lot easier to update them. So when those pesky CPU/memory hog bugs are found, they can be quickly patched. As for the general trade off that comes with running an extra Chromium process, I suppose it's up to users/developers as to whether it is worth it in each case.
(I continue to be amused that everyone records & shares gifs for "compatability" and "simplicity", but many of the places they're shared re-convert them into videos.)
Holy fuck, can you imagine the supercomputers that were required to display Geocities websites in the 1990s?
Its also worth noting that blog post is from a few months ago. Its possible the slack team has fixed the issue now. I wouldn't know because I deleted the slack desktop app and haven't looked back.
I have Atom and Mattermost (Slack clone) running right now with very little avg. "energy impact". MM is at about a half gig in memory though.
You're paying for the codecs, might as well use them.
I find memory/cpu efficient applications not just useful but respectful to users specially when upgrading hardware is not possible due to financial or policy reasons.
What kind of hardware are you on as a developer?
I feel like I agree with most what's said there, the same would apply to NW.js and the likes.
This should be a heads up for GUI developers to [re]consider Qt and QML. It made real progress in the last few months. and there are some nice bindings to it.
I agree that Electron has its issue like having multiple copies of Chromium (and not Google Chrome).
Obviously native apps are better overall, but only if they provide a better UX. Being a vscode user, I don't know which native editor provides the same UX.
"Native" should mean that it uses native UI widgets offered by the platform itself, which hardly any editor does.
VSCode is clearly aimed at people who disagree with this statement. It's hardly a matter of objective fact.
Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release.
The proof is in Atlassian and Microsoft chasing after Slack on this. Very few people came forward to wave the "Let's just go back to IRC" flag.
It's shiny, new, you can drag and drop gifs and files into it, and it runs pretty swiftly (ignoring all of the obvious flaws). Most, especially less technical, users would find it a charm to work with. In my experience, they do -- and above all of the competitors.
The rest of your points are rather valid. But maybe its not so much obliviousness, as eagerness and impatience, and the reality of the market being as timely and pressing as it currently is. It's a race -- just like the telephone and the radio (for my point I'm ignoring the scale of impact here).
That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS.
> time to market
If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - and poor performance is a huge turnoff. Looking blingy and having all the features doesn't save an app with a 200ms lockup. or a 10% CPU at idle.
I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript.
Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.
Given that constraint, time to market becomes crucial as the huge cross platform barrier is significantly reduced by Electron.
It's also a demographic shift. Young developer's aren't coding in Java peak world anymore. We haven't even reached peak Javascript yet.
Software isn't just about making things fast as possible. You also have limited resources and have to make decisions on money in the bank, level of effort, engineer skillsets, competitive forces and market demand.
Ah yes. Someone who downvotes you, which you assume to be about the time to market comment of your argument, must naturally be a person "who is very mature and well seasoned in Java architecture".
What does that even mean to be "well seasoned in Java architecture"?
The flash analogy doesn't hold in any way. "Well, flash was errr ummm BAD you know.... and this electron thing it's BAD too .... err umm SAME AS FLASH!
Grumpy grump just wants to yell and stomp.
Every place I need to render text or make a thing respond to a mouse click I need to manually do all my own text layout and event handling and so on. (The app is in a domain where it needs special rendering -- I can't just reuse a system widget or library like Qt for this.)
Meanwhile, people are making apps similar to mine on top of Electron and banging out features way faster than I ever could. If they want some popup to have some bold text, or use the GPU to animate, or properly handle Arabic text layout, they get it all for basically free, they just need to bang out some divs. I am jealous.
It can be fine to prototype in Electron, or to make tools in it. But if you're making a chat program or anything similarly long-lived, it's the worst decision you can make for your user.
Go to Electron's website and download the demo (called API Demos). It's 3 processes and consumes 0.0 CPU on idle. Is it super efficient space-wise for what it does? Certainly not. And RAM usage is a valid concern. But churning CPU cycles on idle is not Electron's / Chrome's fault. I also suspect that if an app is behaving grossly on Electron, it's probably a bad actor within a generic browser environment, too.
My recommendation would be to not ship simple web apps wrapped in this huge machine without a good reason. But there are good reasons to use Electron or NW. It's just a poor choice when all you need is a thin wrapper around your website.
But I'd also argue that Flash could always be written to be efficient too. The problem with flash was never the little games people made. The problem was that one tab with a stupid punch-the-monkey banner add playing somewhere that would sit on 20% cpu even when the tab was in the background. I think Electron is similar, except in the desktop space. Well written apps seem to be able to keep CPU load down (although they still have a huge download and a huge RAM footprint). But there's been a running trend of noticing some dumb software running somewhere on my machine eating all my CPU. And in the last year or two its been an electron app, every time. Just like flash before it.
It seems deceiving to conceal that information when your call to action is to ditch Electron for the sake of performance.
Gotta agree with the other response here. If you have shown that what would seem to be much larger and more CPU intensive applications have been able to reliably perform well, why suggest moving away from electron instead of suggesting that users learn how to use it correctly, or perhaps suggesting that electron better educate users on how to use it correctly?
Can you please share how you came to the conclusion that Spotify is made with Electron? (hint: it's not)
The author is claiming it's built on Electron, which is false.
But there are a few differences between Flash and Electron that are not small. I mean the first thing is, Electron is open source in a open Standard, and have a fast development cycles to fix performance and security issues.
I think it's like a PHP situation. Electron is easy to use and sells itself as a cheap way to build apps, so this attracts lazy developers so we have a lot of problems, but that doesn't mean the technology is bad. But this is not a Electron problem, I mean web pages right now are heavy and slow for nor real reason. We need better fron-end developers.
I love VS Code, Hyper, and others, so maybe I'm biased, but I think Electron will be a interesting option to make desktop Apps something again.
For most of the computing world, desktop apps have never stopped being a thing.
I was thinking more in the Hype thing for new developers. You know like a small Renaissance in the Desktop UI/UX deparment, you know would be cool see beautiful desktop Apps in sites like Behance, Dribbble, etc spotting the first places, instead of the classic App with default OS UI or weird adapted ports of Mobile apps.
Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then?
Electron has won out because key apps have opted to use it and decided that the trade-offs of user CPU and battery are worth some amount less than their productivity as developers. Yes, there are alternatives to developing native desktop apps in JavaScript (I'm not sure I've seen React Native used this way, but it probably exists somewhere out there.) People opt for Electron because it's holistic, battle-tested and easy to use.
I'm not excusing Electron's (many) flaws. There should be a concerted effort by the team to "disable" parts of Chrome that don't make sense for native apps, or at the very least let it be configurable. He's right, there's no reason Slack should have access to the GamePad API (or WebVR, etc.)
My overall point is that like everything, productivity of the end-user is always going to have some kind of trade-off with the productivity of the developer (or more specifically, the business considerations of the company.) Always. We don't write assembly anymore even though the apps would be a gajillion times faster than writing Electron-wrapped web apps.
Now, complaining that Electron/Slack/etc. are CPU/battery-hungry is completely valid and a good discussion to have, but you only get me to jump into the HN comments once you start delivering global developer edicts with no regard for the other considerations those projects have made.
> The other sad fact is that even most developers have no idea that this is even happening on their computers. They run slack but have no idea how hungry it is. As a developer its your responsibility to know this stuff.
I'm not sure I completely agree here, "responsibility" is a bit heavy of a word.
> Users: Please complain more about slow programs. Its 2016. We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish.
Wait, this is the first instance (edit- second, but mentioned in passing in the previous paragraph) the author mentions "sluggishness" as a metric. IMO sticking with measurable stats like CPU and battery life are better because you have no idea if someone other than yourself experiences or even perceives this sluggishness. What about non-developers at BigCo that only run Chrome, Slack, Spotify, and Word? Would they feel sluggishness? I would guess not, since I rarely experience it as a developer on a Macbook using Chrome, Slack and Atom. (Things only get dicey when I start doing Vagrant stuff.)
> Also all you web devs: Go learn C or Rust or something. Your program runs on a computer. Until you know how that computer works, you're doomed.
Doomed to have a successful career? I prefer being "doomed" then. (For the record, I do know
> And until then get off my lawn shakes fist.
Aaaaand there we go. Maybe next time don't bury the lede? :P
> Oh, and read this talk on the website obesity crisis. Its very funny. And very sad. And very true.
This is an entirely separate concern (and one I agree with.) Heavy web pages are heavy because they are multi-megabytes to download, not because their "installed" wrapper (Chrome) is hundreds of megabytes.
I read Slack in emacs. I write code in emacs. I browse the web in emacs & Firefox. I play music via my phone's native Google Play Music client, although if I wanted to I could use emms, an emacs music-playing mode.
I have no desire to run some GUI-only, CPU-hungry, memory-ravenous, of-the-moment JavaScript nightmare of a program. My productivity as a developer is hindered by those things. I have no desire to write JavaScript: I'd rather write Lisp, or Go, or Python.
Yes, it's possible — and preferable! — to uninstall Slack, Atom, Chrome and Spotify. Try it today.
Side note; many of said devs also used OSX instead of linux, maybe some correlation there.
Emacs is where it's at. Really, it's my main operating system. Email, org-mode, erc for IRC, RSS reader, editor, twitTER, eww (for some things like documentation), dired for folder management etc. Currently working on learning ledger.
"Using a free version of vi is not a sin but a penance."
Food for thought. :)
One serious nitpick with you though. "Heavy web pages are heavy because they are multi-megabytes to download...) In my experience, heavy web pages are heavy because of the dozens of scripts being run on the pages, often based on bloated frameworks. Running uBlock and NoScript in advanced, I see it all, and I immediately think less of any site trying to load more than 3 scripts. Often I come across sites trying to run 20+. That's why the web is heavy today, not because the sites are huge to download.
[1] http://idlewords.com/talks/website_obesity.htm