Hacker News Reader

Comment by morpheuskafka | Hacker News Reader

That's fine for someone who already keeps current with front-end stuff, but someone who is a desktop app developer is more likely to just go native than try to make a desktop app that tracks 3+ browser engines of wildly varying versions (luckily 7 is out of support now, but it still might be desired to support for some desktop apps in which case now you have IE to deal with). Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.

View on HN

> Electron gives the promise of total code re-use across platforms which is what makes web technologies more suitable for desktop apps.

I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app. Instead of writing platform specific apps that leverage the power and capabilities of those platforms, we get a jack of all trades and master of none. Electron is a business decision, not an enlightened technical one.

What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.

> I am not sure what the point is of Electron: a shitty-resource hungry app that literally is a wrapped web-app

The point is that its effectively a web app.

> What value does electron add to the user?

They have a desktop app faster than if it was being built natively.

Or at all, how many Electron apps would bother with native Linux clients for example. Some maybe but certainly not all and probably not most either.

Electron app is not a native Linux client, it is just a browser app. If you ran that app in a tab it gives you much better performance and less memory used.

That all depends on how the app is written. The idea of Electron is to bring the web app frontend experience to apps which are fundamentally not able to run in a browser, such as VS Code, Etcher, etc. Writing to raw device files, listening to ports, using the full CPU resources and timers not available in the browser, using more memory, etc.

If you just package an existing website into an Electron app that is a waste of time and user resources. Electron is intended to combine a web-based presentation/UI layer with a Node.js layer that supports access to native resources, unlimited storage, persistence outside the browser, etc. If you are not making meaningful use of these capabilities a PWA would be sufficient.

Overall, I do prefer native apps, although there are examples out there such as VS Code that have achieved UI excellence without it. Although, I really only like that on macOS... on Windows I prefer the older Windows Forms style rather than the new Modern UI, and on Linux there is a bit of style mismash between Qt and GTK apps already.

Electron exists because there's a horde of developers whose only tool is a JavaScript hammer, so every problem looks like a nail. That's how you end up rewriting `dd` for Chrome[π].

π: https://www.balena.io/etcher/

My god... a 200+ MB install footprint, 200+ MB of RAM usage, requires a beefy GPU just to render its window. How did we get here?

I think we got there also by desperation of lacking good cross-platform GUI toolkits.

The current state is, you either use something that looks like Windows 95 in all platforms, or web app.

What the web made possible is to anyone to create a decent custom UI with little effort. I still remember how messed up was to create a custom component for Java Swing, which I believe is still one of the easiest to do. How would you do that for QT? GTK? WxWidgets? etc

I'll take Win95 in a heartbeat; consistent, accessible, responsive and clear. Vastly superior to the majority of web interfaces.

Also totally inflexible, you better have the right-sized screen/resolution: too small and you can't see that "ok" button; too large and you'll have a ridiculously small and crammed winform to fill/see your information.

Most cross platform toolkits support layout managers, since Motif days.

Actually even WinForms supports them, even though too many are happily doing fixed canvas positioning without using them.

Windows has shipped an accessibility magnifier since the 90s, before hidpi was a thing.

Take a look at Telegram client, looks great on Linux, not sure how it looks on macos or Windows.

Interesting Telegram has both a native (Swift/Obj-C not sure which) and an cross-platform-codebase app for macOS. The former is called Telegram for macOS and the latter Telegram Desktop. Both are on the app store even. So it would actually be a very good case to compare performance, etc. The native one presumably shares a lot of code with iOS which is probably why it exists at all, and it supports secret chats. Otherwise they have similar but slightly different design and features.

However, I think the Telegram Desktop client is not Electron either, it is just regular C++ compiled on different systems.

Yes, Telegram Desktop is a normal C++ app: https://github.com/telegramdesktop/tdesktop

So a cross-platform is quite easy, Electron one would need to be tested for different webviews on each system.

