5 ms·

Consider Electron: grotesquely inefficient in terms of CPU usage, because it's optimized for minimizing developer time instead. We aren't solving the same prob

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.

colechristensen 5y ago
Is developer time actually being conserved though?
- Enginerrrd 5y ago
  Yeah I for one am extremely skeptical of the implicit assumption.
- nine_k 5y ago
  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 :-/
  - mhmmmmmm 5y ago
    > 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.
  - sdevonoes 5y ago
    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
- naikrovek 5y ago
  > 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.
  - Cyphase 5y ago
    > 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?
    - zhte415 5y ago
      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.
makeitdouble 5y ago
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.
- avl999 5y ago
  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.
  - xwolfi 5y ago
    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.
  - dragonwriter 5y ago
    > 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.
simonh 5y ago
> 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.
- pjmlp 5y ago
  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.
xg15 5y ago
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.
flohofwoe 5y ago
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).
- dwighttk 5y ago
  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
  - flohofwoe 5y ago
    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).
    - dwighttk 5y ago
      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.

colechristensen 5y ago

Is developer time actually being conserved though?

Enginerrrd 5y ago
Yeah I for one am extremely skeptical of the implicit assumption.
nine_k 5y ago
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 :-/
- mhmmmmmm 5y ago
  > 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.
- sdevonoes 5y ago
  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
naikrovek 5y ago
> 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.
- Cyphase 5y ago
  > 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?
  - zhte415 5y ago
    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.

makeitdouble 5y ago

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.

avl999 5y ago
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.
- xwolfi 5y ago
  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.
- dragonwriter 5y ago
  > 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.

simonh 5y ago

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

pjmlp 5y ago
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.

xg15 5y ago

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.

flohofwoe 5y ago

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

dwighttk 5y ago
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
- flohofwoe 5y ago
  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).
  - dwighttk 5y ago
    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.