12 ms·

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their p

by mrd3v0 3y ago

> Software "engineers" > For every extra cycle an hardware engineer can squeeze out of silicon, you will find a programmer adding one hundred cycles to their program[6]. In other terms, I fear that once devs figure out how powerful the M1 is, they will throw more "features" at it. Can we please stop replicating the "growth" fallacy into software ecosystems? Haven't we learnt enough about how unsustainable and damaging this is? I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world.

ramesh31 3y ago
>I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Yes, so we can go back to writing a hundred lines of imperative code to render hello world.
- lylejantzi3rd 3y ago
  4 in c. 11 in assembly. Not so bad, really. https://i.imgur.com/r2WRnZk.png https://i.imgur.com/r2WRnZk.png
  - dijit 3y ago
    I was about to make a joke about how many lines are required for an electron hello world but it was even more than I expected. 11 for the HTML document template 7 for the boilerplate package.json 3 more for the scripts addition to package.json 3 more for the “devdependencies” 20 for main.js from: https://electronjs.org/docs/latest/tutorial/quick-start https://electronjs.org/docs/latest/tutorial/quick-start A fairer assessment would be C++ with Qt to be honest though.
  - SubjectToChange 3y ago
    write a hello world application in gtk or qt and see how much assembly you get.
    - GhostWhisperer 3y ago
      let's move the goal posts to doing it in brainfuck since we're at it
      - SubjectToChange 3y ago
        What goalpost did I supposedly move?
    - 5- 3y ago
      x86_64 assembly, gtk3, 21 lines / 19 instructions build with e.g. gcc hw.s `pkg-config --libs gtk+-3.0` .globl main;main: push %rbx xor %esi, %esi xor %edi, %edi call gtk_init@PLT lea .HW(%rip), %r8 xor %edx, %edx xor %esi, %esi mov $2, %ecx xor %edi, %edi xor %eax, %eax call gtk_message_dialog_new@PLT mov %rax, %rbx mov %rax, %rdi call gtk_dialog_run@PLT mov %rbx, %rdi call gtk_widget_destroy@PLT xor %eax, %eax pop %rbx ret .HW:.string "Hello World!"
      - SubjectToChange 3y ago
        Are you sure you couldn’t wrap that up in another library and just do everything in a single call?
        5- 3y ago
        you jest, but in fact you could. https://wiki.libsdl.org/SDL2/SDL_ShowSimpleMessageBox https://wiki.libsdl.org/SDL2/SDL_ShowSimpleMessageBox
  - wiseowise 3y ago
    That’s super ironic that you’ve shown screenshot from a web application.
    - lylejantzi3rd 3y ago
      Why, thank you!
- johnnyworker 3y ago
  To the CPU it always boils down to sequences of instructions operating on data, so the syntax sugar put on top has be undone first, the abbreviations have to be unrolled, some way or another. But more importantly it's really not about the lines you code write once, or very few times in comparison -- it's about the computer does any time the application starts up on any machine, or any user does something. Obviously, to an extent. You wouldn't write a thousand lines of code instead of 100 to make something that is already very fast 10% faster. But I certainly would write 10 line instead of 1 if it meant the code is 10 times faster. It's just typing after all.
  - ramesh31 3y ago
    My point was that CPU cycles mean nothing now. Compared to programmer cycles they are effectively free. So stuff it into RAM and forget about it. Why not? Complexity is bad, and being able to hide it (effectively) is good. I shouldn't be thinking about pointer allocation when building a a text input box for a UI.
speedgoose 3y ago
For that you need a better alternative. I’m not aware of anything.
- slowmovintarget 3y ago
  Godot? Targets Windows, UWP, MacOS, Linux, BSD, Android, iOS, and Web: https://docs.godotengine.org/en/stable/about/faq.html https://docs.godotengine.org/en/stable/about/faq.html Nothing says you have to use it to make a game. I recall seeing articles here on HN about using it as a cross-platform app development framework. GDScript may be less appealing than JavaScript, however.
  - DonHopkins 3y ago
    Godot is wonderful. But GDScript is a horrible, terrible, ill conceived idea. So how's the QuakeC development ecosystem these days? How good is ChatGPT at generating QuakeC? Who's still programming Unity3D in Managed JScript or Boo?
    - satvikpendem 3y ago
      I wonder if Bevy might be a good alternative, it's in Rust which isn't a proprietary language.
  - wiseowise 3y ago
    How’s accessibility and access to native apis?
