3 ms·

The article is kind of right about legitimate bloat, but "premature optimization is evil" has become an excuse to stop thinking about efficiency entirely. When

The article is kind of right about legitimate bloat, but "premature optimization is evil" has become an excuse to stop thinking about efficiency entirely. When we choose Electron for a simple app or pull in 200 dependencies for basic tasks, we're not being pragmatic, we're creating complexity debt that often takes more time to debug than writing leaner code would have. But somehow here we are, so...

rossant 11mo ago
Yes. Too many people seem to forget the word "premature." This quote has been grossly misused to justify the most egregious cases of bloat and unoptimized software.
- SurceBeats 11mo ago
  Yeah, somehow it went from don't micro optimize loops to 500MB Electron apps are just fine actually hahaha
  - cpt_sobel 11mo ago
    The latest MS Teams update on MacOS fetched an installer that asked me for 1.2GB (Yes, G!) of disk space...
    - thaumasiotes 11mo ago
      I recently set up a new virtual machine with xubuntu when I stopped being able to open my virtualbox image. Turns out modern ubuntu will only install Firefox as a snap. And snap will then automatically grow to fill your entire hard drive for no good reason. I'm not quite sure how people decided this was an approach to package management that made sense.
    - xigoi 11mo ago
      I recently found out that Teams was taking up over 5 GB on my laptop. The incompetence of Microsoft developers knows no bounds.
  - stared 11mo ago
    I hope Tauri gets some traction (https://v2.tauri.app/ https://v2.tauri.app/). The single biggest benefit it drastically smaller build size (https://www.levminer.com/blog/tauri-vs-electron https://www.levminer.com/blog/tauri-vs-electron). A 500MB Electron app can be easily a 20MB Tauri app.
    - brabel 11mo ago
      Not sure. Tauri apps run on the browser and browsers are absolute memory horders. At any time my browser is by far the biggest culprit of abusing available memory. Just look at all the processes it starts, it’s insane and I’ve tried all popular browsers, they are all memory hogs.
      - peterfirefly 11mo ago
        Electron apps also run in a browser. They package an entire browser as part of the app.
      - dspillett 11mo ago
        A big complaint with Electron that Tauri does avoid is that you package a specific browser with your app, ballooning the installer for every Electron app by the size of Chromium. The same with bundling NodeJS (or the equivalent backend for Tauri), but that isn't quite as weighty and the difference is which backend not whether it is there at all or not. In either case you end up with a fresh instance of the browser (unless things have changed in Tauri since last time I looked), distinct from the one serving you generally as an actual browser, so both do have the same memory footprint in that respect. So you are right, that is an issue for both options, but IME people away from development seem more troubled by the package size than interactive RAM use. Tauri apps are likely to start faster from cold as it is loading a complete new browser for which every last byte used needs to be rad from disk, I think the average non-dev user will be more concerned about that than memory use. There have been a couple of projects trying to be Electron, complete with NodeJS, but using the user's currently installed & default browser like Tauri, and some other that replace the back-end with something lighter-weight, even more like Tauri, but most of them are currently unmaintained, still officially alpha, or otherwise incomplete/unstable/both. Electron has the properties of being here, being stable/maintained, and being good enough until it isn't (and once it isn't, those moving off it tend to go for something else completely rather than another system very like it) - it is difficult for a newer similar projects to compete with the momentum it has when the “escape route” from it is generally to something more completely different.
  - bluetomcat 11mo ago
    And consequently, "you need 32GB of RAM just to be future-proof for the next 3 years".
