Hacker News Reader

Comment by rectang | Hacker News Reader

Consider Electron: grotesquely inefficient in terms of CPU usage, because it's optimized for minimizing developer time instead.

We aren't solving the same problems our forebears did. People weren't designing native apps with pencil and paper when somebody figured out how to bundle up the Chromium Embedded Framework, but they were burning tons of time duplicating effort on multiple native apps because OS platform vendors are manically determined to lock us in and stop us from writing portable code.

View on HN

Developer time is not infinite, so a specific ecosystem optimizing for it doesn't come to me as weird.

You might begrudge the resources used at scale, but if these programs weren't built in the first place it would be net negative. I also don't see Slack coded in GTK for instance, if it wasn't electron it would have been some Java framework, and I'm not sure it would have been better.

Comparing VSCode with Eclipse (which was optimized compared to other frameworks....), I'm pretty happy with VSCode and think we came a long way.

Even a Java based gui written using the Swing toolkit (which I believe is considered ancient tech that most have moved on from although I haven't built a gui in java in ages so don't take my word for it) would be an improvement on these electron apps just because it will prevent the cancer that is Javascript, node, npm and the entire JS ecosystem from invading the desktop. We deal with JS/Node on the frontend because we have no choice, that tech invading the server and the desktop is just sad to watch.

I found that we have the choice and successfully migrated an enormous bloatware of thousands of binding setinterval functions (Angular 1) full of node dependencies, npm breakages, impossible to understand grunt builds into a simple, 10 files pure javascript + some jquery approximately well compatmentalised set of bespoke business services.

The only critic I ever faced with this was that it was not classical nor "the proper way", but the fact it loaded instantly and worked exactly the same way albeit infinitely faster managed to convince we may not need all that jazz.

You always have a choice but you'll face more resistance and worry not to go with everyone else towards suicide by a thousand dependencies.

> Even a Java based gui written using the Swing toolkit (which I believe is considered ancient tech that most have moved on from although I haven't built a gui in java in ages so don't take my word for it) would be an improvement on these electron apps just because it will prevent the cancer that is Javascript, node, npm and the entire JS ecosystem from invading the desktop.

I remember a very similar complaint being made about Eclipse, Java, and Swing as you make about Electron, JS, and Node as a cancer on the desktop.

From my Java days, backend work looked like creating plugins to auto-generate XML, which would be parsed by the build system to auto-generate classes...on a philosophy level, I can't remember people preaching simplicity and pragmatism outside of the Eclipse people (who had to deal with real hard complexity issues day in and day out...)

An alternative history where Java would have been huge on the desktop doesn't look to me like we'd have a heaven of well-though lightweight apps TBH.

I personnally think npm is something inevitable, and am not sure Maven for instance is fundamentally better in the grand scheme of things (I'd argue as a dev it's way more of a PITA without any specific upside, but it might be my own incompetence).

The same VSCode that happens to run Eclipse headless for its Java support?

> You might begrudge the resources used at scale, but if these programs weren't built in the first place it would be net negative.

I don't think so. Different programs might have been built in a more efficient framework instead.

> it would have been some Java framework, and I'm not sure it would have been better.

Java Swing is much more responsive and light when compared to Electron. Java is no longer heavy since the first Core series processors of Intel, and it's visibly optimized to be lighter and faster every release.

> Comparing VSCode with Eclipse (which was optimized compared to other frameworks....), I'm pretty happy with VSCode and think we came a long way.

Eclipse of today can run circles around both the Eclipse of yesteryear and VScode in terms of performance, resource utilization and capabilities.

I'm using Eclipse for 20 years (and still using it), and just because it's old enough to get a driver's license, it doesn't mean it's obsolete or featureless.

If you want to try an example of a truly scalable and snappy GUI experience with lightweight Java check my node/tree editor out: http://move.rupy.se/file/logic.html

Depends who is "we". It does seem like a waste if a considerable amount of the user's resources is wasted for developer convenience, path dependency and politics.

