Hacker News Reader

Comment by zarzavat | Hacker News Reader

Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there.

The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.

View on HN

A similarly bad problem is that Electron apps by default does not adhere to the operating system conventions and API:s, and often also does not use the the features which makes the OS good.

For example all Electron apps I use have their own implementation of a spell checker rather than hooking into the system one. Normally in Mac OS if I add a word to the system dictionary all apps will learn that word, but in each Electron app I will have to do it again, and again, ...

Many also implement their own UI widgets like basic buttons and input fields whose UX is not at all in line with native apps.

Most consumers don't care about native controls. In fact for a company it's more important to have a unified UX across all devices so that the user can pick up easily from one to the other, ie Macbook to iPhone. Slack is a good example of this.

Strong disagree with your assumption. I __hate__ unified controls across devices. When I am on an iOS device I want iOS controls, not the same as I have on Windows, and on Windows I want Windows controls, not something kind of like Mac OS. And I am 100% certain pretty much every consumer would actually agree if they were given the opportunity and knowledge about the situation, and the "unified" look is just something developers like me lie to ourselves about since it is easier to do it with Electron and not spend time and energy to do a properly good user experience.

Well I can tell you having doing user interviews about precisely this topic for our teams that users really don't care about device specific controls and we've found that it's really devs that care a lot about it, and even then it's been specifically Apple users. Windows or Linux users didn't care as much, although Linux users cared a bit more than Windows users. Most of our interviewees said they either don't care or prefer unified controls per app.

I guess you limit your context to your own application and not the entire computing device and therefore you get flawed results.

No, we never asked them about our own application specifically, it was about what they preferred generally across all of their devices. So, no flaws here. You may just be projecting your own bias for OS specific controls onto the general populace.

I highly doubt your research was so perfect, since it seems it wasn't even peer reviewed and published, so that conveniently nobody can point out methodology flaws.

I never said it was some peer reviewed study, just that we did it for our team to figure out how to lay out the UX, that doesn't mean it's not statistically and methodologically valid. It seems you are also trying to project your biases on top of my comment so as to question any sort of research that we conducted.

Yeah because it doesn't really match with the state of the art.

What is the state of the art then? Where are your peer reviewed studies on this topic?

How are controls unified when on a device you have a mouse and 400cm² of space and on another you have a finger and 60cm² of space?

Notice that the Slack app has a similar layout on both mobile and desktop, with a list of teams on the left, followed by channels, followed by the channel content. There are no device UI framework specific elements anywhere, it doesn't use iOS or Android style buttons nor is it designed with Fluent Design on Windows or HIG on macOS.

Agreed that this is a good example where designing for everyone ends up with a worse product for everyone. Same thing goes for Teams, GitHub Desktop, and Postman.

It's horrible having to constantly context switch _within the operating system I am using right now within this very moment_. Context switching when switching devices is not a problem at all.

I wouldn't say worse, I appreciate not having to context switch between different devices.

The RAM usages comes with cache misses. It's NOT efficient. Just because you have a monster machine, doesn't mean it's efficient

If somebody just made Electron into a HTML/CSS/JavaScript engine capable of opening just the HTML/etc parts from, say, an HTTP server, and then shipped it to all users worldwide...

Heh

I wonder if anyone did that comparison, an Electron app vs Chrome + a local copy of node+express whatever running the backend

Why does it have to be node and express? You can compile lightweight Go, C++, Rust binaries.

The RAM usage is from JavaScript heaps, not from multiple copies of the binaries.

(There basically aren't memory metrics that can show the effect of binary sizes on macOS. It'd show up as disk reads/page ins/general slowdowns instead, but SSDs are so fast that it's very hard to see one.)

Multiple copies of the same binary can't share a memory page for the code. They do take more RAM.

And there are no metrics you can look at to see the impact of this, so it's not contributing to any of the metrics you are seeing, as I said.

It has been solved decades ago: it’s called a browser.

Reply on news.ycombinator.com