[SurceBeats]

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...

[0xEF]

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.

[rossant]

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]

Yeah, somehow it went from don't micro optimize loops to 500MB Electron apps are just fine actually hahaha

[sublinear]

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.

[nly]

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

[matusp]

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]

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.

[m-schuetz]

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]

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.

[eitau_1]

The sad reality is that easy tech explores solution space faster