- satvikpendem 3y ago
  Flutter works pretty well for apps like these.
- MikusR 3y ago
  https://sciter.com/ https://sciter.com/
threeseed 3y ago
The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.
- bombolo 3y ago
  Decent developers can do that in C++
  - seanthemon 3y ago
    Decenter developers can do that with a magnetized needle and a steady hand
    - dijit 3y ago
      I wonder if there is a name for the idea that the more you earn the lazier you get. Sysadmins used to know a lot but earn pittance compared to “devops” or “SRE”; then those more expensive folks outsourced the majority of their hard work to cloud vendors who charge 5-11x the cost for compute. Developers earn 5-10x more than 15 years ago, yet continue to choose solutions for their own convenience and time saving. Stating that its better for the company if they have to work less. Surely at some point its just your job to consider the entire ecosystem and your contribution to it. Otherwise why are you worth all that money?
      - deleted 3y ago
        [deleted]
      - pocketarc 3y ago
        Because they -are- providing value, and because dev resources are limited. If you're a dev, do you think your company would want you to spend 2 weeks on building a new feature, or on "considering the entire ecosystem"? And more than that - if you have a team that only/mostly has web experience, they're going to use Electron, and... what kind of company would want them to stop and go learn native app development, or hire extra people just to get a native app? Note: I fully agree with you, I do feel that as a profession we really have descended into a weird "ship the MVP, ship new features non-stop, forget quality" reality, and I dislike it. I'd love it if everything was resource-thrifty native apps, and dev teams could stop chasing new and shiny things and work on improving their existing apps until they were shiny polished diamonds. I'd love to point to an app and say "see? this is 20 years of development, look at how nice it is, how perfectly thought out everything is, how everything just works flawlessly". But the fact that that's not happening is not because devs are lazy, or not worth their money. It just doesn't make business sense.
makeitdouble 3y ago
> people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Wasn't the whole OSX's new paradigm a switch to high level language and frameworks , with compositing window management to display super fancily rendered hello worlds ? Decrying cycle burning for the sake of high level abstractions feels like a complete rebutal of everything OSX/macos ecosystem stood for.
- wtallis 3y ago
  > Wasn't the whole OSX's new paradigm a switch to high level language and frameworks , with compositing window management to display super fancily rendered hello worlds ? No, not really. You're making it sound like Classic MacOS applications were written in assembly, when it was mostly C++. Switching to Objective-C was more of a lateral move, not a clear step forward in time or level of abstraction. The Mac OS X graphics stack was a pretty big change from Classic MacOS, but it wasn't that much of a change from NeXTSTEP, which worked with 12MB of RAM + 1.5MB VRAM. NeXTSTEP just wasn't as eye-catchingly colorful. Early OS X did poineer gratuitous use of some effects like translucency with blurs in desktop GUIs, but since this was the time period where GPUs were becoming mainstream, these effects weren't egregiously resource-intensive. And considering that OS X was adapted with relative ease to power a smartphone with 128MB of RAM (with the graphical effects turned up to 11), it definitely wasn't fundamentally bloated in the way that today's Electron apps are.
  - makeitdouble 3y ago
    Many Obj C libraries were a wrapping layer on top of the Carbon APIs and in terms of abstraction Obj C is also a level above C++. Passing everything as messages is an additional layer of indirection. NextSTEP itself was a big change compared to X or Windows's GUI stack. NeXT machines were beefy and adjusted to high workloads so the user experience wasn't problematic, but it's still more resource use than the standard stacks of the time. I don't see it as a bad thing, but we should acknowledge resource economy wasn't a target of the neither NeXT nor Apple at that time. > 12MB of RAM + 1.5MB VRAM NeXT launched in 1988, basically around the times when "640k should be enough for everyone" was a meme. Even in 1996, 12MB of RAM was nothing to sneeze at. So, sure those are not enormous numbers, but they're far from the lower end of what was sold to consumers at the time. > smartphone with 128MB of RAM We should take a minute to note that 128Mb or RAM is not small for a phone at the time. Otherwise, sure electron apps use a lot more than that, but the point was always to pay for powerful hardware and use it at full potential to run fancy apps. People loathe electron apps' bloat, but ease of development has also always been one of the core values. Better have apps that aren't fully optimized than no apps at all.
