Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Electron is flash for the desktop (2016)

josephg.com

Post reply on HN
Print view View original

41–50 of 1001 posts

Re: Electron is flash for the desktop (2016)

#41

Post by Longhanks »

fknop wrote: post #25

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.

Re: Electron is flash for the desktop (2016)

#42

Post by alkonaut »

Ambroos wrote: post #18

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 par…

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.

Re: Electron is flash for the desktop (2016)

#44

Post by feelandcoffee »

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.

Re: Electron is flash for the desktop (2016)

#46

Post by lazarus101 »

cgh wrote: post #45
lazarus101 wrote: post #15

In most cases it's either an Electron app or no desktop app at all. It's simply not feasible to write native apps.

Qt exists and is really nice to work with. It has multiple language bindings. How is it unfeasible?

Development time needed to create desktop apps (for Windows, Mac and Linux) given that there's already an existing webapp:

- using Electron: 1 month

- using QT: 2 years

Re: Electron is flash for the desktop (2016)

#47

Post by Andrex »

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

Re: Electron is flash for the desktop (2016)

#48

Post by mijoharas »

migueloller wrote: post #16

> 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]. [1] https://github.com/ptmt/react-native-macos [2] https://github.com/Microsoft/react-native-windows [3] https://github.c…

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

Do you know if they have anything for linux yet?

Re: Electron is flash for the desktop (2016)

#49

Post by Mithaldu »

Ambroos wrote: post #18

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 par…

Note that you need to multiply your percentages by cpu core number.

Re: Electron is flash for the desktop (2016)

#50

Post by wfleming »

Ambroos wrote: post #18

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 par…

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

Post reply on HN