I might be crazy, but for me it's faster and more convenient to download and run Etcher than to read up on dd command arguments and device paths. Storage space is plentiful for me. RAM isn't an issue as it's only run once in a blue moon.

Is it crazy bloated and resource hungry for what it does? Undeniably! Does it matter? Not for me.

Electron resource use can be painful for apps that are running constantly, like Discord, VSCode and Slack. For utilities like Etcher, who cares.

I realize I'm replying six days later - but I can't help mentioning that the "dd situation" is even crazier than it first appears: you can just use `cp foo.iso /dev/sdb` or `cat > /dev/sdb`.

https://unix.stackexchange.com/a/189091/220387 https://eklitzke.org/the-cult-of-dd

The actual duplication is done in the Node.js runtime, not the V8 runtime inside of the Chromium GUI layer.

I do wish they had a command-line version that just ran node without Chromium, but there is a use-case to have a simple foolproof application like this; these days there are a lot of people who need to image drives like this and would be best not to mess with dd on their first time.

And dd doesn't exist for Windows so you've got to use some tool or another like this.

In fairness, for some reason Etcher works sometimes when other things don't.

It might be because it is slower and doesn't overheat my usb sticks, I don't know, but if nothing else works you can try etcher.

(Not sure how I found out, can have been something I read or a recommendation by a colleague 3 a 7 years ago or something.)

Electron should be banned for the environments sake if the other reasons doesn't persuade, it's inefficient computation to energy ratio using Electron apps, when there is a lot of users like with VSCode or Slack it probably affects the global climate in a negative way

Let's ban anything not written in assembly.

Second that

I see a lot of people in the tech industry deeply concerned with human impact on the environment and our diminishing prospects of repairing it without drastically altering our lifestyles. At the same time the general consensus in the tech industry towards the steady increase in power requirements for everyday computing seems to be indifference.

These two viewpoints cannot be reconciled.

Every month when this Electron discussion comes up there are so many who dismiss the egregious resource usage outright on the basis that it's trivial for modern computers. I'm one of those people who use Thinkpads in 2021 for my personal computing and have no problems with it. I will never buy a Mac, and I don't want to unnecessarily spend hundreds of dollars on a modern system when refurbished ones from a decade ago work so well. I avoid Electron apps on the basis that they flatten my battery quickly. I switched from using vscode to vim on my x200 and my battery life tripled, I'm not even exaggerating here either.

No, they are completely reconcilable. The amount of power it takes to run a powerful consumer CPU is trivial compared to the amount of power used in many other common applications like heating, vehicles, etc. This effect is particularly pronounced when you consider that laptops use way less energy than desktops (on average) and mobile computing as a whole is displacing desktops outside of niches like PC gaming.

The environmental issue doesn't make sense IMO, but increasing hardware requirements does have real impact on accessibility.

These effects scale. If every single laptop uses a small amount more power than is necessary, the relatively minor increase in energy use for one computer totals up to a significant increase in overall energy usage. Not to mention the unnecessary obsolescence of hardware. The externalities of manufacturing new hardware - and disposing of old hardware - are extremely significant. Just so what? So my perfectly good 10 year old laptop has enough RAM to run 6 Electron apps at once?

Sure, your ceiling lights use less energy than your fridge. That's not a justification for everyone to completely ignore turning them off when not needed.

Even if they add up, they still pale in comparison to the amount of energy you can offset with a couple of windmills.

No joke, if it weren't for the resource usage of vscode and the couple of other Electron apps I rely on, I wouldn't consider upgrading my workstation (which is already new enough to be energy efficient enough but maxes out at 24GB RAM) but here we are.

> it's inefficient computation to energy ratio

Probably true.

> affects the global climate in a negative way

If electricity consumption of all computers in the world doubled because of Electron apps, the total annual electricity consumption would increase by 0.01%. So probably false.

In 2012 PCs (only PCs, not network appliances, not data centers, not phones...) were estimated at 1.5% of global electricity use, so you're off by a good margin. And that is deeefinitely not negligible, nor is the need (and eco impact) to buy newer computers because a 2016 MacBook Pro is unusable when your work requires 4/5 electron apps side by side.

