Why the dislike of Electron apps?

Interesting. More out there than I anticipated.

The newest Evernote iteration is built with Electron and the performance is ABYSMAL compared to the legacy app (which I went back to using as my daily driver on Mac).

Evernote is electron now and it sucks :exploding_head:

I avoid electron apps because they make a huge difference to battery life. I work all day without charging, and when I had to use Slack or Teams (thankfully I don’t use have to them anymore on my Mac) I noticed 2-3 hours less battery time a day. Now, I won’t agree to use another Electron app ever again, as it means having to find time to charge my laptop, which is not something I’m willing to do for an application. I also find these apps perform terribly compared to native apps.

Yes. That’s a good way to look at it.

If you can run 4-5 active electron apps where you could have run, say, 6-8 equivalent native apps, you have a rough idea of how much functionality Electron is costing you. And that’s before any sluggishness in UI and web app conventions where system/native is expected.

Granted this must be weighed against the value of the existence of apps that might not otherwise have been developed, which is why I’m more appreciative of Electron versions of apps that are adding features rapidly.

Evernote started sucking years ago. :smiley:

4 Likes

Nice use of the find and cut commands to sleuth out the electron-dependent apps on the machine. Very elegant, especially how you took care to clean up the output.

I have three on my system: github desktop; Slack; and Teams. I don’t use Teams. Slack seems fine. I like Github Desktop to have a quick way to pull up repositories when I’m not in the terminal; however, I find that I usually have to force quit it at some point because it seems to be an enormous drain on system resources. I’ve never measured it, so my experience may be anecdotal. But it becomes unstable and my whole system starts behaving oddly. I always suspected it was an Electron issue, which may not be the case.

Also, I’ve checked out VS Code on Linux. I know people seem to like it, the app feels “heavy” and sluggish to me.

So, my own experience with Electron-based apps does not give me great confidence with it.

1 Like

Trello is Electron. I appreciate that it presents a consistent UI because my team is not mac-centric and I absolutely need a cohesive, easy way to monitor their progress on projects. Trello does just what I need/want, I only fire it up when I need it, and it also works on my iPad.

I discovered that GeoGebra is also Electron. I don’t care here either. Again, in the world that I have to work, students are not all mac-Centric. When I have to demonstrate a formulation in a graphical way, I must be able to do so without the confusion they will face to translate my mac-UI to their Windows-UI.

In summary, the fact that I must have consistency in UI behavior to the Windows world trumps the fact that I don’t have access to the full mac-centric UI bells and whistles on the two apps.

For my own world of apps … yes, absolutely. I have yet to find an app that is not developed to the macOS paradigm that does not at some point make me feel as though I am working in something akin to Windows-emulation mode.


JJW

Fromm accessibility point of view, many web pages are half accessible or some times you can’t even navigate on them at all. Therefor native apps often brings better experience than on the web. For example MS teams. Both on the web and their macOS ‘app’ is garbage and difficult to use.

Here is another specific use case. As VoiceOver user on each web page after it loaded VoiceOver announce: name of web page, web content. So whenever I open electron app I first get reminded that it is electron version. Also electron apps don’t care about accessibility so much, because they are basically web pages.

3 Likes

Teams on Windows is pretty terrible as well.

Also electron apps don’t care about accessibility so much, because they are basically web pages.

This could probably be improved if the developers put some effort into it. They just don’t for whatever reason.

Many developers not aware about accessibility. Since I could see before, I understand why. Because it’s a smaller group and simply they don’t have experience with how to use their devices with accessibility features turned on a daily basis. For example one of third-party apps can have a visual bug it will be fixed in few days, versus VO bugs can be ignored years after years.

Now when many apps switched to subscription models and says that they can now work on new features and fix bugs instead of thinking about how to increase sales of their apps. Guess what, Day One have unlabeled buttons in their UI both on macOS and iOS over a year(when I discovered it, I guess it was longer than a year) and still not fixed. Now before I subscribe to new app, I make sure that app is actually is fully accessible since they say that subscription lets them roll out new features and bug fixes more quickly. For you who is not familiar with unlabelled buttons in VoiceOver UI, you simply need to give a name to button in your code. So it’s not about rewriting hundreds lines of code. We don’t ask about complex features, just give this button a dann name.

Imagine if you open an app, and there’s no buttons. Functionality is there, but you can’t access it. You can try to randomly tap somewhere and hope that you hit the right button, but it’s a not funny game to play.

Also about developers in general, I guess they don’t know how many people use different accessibility features. They also lose bit of sales if their competitor offers a accessible version.

Sorry that my post became very off-topic, but applications nowadays can easily provide me a lot of irritation.

7 Likes