A bit of inefficiency is alright, but things get ridiculous if modern web pages actually run less smooth than programs 40 years ago despite having quadrillion times the computing power available - because this power is wasted to write objects to JSON half a dozen times or simulate a network architecture between a virtual server and a virtual client which actually reside on the same machine - all because that's the only architecture modern web developers seem to understand.

Is developer time actually being conserved though?

Yeah I for one am extremely skeptical of the implicit assumption.

Absolutely.

Typescript + Next.js + Electron would be much, much faster for me to develop for than GTK + C, and even than Python + PyQT.

I wish there existed a modern cross-platform open source reactive GUI framework which was less of a resource hog than Electron, that would be great! Qt specifically is not much more economical, though the redistributable is smaller. Java is also rather nice for cross-platform GUIs, and also rather a hog.

Sadly, Electron is not so outstanding wrt resource consumption :-/

> I wish there existed a modern cross-platform open source reactive GUI framework which was less of a resource hog than Electron

Flutter (Desktop) comes pretty close to that. Its really fast to write and your code works on IOS/Android/MacOS/Windows/Linux unless you need Platform specific API's, and even that is possible.

But that's relative, right? I mean, I know Python and PyQT and I am way more productive with them than, let's say, Typescript + Next.js

> Is developer time actually being conserved though?

in the case of Electron, probably. it is comparatively difficult to release a cross platform graphical application in any other way.

in the case of other "high level" languages like Python, almost certainly not.

I remember reading something on Dropbox' engineer or developer blog about their conversion from Python 2 to Python 3 and how well it went for their desktop client, which had over one million lines of code and I had to stop and reread that a few times to make sure I read correctly.

How "high level" is Python if this many lines of code are required to create the Dropbox client? maybe Python is the epitome of a high level language, I don't know, but if it is, I don't see how one million lines of Python saves anyone any time over something low level like C or even Assembly, really. the promised tradeoff of execution speed for programmer productivity isn't there, at all, and almost no one sees it.

even if the majority of those lines of code are in libraries, why do those libraries have so many lines of code? what can they possibly be doing to need that many lines of code? it really does boggle my mind.

entire operating systems require fewer lines of code than the Dropbox client, and are written in languages that are supposedly much less expressive per line of code. so where is this supposed developer productivity when it takes over one million lines of code to write the Dropbox client?

I'm not trying to pick on Python, specifically, mind you; this is just an example I was thinking about recently. I'm quite sure that there are other tradeoffs also not delivering what they promised at all in all other languages, and I'm 110% certain no one is noticing those, either.

> How "high level" is Python if this many lines of code are required to create the Dropbox client?

Do you have some baseline to which we can compare? How many lines "should" it take?

rsync? Plus bells and whistles.

By no means do I wish to awaken the ghost of that infamous HN comment on how easy/why someone else had not done those bells and whistles before.

The bells-and-whistles version was called 'My Briefcase'.

I'm not drawing conclusions from this, but I did some poking around..

I ran `git clone` on the repos of both rsync[0] and the official Dropbox SDK for Python[1]. I then ran sloccount on both of them.

---

rsync came in at a total of 51,410 physical source lines of code.

The Dropbox SDK came in at a total of 74,140 physical source lines of code.

---