0xEF 11mo ago
Thinking is hard, so any product that gives people an excuse to stop doing it will do quite well, even if it creates more inconveniences like framework bloat or dependency rot. This is why shoehorning AI into everything is so wildly successful; it gives people the okay to stop thinking.
nly 11mo ago
Fortunately many apps seem to be moving to native webviews now instead of shipping electron
eitau_1 11mo ago
The sad reality is that easy tech explores solution space faster
matusp 11mo ago
What is often missing from the discussion is the expected lifecycle of the product. Using Electron for a simple app might be a good idea, if it is a proof-of-concept, or an app that will be used sparsely by few people. But if you use it for the built-in calculator in your OS, the trade-offs are suddenly completely different.
- pjmlp 11mo ago
  A large majority of Electron crap could be turned into a regular website, but then the developers would need to actually target the Web, instead of ChromeOS Platform and that is too hard apparently.
  - Incipient 11mo ago
    I've recently gone back to more in depth (but still indie) Web dev with vuejs and quasar, and honestly I don't even find myself thinking about "targeting Web" any more - I just write code and it seems to work on pretty much everything (I haven't tested safari to be fair).
    - jtbaker 11mo ago
      Vue is so good! I've been encouraged seeing more organizations mentioning using it (in the hiring thread etc.) lately.
m-schuetz 11mo ago
I'd argue that the insane complexity of fast apps/APIs pushes many devs towards super slow but easy apps/APIs. There needs to be a middle ground, something that's easy to use and fast-enough, rather than trying to squeeze every last bit of perf while completely sacrificing usability.
- immibis 11mo ago
  Java Swing? It was slow in 1999, which means it's fast now. It's also a much more sensible language than JavaScript. It's not native GUI, but neither is JavaScript anyway.
  - m-schuetz 11mo ago
    Swing has no place in a sentence about good usability. It may be the best of the worst, but it's not a positive example. Things like html or Imgui are better to use, with the former also being much more powerful and the latter being as simple as can be while still being blazing fast.
sublinear 11mo ago
On the flip side, what you're saying is also an overused excuse to dismiss web apps and promote something else that's probably a lot worse for everyone. I've never seen a real world Electron app with a large userbase that actually has that many dependencies or performance issues that would be resolved by writing it as a native app. It's baffling to me how many developers don't realize how much latency is added and memory is used by requiring many concurrent HTTP requests. If you have a counterexample I'd love to see it.

rossant 11mo ago

Yes. Too many people seem to forget the word "premature." This quote has been grossly misused to justify the most egregious cases of bloat and unoptimized software.

SurceBeats 11mo ago
Yeah, somehow it went from don't micro optimize loops to 500MB Electron apps are just fine actually hahaha
- cpt_sobel 11mo ago
  The latest MS Teams update on MacOS fetched an installer that asked me for 1.2GB (Yes, G!) of disk space...
  - thaumasiotes 11mo ago
    I recently set up a new virtual machine with xubuntu when I stopped being able to open my virtualbox image. Turns out modern ubuntu will only install Firefox as a snap. And snap will then automatically grow to fill your entire hard drive for no good reason. I'm not quite sure how people decided this was an approach to package management that made sense.
  - xigoi 11mo ago
    I recently found out that Teams was taking up over 5 GB on my laptop. The incompetence of Microsoft developers knows no bounds.
- stared 11mo ago
  I hope Tauri gets some traction (https://v2.tauri.app/ https://v2.tauri.app/). The single biggest benefit it drastically smaller build size (https://www.levminer.com/blog/tauri-vs-electron https://www.levminer.com/blog/tauri-vs-electron). A 500MB Electron app can be easily a 20MB Tauri app.
  - brabel 11mo ago
    Not sure. Tauri apps run on the browser and browsers are absolute memory horders. At any time my browser is by far the biggest culprit of abusing available memory. Just look at all the processes it starts, it’s insane and I’ve tried all popular browsers, they are all memory hogs.
    - peterfirefly 11mo ago
      Electron apps also run in a browser. They package an entire browser as part of the app.
    - dspillett 11mo ago
      A big complaint with Electron that Tauri does avoid is that you package a specific browser with your app, ballooning the installer for every Electron app by the size of Chromium. The same with bundling NodeJS (or the equivalent backend for Tauri), but that isn't quite as weighty and the difference is which backend not whether it is there at all or not. In either case you end up with a fresh instance of the browser (unless things have changed in Tauri since last time I looked), distinct from the one serving you generally as an actual browser, so both do have the same memory footprint in that respect. So you are right, that is an issue for both options, but IME people away from development seem more troubled by the package size than interactive RAM use. Tauri apps are likely to start faster from cold as it is loading a complete new browser for which every last byte used needs to be rad from disk, I think the average non-dev user will be more concerned about that than memory use. There have been a couple of projects trying to be Electron, complete with NodeJS, but using the user's currently installed & default browser like Tauri, and some other that replace the back-end with something lighter-weight, even more like Tauri, but most of them are currently unmaintained, still officially alpha, or otherwise incomplete/unstable/both. Electron has the properties of being here, being stable/maintained, and being good enough until it isn't (and once it isn't, those moving off it tend to go for something else completely rather than another system very like it) - it is difficult for a newer similar projects to compete with the momentum it has when the “escape route” from it is generally to something more completely different.
- bluetomcat 11mo ago
  And consequently, "you need 32GB of RAM just to be future-proof for the next 3 years".

0xEF 11mo ago

Thinking is hard, so any product that gives people an excuse to stop doing it will do quite well, even if it creates more inconveniences like framework bloat or dependency rot. This is why shoehorning AI into everything is so wildly successful; it gives people the okay to stop thinking.

nly 11mo ago

Fortunately many apps seem to be moving to native webviews now instead of shipping electron

eitau_1 11mo ago

The sad reality is that easy tech explores solution space faster

matusp 11mo ago

What is often missing from the discussion is the expected lifecycle of the product. Using Electron for a simple app might be a good idea, if it is a proof-of-concept, or an app that will be used sparsely by few people. But if you use it for the built-in calculator in your OS, the trade-offs are suddenly completely different.

pjmlp 11mo ago
A large majority of Electron crap could be turned into a regular website, but then the developers would need to actually target the Web, instead of ChromeOS Platform and that is too hard apparently.
- Incipient 11mo ago
  I've recently gone back to more in depth (but still indie) Web dev with vuejs and quasar, and honestly I don't even find myself thinking about "targeting Web" any more - I just write code and it seems to work on pretty much everything (I haven't tested safari to be fair).
  - jtbaker 11mo ago
    Vue is so good! I've been encouraged seeing more organizations mentioning using it (in the hiring thread etc.) lately.

m-schuetz 11mo ago

I'd argue that the insane complexity of fast apps/APIs pushes many devs towards super slow but easy apps/APIs. There needs to be a middle ground, something that's easy to use and fast-enough, rather than trying to squeeze every last bit of perf while completely sacrificing usability.

immibis 11mo ago
Java Swing? It was slow in 1999, which means it's fast now. It's also a much more sensible language than JavaScript. It's not native GUI, but neither is JavaScript anyway.
- m-schuetz 11mo ago
  Swing has no place in a sentence about good usability. It may be the best of the worst, but it's not a positive example. Things like html or Imgui are better to use, with the former also being much more powerful and the latter being as simple as can be while still being blazing fast.

sublinear 11mo ago

On the flip side, what you're saying is also an overused excuse to dismiss web apps and promote something else that's probably a lot worse for everyone. I've never seen a real world Electron app with a large userbase that actually has that many dependencies or performance issues that would be resolved by writing it as a native app. It's baffling to me how many developers don't realize how much latency is added and memory is used by requiring many concurrent HTTP requests. If you have a counterexample I'd love to see it.