I stand corrected. Turns out I forgot to multiply by 365 days/year. The real figure is indeed in the ballpark of 2%.

Maybe not banned but they could do a carbon tax like they do with motor vehicles. Or maybe like with appliances where you have an energy rating, with stickers telling you how much electricity it will use per year, possibly with tax incentives to pick the most efficient.

Problem is: how to test that? Even with the most straightforward tests, there are cheaters. Appliances have a special "eco" mode to meet the specs that most people won't use because it barely does the job. And for cars, well, VW have shown us how far companies are ready to go.

> Instead of writing platform specific apps

You've answered your own question as to why people write then.

> What value does electron add to the user?

It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.

For an app with no source available publicly, I would much rather have a web app in a sandbox than a "native" app (whether native or electron-style) that I would have to trust.

> It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all.

I prefer web versions of those apps on Linux than electron. Sorry, I want to run just one browser and it is not Chrome based one.

And for sure Electron apps don't allow that ease of cross platform development as one thinks, I would argue that it is on the same level as a native app with good abstraction library (see Telegram client source on github).

It is more that they don't want to hire desktop developers (or just ones that want to learn something else than JS).

> It adds a lot of value to Linux and to a lesser extent Mac users: before a electron a lot of apps didn't have a version for these platform at all

What value does _this_ add over a web app?

I've been an exclusive Linux user since college so I'm aware of the disadvantages of app/service unavailability (I remember the dark days of running Netflix in a windows VM that I barely had enough RAM to run...).

But what's the advantage of using the Slack app over a browser tab? This is a sincere question, since enough people reference the benefit of faux-native wrapped webapps that I assume there's some value.

I seem to be the only one in my company who doesn't use Slack's app, and I'm always shocked when I see a colleague's computer freeze and have them say "ugh it's almost definitely the Slack app". I work in autonomous vehicle engineering, so these are _monster_ machines I'm talking about, capable of running the entire car's stack locally. The only advantage I can think of are desktop notifications, but 1) I'm pretty sure browsers support those and 2) is that really worth using an app that's amateurish enough that it freezes your computer regularly?

I'm on Ubuntu and use the Slack app, which never causes any freezes or anything of the like. The advantages is that i know where it is ( in my taskbar and launcher) compared to it being one of my 500 open tabs, and the taskbar icon shows if i have unread notifications or messages. Furthermore, i can use it with multiple workspaces at the same time.

I feel like the push towards PWA where you "appify" those websites rather than running another instance of a full blown browser would be good indeed.

Ah yes, the panel icon. This makes a lot of sense, thank you! My os is _heavily_ customized (i3 + wmctrl + heavy scripting), so I forget sometimes what the standard floating-window workflow looks like and how difficult it can make it to manage and quickly access important windows/tabs.

> What value does electron add to the user? I would argue none. That Slack can’t find the resources to write actual Swift for a Mac App is just amazing to me. Instead we are essentially interacting with a lowest-common-denominator web app. Is a chat app that hard to write natively? We’d get better performance, a smaller footprint, and a more polished, platform-specific product.

Exactly, one can look at Telegram app, it is clean, polished and open source client written as a native app that works across many platforms (and one of few that has Linux client).

Honestly, this site is the only place I really hear about the supposed horror of electron. The resource issue doesn't seem to effect me or people in the 7 slacks I'm in all day.

My 6 year old MacBook runs slack, Xcode, android studio, safari, chrome, messages, vs code, vim, iterm2, preview, battle.net and hearthstone all the time without issue, really.

I think for the average user, they'd rather have more features across platforms more quickly than a smaller resident memory footprint and install size.

For a counter-anecdote, I've seen the Slack app freeze up colleagues' workstations many times, and these are monster machines designed to run an autonomous vehicle stack on raw sensor data.

Reply on news.ycombinator.com