(This data generated using David A. Wheeler's 'SLOCCount'.)

[0] https://git.samba.org/rsync.git

[1] https://github.com/dropbox/dropbox-sdk-python

> it is comparatively difficult to release a cross platform graphical application in any other way.

wxWidgets has been enabling cross-platform native graphics since the 1990s. Though the overall development experience is rather MFC-like, and not to many people's taste.

> what can they possibly* be doing to need that many lines of code? it really does boggle my mind.*

Unless you've spent lots of time (half a decade or more) at each layer of "full stack", it is really hard to comprehend just how mind-bogglingly fractal systems requirements get the more users you expose them to. Anytime you go b2c, or even b2b with a large enough user base, be prepared to say, "huh, I didn't see that coming" once a week or more frequently.

There are entire problem domains that lay submerged until you reach certain scales. Some code bases reflect the encapsulation of those submarine domains; some don't, most assuredly, but until the software becomes unused, at my clients I never ask the question the way you ask. Instead, I ask them to walk me through the code at successively finer-grained conceptual blocks until I reach the level where I can start attacking the problem I've been brought in to help address.

>I don't see how one million lines of Python saves anyone any time over something low level like C or even Assembly

I do somehow agree with you, but going from Assembly to C was a huge step, from C to Java/C# a huge step due to GC and better typing.

Python indeed does not feel much higher level to me than e.g. C#, the only reason I've ever really seen why people save lines of code is the lack of braces, which doesn't really matter IMO, and because there are so many libraries. A big reason why there are so many libraries? I guess because people think it's easy, nothing innate in the language, certainly not that it's easy to package stuff.

The Dropbox client is busy trying to steal your screenshots and flash drive contents, and promote Dropbox Pro every time your storage goes above 90% full, or even randomly otherwise. Though I can't see how that would take 100k lines of code out of the million total.

IMHO "Electron is bloaty" has become a meme on its own which just gets repeated over and over without actually checking how much of it is true.

For instance when comparing VSCode to Visual Studio or Xcode, VSCode isn't universally slower, far from it. VSCode is much faster from start to first keystroke than both VS or Xcode. In other areas it's not so clear, some actions are slower in VSCode, some are faster (and before "but VSCode is a text editor, not an IDE", with the right plugins VSCode is as much an IDE as it needs to be).

So if even the Visual Studio or Xcode teams at Microsoft and Apple can't create applications that are universally better than an Electron application, why should 3rd party developers care about creating "native" applications?

The Windows and macOS platform teams don't seem to have quite understood yet that they are in competition with Electron, and in order to compete, they have to make it easier to create cross-platform applications than what Electron provides. Nobody will choose native macOS or Windows APIs just because they provide a "native look and feel" (which neither Microsoft nor Apple care about all that much in their own applications either).

My problem with electron is not that the apps are slow it is that I can (usually) guess if an app is electron by seeing which ones are using up an entire core when the app is just sitting doing nothing

That's not what I'm seeing with VSCode on macOS though: the highest priority task when sitting "mostly idle" 'Code Helper (Renderer)' at 0.2%, which is at 7th or 8th position (and for instance below an idle iTerm2).

I suspect that the applications that use up a core when idle would do this also if Electron is not used (e.g. it's a property of the development team, not of the framework).

Maybe, but it seems there’s something about development teams that choose to write native apps that avoid that because I’ve never guessed an app was electron and been wrong using this method.

VSCode is the outliner in Electron and not the norm. M$ had a whole team on VSCode dedicated just for performance. Outliner to Outliner you may want to compare VSCode to Sublime Editor.

Yes, almost as if performance doesn't happen on its own. It must be a stated goal and the whole team must work towards that goal (you really don't need a "dedicated performance team", with or without Electron).

> because OS platform vendors are manically determined to lock us in and stop us from writing portable code

Sorry, but that’s both flat out not true, and a fundamental misunderstanding of what the role of a platform vendor is.

If Apple wanted to ban non-native apps on iOS it’s hard to see what would stop them. They’re clearly fine with them. Microsoft has even embraced cross platform development wholeheartedly with many Electron apps, and more to come. They’re even plumbing the chrome engine into Windows to make sharing it more efficient.

The role of a platform vendor though is to make the best platform for native development they can. Portability to other platforms, with a few exceptions such as POSIX, just isn’t their problem. There’s no particular reason it should be. It would just stifle innovation and lead to boring me-too systems that are stuck in the past. That’s simply not in the interests of users or vendors.

They are replacing the IE engine with Chrome one, Web widgets on OS level go back around 25 years.

Even electron apps aren't new, we already had that disease once with Active Desktop and packaged web sites.

There is some hope that like 20 years ago eventually the bubble will burst.

Reply on news.ycombinator.com