zondafan1 3y ago
> I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Web technologies are fine, but what we really need is some kind of lightweight browser which allows you to use HTML/CSS/JS, but with far lower memory usage. I found https://ultralig.ht/ https://ultralig.ht/ which seems to be exactly what I am looking for, but the license is a major turn off for most paid services. It makes sense for smaller, indie projects to adopt it, but I haven't seen many "desktop apps" using this in the wild.
- winter_blue 3y ago
  What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an elegant way). Ultralight (https://ultralig.ht/ https://ultralig.ht/) looks pretty cool. I think another possible option is Servo (https://github.com/servo/servo https://github.com/servo/servo) – it was abandoned by Mozilla along with Rust during their layoffs a while back (but the project still seems to have a decent bit of activity). It would be great if some group of devs could revive the project, or a company could fund such a revival. Eventually, we'll need to reflect on, and explore whether HTML+CSS is really the best way to do layout, and we could maybe perhaps consider porting the Android/iOS layout approach over to desktop. Maybe WPF/GTk/Qt/etc even got things right, and HTML+CSS isn't the best way to do layout.
  - rhaway84773 3y ago
    We already know HTML/CSS are not the best way to do layout. We already have many desktop based UI frameworks to create cross platform desktop apps. GTK, QT, etc which are also superior to the single app, limited size focused Android/iOS UI frameworks. More importantly, unlike iOS/Android, they’re even cross platform. HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS which was the original lingua franca of the web, and there are tons of libraries, frameworks, tools, components, etc available in the HTML/CSS/JS world that makes development easier and quicker.
presentation 3y ago
Keep hoping, because it won’t happen. Practically no consumers care except for other software engineers complaining loudly on HN, and meanwhile companies save millions by not handcrafting their CRUD apps in assembly.
- jrockway 3y ago
  The problem is having to target 5 operating systems. Extremely complicated web app runs on Linux, Windows, Mac, Android, and iOS. Carefully-crafted Native UI widgets only target one platform at a time. If you want to get rid of Electron, you personally have to volunteer to be responsible for 5x the work of anyone else, and accept bootcamp-graduate pay. Do you see why it's not happening?
  - raverbashing 3y ago
    Exactly this. And HTML/CSS may have its quirks but I'll take it every day over fumbling with GTK or whatever
  - satvikpendem 3y ago
    I just use Flutter instead, works great for all 5 OS.
  - bombcar 3y ago
    Arguably the success of MacOS has caused the expansion of Electron, because developers are using macs and want to use macs even when programming tools for windows.
    - caycep 3y ago
      Some (maybe Apple) ought to make a Swift -> Windows/Linux cross compiler...
- LtWorf 3y ago
  Consumers care but have no choice. Like consumers that want to buy a phone that fit in the hand… there is none at a reasonable price.
zarzavat 3y ago
Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there. The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.
- jbverschoor 3y ago
  The RAM usages comes with cache misses. It's NOT efficient. Just because you have a monster machine, doesn't mean it's efficient
- astrange 3y ago
  The RAM usage is from JavaScript heaps, not from multiple copies of the binaries. (There basically aren't memory metrics that can show the effect of binary sizes on macOS. It'd show up as disk reads/page ins/general slowdowns instead, but SSDs are so fast that it's very hard to see one.)
  - bombolo 3y ago
    Multiple copies of the same binary can't share a memory page for the code. They do take more RAM.
    - astrange 3y ago
      And there are no metrics you can look at to see the impact of this, so it's not contributing to any of the metrics you are seeing, as I said.
- Y-bar 3y ago
  A similarly bad problem is that Electron apps by default does not adhere to the operating system conventions and API:s, and often also does not use the the features which makes the OS good. For example all Electron apps I use have their own implementation of a spell checker rather than hooking into the system one. Normally in Mac OS if I add a word to the system dictionary all apps will learn that word, but in each Electron app I will have to do it again, and again, ... Many also implement their own UI widgets like basic buttons and input fields whose UX is not at all in line with native apps.

by mrd3v0 3y ago

ramesh31 3y ago

>I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Yes, so we can go back to writing a hundred lines of imperative code to render hello world.

lylejantzi3rd 3y ago
4 in c. 11 in assembly. Not so bad, really. https://i.imgur.com/r2WRnZk.png https://i.imgur.com/r2WRnZk.png
- dijit 3y ago
  I was about to make a joke about how many lines are required for an electron hello world but it was even more than I expected. 11 for the HTML document template 7 for the boilerplate package.json 3 more for the scripts addition to package.json 3 more for the “devdependencies” 20 for main.js from: https://electronjs.org/docs/latest/tutorial/quick-start https://electronjs.org/docs/latest/tutorial/quick-start A fairer assessment would be C++ with Qt to be honest though.
- SubjectToChange 3y ago
  write a hello world application in gtk or qt and see how much assembly you get.
  - GhostWhisperer 3y ago
    let's move the goal posts to doing it in brainfuck since we're at it
    - SubjectToChange 3y ago
      What goalpost did I supposedly move?
  - 5- 3y ago
    x86_64 assembly, gtk3, 21 lines / 19 instructions build with e.g. gcc hw.s `pkg-config --libs gtk+-3.0` .globl main;main: push %rbx xor %esi, %esi xor %edi, %edi call gtk_init@PLT lea .HW(%rip), %r8 xor %edx, %edx xor %esi, %esi mov $2, %ecx xor %edi, %edi xor %eax, %eax call gtk_message_dialog_new@PLT mov %rax, %rbx mov %rax, %rdi call gtk_dialog_run@PLT mov %rbx, %rdi call gtk_widget_destroy@PLT xor %eax, %eax pop %rbx ret .HW:.string "Hello World!"
    - SubjectToChange 3y ago
      Are you sure you couldn’t wrap that up in another library and just do everything in a single call?
      - 5- 3y ago
        you jest, but in fact you could. https://wiki.libsdl.org/SDL2/SDL_ShowSimpleMessageBox https://wiki.libsdl.org/SDL2/SDL_ShowSimpleMessageBox
- wiseowise 3y ago
  That’s super ironic that you’ve shown screenshot from a web application.
  - lylejantzi3rd 3y ago
    Why, thank you!
johnnyworker 3y ago
To the CPU it always boils down to sequences of instructions operating on data, so the syntax sugar put on top has be undone first, the abbreviations have to be unrolled, some way or another. But more importantly it's really not about the lines you code write once, or very few times in comparison -- it's about the computer does any time the application starts up on any machine, or any user does something. Obviously, to an extent. You wouldn't write a thousand lines of code instead of 100 to make something that is already very fast 10% faster. But I certainly would write 10 line instead of 1 if it meant the code is 10 times faster. It's just typing after all.
- ramesh31 3y ago
  My point was that CPU cycles mean nothing now. Compared to programmer cycles they are effectively free. So stuff it into RAM and forget about it. Why not? Complexity is bad, and being able to hide it (effectively) is good. I shouldn't be thinking about pointer allocation when building a a text input box for a UI.

speedgoose 3y ago

For that you need a better alternative. I’m not aware of anything.

slowmovintarget 3y ago
Godot? Targets Windows, UWP, MacOS, Linux, BSD, Android, iOS, and Web: https://docs.godotengine.org/en/stable/about/faq.html https://docs.godotengine.org/en/stable/about/faq.html Nothing says you have to use it to make a game. I recall seeing articles here on HN about using it as a cross-platform app development framework. GDScript may be less appealing than JavaScript, however.
- DonHopkins 3y ago
  Godot is wonderful. But GDScript is a horrible, terrible, ill conceived idea. So how's the QuakeC development ecosystem these days? How good is ChatGPT at generating QuakeC? Who's still programming Unity3D in Managed JScript or Boo?
  - satvikpendem 3y ago
    I wonder if Bevy might be a good alternative, it's in Rust which isn't a proprietary language.
- wiseowise 3y ago
  How’s accessibility and access to native apis?
satvikpendem 3y ago
Flutter works pretty well for apps like these.
MikusR 3y ago
https://sciter.com/ https://sciter.com/

threeseed 3y ago

The majority of users who own an M1 are never going to push it to 100% utilisation. So whether their productivity app is written in Electron or hand-crafted assembler isn't going to make much of a difference to the end user experience. Electron and similar apps serve a legitimate purpose in the marketplace which is to allow developers to deliver a cross-platform app for the same cost as a single platform one.

bombolo 3y ago
Decent developers can do that in C++
- seanthemon 3y ago
  Decenter developers can do that with a magnetized needle and a steady hand
  - dijit 3y ago
    I wonder if there is a name for the idea that the more you earn the lazier you get. Sysadmins used to know a lot but earn pittance compared to “devops” or “SRE”; then those more expensive folks outsourced the majority of their hard work to cloud vendors who charge 5-11x the cost for compute. Developers earn 5-10x more than 15 years ago, yet continue to choose solutions for their own convenience and time saving. Stating that its better for the company if they have to work less. Surely at some point its just your job to consider the entire ecosystem and your contribution to it. Otherwise why are you worth all that money?
    - deleted 3y ago
      [deleted]
    - pocketarc 3y ago
      Because they -are- providing value, and because dev resources are limited. If you're a dev, do you think your company would want you to spend 2 weeks on building a new feature, or on "considering the entire ecosystem"? And more than that - if you have a team that only/mostly has web experience, they're going to use Electron, and... what kind of company would want them to stop and go learn native app development, or hire extra people just to get a native app? Note: I fully agree with you, I do feel that as a profession we really have descended into a weird "ship the MVP, ship new features non-stop, forget quality" reality, and I dislike it. I'd love it if everything was resource-thrifty native apps, and dev teams could stop chasing new and shiny things and work on improving their existing apps until they were shiny polished diamonds. I'd love to point to an app and say "see? this is 20 years of development, look at how nice it is, how perfectly thought out everything is, how everything just works flawlessly". But the fact that that's not happening is not because devs are lazy, or not worth their money. It just doesn't make business sense.

makeitdouble 3y ago

> people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Wasn't the whole OSX's new paradigm a switch to high level language and frameworks , with compositing window management to display super fancily rendered hello worlds ? Decrying cycle burning for the sake of high level abstractions feels like a complete rebutal of everything OSX/macos ecosystem stood for.

wtallis 3y ago
> Wasn't the whole OSX's new paradigm a switch to high level language and frameworks , with compositing window management to display super fancily rendered hello worlds ? No, not really. You're making it sound like Classic MacOS applications were written in assembly, when it was mostly C++. Switching to Objective-C was more of a lateral move, not a clear step forward in time or level of abstraction. The Mac OS X graphics stack was a pretty big change from Classic MacOS, but it wasn't that much of a change from NeXTSTEP, which worked with 12MB of RAM + 1.5MB VRAM. NeXTSTEP just wasn't as eye-catchingly colorful. Early OS X did poineer gratuitous use of some effects like translucency with blurs in desktop GUIs, but since this was the time period where GPUs were becoming mainstream, these effects weren't egregiously resource-intensive. And considering that OS X was adapted with relative ease to power a smartphone with 128MB of RAM (with the graphical effects turned up to 11), it definitely wasn't fundamentally bloated in the way that today's Electron apps are.
- makeitdouble 3y ago
  Many Obj C libraries were a wrapping layer on top of the Carbon APIs and in terms of abstraction Obj C is also a level above C++. Passing everything as messages is an additional layer of indirection. NextSTEP itself was a big change compared to X or Windows's GUI stack. NeXT machines were beefy and adjusted to high workloads so the user experience wasn't problematic, but it's still more resource use than the standard stacks of the time. I don't see it as a bad thing, but we should acknowledge resource economy wasn't a target of the neither NeXT nor Apple at that time. > 12MB of RAM + 1.5MB VRAM NeXT launched in 1988, basically around the times when "640k should be enough for everyone" was a meme. Even in 1996, 12MB of RAM was nothing to sneeze at. So, sure those are not enormous numbers, but they're far from the lower end of what was sold to consumers at the time. > smartphone with 128MB of RAM We should take a minute to note that 128Mb or RAM is not small for a phone at the time. Otherwise, sure electron apps use a lot more than that, but the point was always to pay for powerful hardware and use it at full potential to run fancy apps. People loathe electron apps' bloat, but ease of development has also always been one of the core values. Better have apps that aren't fully optimized than no apps at all.

zondafan1 3y ago

> I hope Electron/CEF die soon, and people get back to building applications that don't consume hundreds of megabytes of RAM to render a hello world. Web technologies are fine, but what we really need is some kind of lightweight browser which allows you to use HTML/CSS/JS, but with far lower memory usage. I found https://ultralig.ht/ https://ultralig.ht/ which seems to be exactly what I am looking for, but the license is a major turn off for most paid services. It makes sense for smaller, indie projects to adopt it, but I haven't seen many "desktop apps" using this in the wild.

winter_blue 3y ago
What I'd really like to see with CEF et al, is JS being dropped, in favor of directly controlling the DOM from the host language. Then we could, for example, write a Rust (or Kotlin, Zig, Haskell, etc) desktop application that simply directly manipulated the DOM, and had it rendered by a HTML+CSS layout engine. Folks could then write a React-like framework for that language (to help render & re-render the DOM in an elegant way). Ultralight (https://ultralig.ht/ https://ultralig.ht/) looks pretty cool. I think another possible option is Servo (https://github.com/servo/servo https://github.com/servo/servo) – it was abandoned by Mozilla along with Rust during their layoffs a while back (but the project still seems to have a decent bit of activity). It would be great if some group of devs could revive the project, or a company could fund such a revival. Eventually, we'll need to reflect on, and explore whether HTML+CSS is really the best way to do layout, and we could maybe perhaps consider porting the Android/iOS layout approach over to desktop. Maybe WPF/GTk/Qt/etc even got things right, and HTML+CSS isn't the best way to do layout.
- rhaway84773 3y ago
  We already know HTML/CSS are not the best way to do layout. We already have many desktop based UI frameworks to create cross platform desktop apps. GTK, QT, etc which are also superior to the single app, limited size focused Android/iOS UI frameworks. More importantly, unlike iOS/Android, they’re even cross platform. HTML/CSS/JS are successful because of the same reason electron exists. The success of the web means there’s a huge developer base that knows how to work with HTML/CSS/JS which was the original lingua franca of the web, and there are tons of libraries, frameworks, tools, components, etc available in the HTML/CSS/JS world that makes development easier and quicker.

presentation 3y ago

Keep hoping, because it won’t happen. Practically no consumers care except for other software engineers complaining loudly on HN, and meanwhile companies save millions by not handcrafting their CRUD apps in assembly.

jrockway 3y ago
The problem is having to target 5 operating systems. Extremely complicated web app runs on Linux, Windows, Mac, Android, and iOS. Carefully-crafted Native UI widgets only target one platform at a time. If you want to get rid of Electron, you personally have to volunteer to be responsible for 5x the work of anyone else, and accept bootcamp-graduate pay. Do you see why it's not happening?
- raverbashing 3y ago
  Exactly this. And HTML/CSS may have its quirks but I'll take it every day over fumbling with GTK or whatever
- satvikpendem 3y ago
  I just use Flutter instead, works great for all 5 OS.
- bombcar 3y ago
  Arguably the success of MacOS has caused the expansion of Electron, because developers are using macs and want to use macs even when programming tools for windows.
  - caycep 3y ago
    Some (maybe Apple) ought to make a Swift -> Windows/Linux cross compiler...
LtWorf 3y ago
Consumers care but have no choice. Like consumers that want to buy a phone that fit in the hand… there is none at a reasonable price.

zarzavat 3y ago

Electron is quite efficient. You get a modern GPU composited UI, and JavaScript is by far the most highly optimized scripting language out there. The problem with Electron is RAM, disk space, and download size, which is because every app needs to ship its own copy of Blink. This is a solvable problem, but nobody is incentivized to solve it.

jbverschoor 3y ago
The RAM usages comes with cache misses. It's NOT efficient. Just because you have a monster machine, doesn't mean it's efficient
astrange 3y ago
The RAM usage is from JavaScript heaps, not from multiple copies of the binaries. (There basically aren't memory metrics that can show the effect of binary sizes on macOS. It'd show up as disk reads/page ins/general slowdowns instead, but SSDs are so fast that it's very hard to see one.)
- bombolo 3y ago
  Multiple copies of the same binary can't share a memory page for the code. They do take more RAM.
  - astrange 3y ago
    And there are no metrics you can look at to see the impact of this, so it's not contributing to any of the metrics you are seeing, as I said.
Y-bar 3y ago
A similarly bad problem is that Electron apps by default does not adhere to the operating system conventions and API:s, and often also does not use the the features which makes the OS good. For example all Electron apps I use have their own implementation of a spell checker rather than hooking into the system one. Normally in Mac OS if I add a word to the system dictionary all apps will learn that word, but in each Electron app I will have to do it again, and again, ... Many also implement their own UI widgets like basic buttons and input fields whose UX is not at all in line with native apps.