Please switch from Electron

[StjepanBM1]

Rufus (written in C) is much faster than your bloated Electron mess.

I was mounting Arch Linux ISO on my USB, Rufus took about 3-4 minutes. Balena Etcher took 14 minutes (validation not included). So please at least switch from Electron.

[Andrej123456789]

Yeah, Balena is slower than Rufus but maybe isn't Electron guilty for this, maybe is the code

[thedocbwarren]

Device access requires some native code that is handled via a plugin (for lack of better description) that the electron app calls. I can't speak to the speed but it's using something native to access devices.

[rradar]

Electron is not only a big horse shoe (etcher was already 0.5GB years ago!) but also often a security mess...

Device access requires some native code

Not sure why that needs electron - usbimager can do everything (including respecting the users privacy) and comes in a executable package of less than 0.5MB for all platforms you can imagen.

Rufus took about 3-4 minutes. Balena Etcher took 14 minutes

The linked website claims for "Compressed write time (4)":

balenaEtcher 01:12:51 USBImager 30:47

I think this times we are even more in need for efficient and small software.

[StjepanBM1]

I haven't treied USBImager. I was just using Rufus as example because I used it often, and I think that it is a greate example of time difference. When it comes to smaller ISO images balenaEtcher is OK. But when it comes to big ISO images, balenaEtcher is very slow.

[zwhitchcox]

Hi, electron is the front end and doesn't have much of an effect on performance. The libuv library is responsible for the I/O parts of etcher and is very fast, runs multithreaded automatically, and is battle tested on servers with high throughput need.

We will eventually probably move on from Etcher, but as of now, it's a fairly good solution for us.

I was mounting Arch Linux ISO on my USB, Rufus took about 3-4 minutes. Balena Etcher took 14 minutes (validation not included). So please at least switch from Electron.

This does not seem right. Etcher should be as fast/faster than Rufus for ext4 images unless something is wrong. Are you running Etcher on the same machine and same target USB device as you are running Rufus? If you are not using the exact same setup, there could be a bottleneck other than Etcher.

If not, are you just using the plain download from the arch website? If so, I can test on my machine and see if I get similar results.

[rradar]

Hi, electron is the front end and doesn't have much of an effect on performance.

There is a BIG difference in performance actually. usbimager starts virtually instant on my machines while etcher used to (not using this *ware anymore) always take seconds to present the gui!

[lurch]

We will eventually probably move on from Etcher,

I assume you meant to write "Electron" there? :wink:

[zwhitchcox]

I assume you meant to write "Electron" there? 😉

Haha, yes

There is a BIG difference in performance actually. usbimager starts virtually instant on my machines while etcher used to (not using this *ware anymore) always take seconds to present the gui!

Right, well, that's just loading time for the GUI, I was meaning flash time. We are working towards segregating the view from the controller. After that, it opens a lot more options to use, like using webview or React Native. This is a medium level priority though, and we currently have a few high-level priorities we are taking care of.

[zwhitchcox]

@mcraa The people want webview!!

[Andrej123456789]

Guys, you should try Tauri

[zwhitchcox]

@Andrej123456789 That is on the list...unfortunately, it would involve rewriting our entire back end in Rust for now though

[Andrej123456789]

It is hard job but in long run it might be better but we can still use usbimager and Rufus if we have working Windows installation

[rradar]

@Andrej123456789 usbimager is available for literally all platforms!

It would be funny (or sad) to calculate what energy etcher is wasting when downloaded and burning a image and then to compare it to other solutions which have magnitudes smaller binaries and no dependencies, adware, spyware etc. included.

[zwhitchcox]

@rradar

adware spyware

Etcher doesn't have adware or spyware. There is some minimal telemetry data for internal Balena use and features of the latest Balena projects, some of which are user driven. We don't sell ads to anyone.

@Andrej123456789

I've started hacking together a Tauri version of Etcher, as we have a policy similar to Google's 20% rule...I'll let you know how it goes! it seems like a lot of users want this.

[Andrej123456789]

Great

[rradar]

Etcher doesn't have adware or spyware.

I actually have no idea how it is nowadays (don't use that *ware anymore) but in the past there were hell lot's of connection to all over the world when only opening etcher (most of them were included "unintentional" once discovered :thinking:)

• 3784

• 3476

• 3006

• 2977

• 2914

• 2890

• 2766

• 2599

• 2497

• and more...

Most of the closed issues are not (technically) resolved and therefor closed (some even with censored posts) but only because dev's don't have/show interest in that problems :warning:

Also in my world software which only runs with ads is considered adware (that would be certainly qualify etcher for adware). :put_litter_in_its_place:

But like said before: I really don't think there is much use left for etcher because there is privacy respecting alternatives with a fraction of the size like usbimager available that probably fits most users much better and does not have such a negative impact on the environment. :star2:

Beside it looks like etcher is a possible security nightmare and uses EOL electron for example :skull_and_crossbones:

[StjepanBM1]

Any updates on this issue?

[thedocbwarren]

Sorry but this feels like an off topic since the electron question was already answered and 'other' stuff creeped in.

[mcraa]

Thanks for chiming in @thedocbwarren. Yes, sadly, this and some other issues were driven off-topic.

@StjepanBM1

Any updates on this issue?

If "this" refers to the original question, let me close with a summary

• There are plans (research/experiments/POCs) to move away from electron
• replacing electron won't happen from one day to another

• the first step (in progress) is to clean up/rewrite the current version, meaning

  • get rid of outdated packages / deprecated APIs
  • create a structure that is easier to maintain / extend / migrate

  Then this "middleman version" could be migrated with smaller effort to (tauri, browser, webui, whatever)

[Andrej123456789]

If you already planning to move away from Electron, this issue should be open because nearly everyone says that they are doing something but then they close issue and doing nothing.

Acts, not words @mcraa

If you are planning to stay on Electron, that is ok, just say you want stay and then close issue

Also Electron don't support Windows 7 anymore

[aethernet]

"Planning to" doesn't mean it's the highest priority and that everyone will drop everything else to do it. This is open source and free software, you're all welcome to contribute a PR.

That being said the project that are showcased in the app are community driven project on our own platform. You can call that what you want but running the balena cloud platform is what actually fund the development of etcher. As my colleague said earlier we don't sell advertisement to anyone.

Telemetry is actually quite limited, anonymous and easy to turn off.

Again this is free software that you're welcome to fork...