5 ms·

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed w

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

deleted 3y ago
[deleted]
FirmwareBurner 3y ago
Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?
- zer0zzz 3y ago
  Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.
  - FirmwareBurner 3y ago
    Why is it terrible? Asking for real.
    - LeoNatan25 3y ago
      Because it’s not “sexy” anymore. Now “sexiness” lies with web crap, so Electron is a “great tool”, while Java is “terrible”.
    - zer0zzz 3y ago
      Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.
      - FirmwareBurner 3y ago
        > The original interpreted stack-based JVM model is really bad for performance And we addressed that today by launching a copy of Chrome with every app?
        zer0zzz 3y ago
        yes I think it's hard to beat the tide that is the web as a content and app delivery system. The web is also getting all the billions in investment from every massive faang.
        3y ago
    - mikrotikker 3y ago
      It's got more security holes than Swiss cheese.
      - samus 3y ago
        You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.
        mnd999 3y ago
        Applets are still a thing. We just call them webasm and canvas these days.
        samus 3y ago
        The crucial difference is that these technologies are embedded differently. Java Applets had access to dangerous APIs that had to be restricted by the SecurityManager. Also, the JVM was installed externally to the browser, turning it into an uncontrollable component which made the browser vulnerable in turn. The newer technologies were designed from the beginning with a well-defined security boundary and are based on a language that was designed from the beginning to be embedded. Everything is implemented within the browser and can be updated together with it.
        mikrotikker 3y ago
        I'm living in the future. We have golang and rust now. Java is a pile of junk and should be relegated to the past.
        samus 3y ago
        Golang's only consistent advantage over Java is lower latency on compilation, startup, and GC. OpenJDK will eventually level the playing field with Project Valhalla. In terms of FFI and language features Java has already caught up. And faster startup can be achieved with CRaC. Rust in turn is not competing with Java.
- creesch 3y ago
  Java simply has a much higher barrier of entry. Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. Electron isn't just cross platform, it is cross platform based on technologies (html, css and javascript) that also by a huge margin have the largest amount of developers available.
  - whartung 3y ago
    > Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. What external dependencies does Java need that's not in the JDK itself? I have an app with Mac and Windows installers (and thus bundles JDKs), it also runs on Linux (via a fat jar), I tested it on Ubuntu, but for the life of me I couldn't figure out how to package it properly. It was more complicated that I cared to invest it at the time. As for the barrier to entry, I feel the same way about the web. I find the JS and Web ecosystem to be utterly overwhelming, one reason I stuck with Java over something like Electron, and the installers/footprint of the app are smaller to boot.
    - creesch 3y ago
      > What external dependencies does Java need that's not in the JDK itself? I mean that it doesn't come with Java itself, but you as a developer need to pick a UI framework and not all of them actually work all that well cross platform or will get you an actual modern interface. Edit: I should also note that the threshold for entry I am talking about is for people just generally starting out. There simply are way more resources available for web related development than there are for java. Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore.
      - ElectricalUnion 3y ago
        > Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore. What, do you bundle Electron source and Electron build environment with your Electron app? Why would you do the same and bundle Java source code + Java compilers in your Java app? Why would you do the same and bundle <any language> source code + <any language> compilers in your <any language> app? If you need to create a "just works without dependency b.s." experience in Java, you use the correct tooling for that, jlink.
- zlg_codes 3y ago
  It's the JS kiddies. They got Node and then decided the whole world should be written in Javascript, lol.
- chefandy 3y ago
  Java is great for making huge well-organized codebases with a lot of developers, especially if you've got good tooling support or a rich ecosystem of existing code to work with. Outside of that... If it was a good development ecosystem for native gui-based apps targeted at end users, why wouldn't the preponderance of native user-facing apps be written in Java, anyway? Ask nearly any experienced mobile app developer if they're more productive in Java on Android or Swift on iOS-- it's not even close. Sure, some of that is the OS itself, but a whole lot of it isn't. On the desktop, the one time I tried to make something with Swing I wanted to Fling my computer out the window. Clunky.
  - skydhash 3y ago
    It’s about branding. Swing and JavaFX looks like other desktop app (aka not cool to a lot of designers). And it has a high barrier of entry (ever tried QT, AppKit or Win32). Electron is easy, but it’s shoehorning a document process to software interfaces.
    - chefandy 3y ago
      Yeah the architecture for electron is absurd, but it's important to not relegate UI flexibility to mere aesthetics. For most of my career, I was a back-end web developer, but more recently I've done a lot of interface design after getting some formal education in it. The overwhelming majority of developers I've worked and interacted with conflate aesthetic and interface usability. Heck, even I did before I really started digging into it professionally. I think it's because applications that have experienced designers make a good, usable interfaces will also likely hire visual designers to do aesthetic/branding work, and especially in waterfall environments, developers get it all handed to them as a "design." And for many reasons I will (uncharacteristically) not rehash here, FOSS lacks both. However, a good interface and a pretty interface are not the same thing-- both are communication mediums that communicate through the software interface, but visual/branding/identity designers communicate things to the user about the brand as a marketing device, and interface designers figure out how to communicate the software's features, status, output, etc. with the greatest efficiency and reduce unnecessary cognitive overhead. Branding and identity is a very specialized form of design that's usually done by design houses-- even huge companies with big teams of designers often contract this work out to specialists. They might go so far as to recommend certain animations for interaction, but you don't want them designing your interface. In small companies, the designer will probably have to implement their design to conform to the design document, but they're using tools like gestalt, alignment, color grouping and type to create information hierarchies, existing expectations for layout and functionality, etc. that tell the user what they need to know as effectively as possible, and how to act on that in the ways they need to. A good example of the power of interface design is in many dark patterns. You can simply have a plain system-standard dialog box asking if a user consents to some creepy analytics that nobody really wants, but instead of "OK" and "Cancel" in their normal spots, put "Off" in bold letters where "Ok" would normally be, and "Consent" in non-bold letters where "Cancel" would normally be, and I'll bet you at least 60% of users would choose "Consent" having only skimmed the familiar pattern. That experience isn't branded or styled in any way-- it solely uses juxtaposition, pattern expectations, and context to influence users behavior. When you've got an inflexible, counterintuitive UI kit that developers must fight with to get the results the interface designer carefully put together, you hurt the usability of that tool for end users a hell of a lot more than mediocre performance does. This is very counterintuitive for most developers because of the curse of expertise. We have a working mental model of how software works on the back end and consider the interface a tool to expose that functionality to the user. To users, the interface is the software, and if you're design is more informed by the way the software works under the hood than the way a nontechnical user thinks about solving the problem they're trying to solve, it's going to be very frustrating for everyone who isn't a developer. Developers like to talk about marketing as the primary reason commercial software is king, and it's definitely a factor, but developers aren't magically immune to marketing, and you can't get much more compelling than "Free." To most users, the frustration of dealing with interfaces designed by and (inadvertently) for developers is worse than paying for software--- hence FOSS nearly exclusively being adopted by technical people.
- em-bee 3y ago
  when i see a java application i think, hmm, this is likely going to be bloated (but not necessarily) but for sure it's going to run. if i want to create a cross platform application where i don't even have to think about testing on multiple operating systems, then java is going to be a serious contender. and if i have to choose between an app written in java or electron, i'd probably pick the one in java. so yeah, i don't understand what happened here either.
- paulddraper 3y ago
  If Java applets were anywhere as popular as JavaScript web apps, I'm sure Java desktop would be as popular as Election. But Java applets aren't popular.
- account42 3y ago
  The JRE itself is an external dependency that you need to bunle because it is not part of most Linux distributions. And even if there is a JRE installed it is not guaranteed to be able to run your Java application. So yeah if you redefine your problem to "run on systems with the right JRE" then Java makes things "easy" (your program will still stick out like an unpolished turd). But if you can just require stuff like that than you can also require the right dependency versions for native programs.
zlg_codes 3y ago
As someone who uses Linux as a daily driver, I can recognize these gargantuan apps a mile away and stay away from them. They are absolute hogs of system resources, and for something simple like Etcher there's no excuse. Things like Electron are good for devs but bad for users. We have more computation power than ever and yet programs still run slow.
- FirmwareBurner 3y ago
  Oh, it gets better. Even the default Weather app shipping with Windows 11 is also an Electron pile of trash that uses ~520 MB of RAM. Just let that sink in. 500MB of RAM just to show you the weather forecast for the day and week. That was my entire system RAM of my Windows XP gaming rig. Same for the Widgets app, it's not only bad because it shows you news and ads when you open it, it's worse because it's also, you guessed it, an Electron app. Some VP in Redmond must be off their meds. I assume Microsoft just can't find devs to write C#, their own damn programing language for their own OS, and one of the dozens of frameworks they have for Windows GUI, that they need to resort to using Electron for what are just Windows-only apps.
  - ziml77 3y ago
    The Weather app in Windows 11 a UWP .NET Native wrapper around WebView2 controls. It's exceptionally silly that it's basically just a web browser with predefined tabs and that it uses so much RAM, but it's not Electron.
    - FirmwareBurner 3y ago
      Oh my bad. I think I saw it call some Edge system components in task manager and I assumed it must be Electron.
  - zlg_codes 3y ago
    Good lord, that's crazy, haha. You'd think with all of their different frameworks, one would have been more suitable than starting from scratch with a browser tab, jeez. I recently upgraded to 10 because of Steam requiring it in a few weeks, and it's been an adventure. Lots of crashes and restarts that I didn't ask for. I really don't know who exactly modern Windows is for, because I'm a gamer and programmer and it's not been good for either of those tasks... Windows 7 was solid and I almost never had issues out of it. It booted and got out of the way.
nmz 3y ago
I like to shit on electron because plain old tcl/tk is a better/leaner alternative. Apart from the myriad of other[0] alternatives that exist. [0]: https://github.com/sudhakar3697/awesome-electron-alternatives https://github.com/sudhakar3697/awesome-electron-alternative...
- chefandy 3y ago
  I think that anyone who recommends Electron to a young developer interested in learning native application GUI programming should be slapped. It's the wrong tool for a specific job. That's a pretty niche use case to judge overall worthiness against, though.
- zer0zzz 3y ago
  I suspect the biggest issue with electron is that it leads to lots of devs packaging various V8 versions individually with their app. On windows they have been trying to get devs to switch to something called WebView2 where the OS provides an electron compatible chromium where unlike electron the resources are centrally managed by the OS.
account42 3y ago
I'd rather use Wine than Electron tbh.

deleted 3y ago

[deleted]

FirmwareBurner 3y ago

Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?

zer0zzz 3y ago
Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.
- FirmwareBurner 3y ago
  Why is it terrible? Asking for real.
  - LeoNatan25 3y ago
    Because it’s not “sexy” anymore. Now “sexiness” lies with web crap, so Electron is a “great tool”, while Java is “terrible”.
  - zer0zzz 3y ago
    Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.
    - FirmwareBurner 3y ago
      > The original interpreted stack-based JVM model is really bad for performance And we addressed that today by launching a copy of Chrome with every app?
      - zer0zzz 3y ago
        yes I think it's hard to beat the tide that is the web as a content and app delivery system. The web is also getting all the billions in investment from every massive faang.
      - 3y ago
  - mikrotikker 3y ago
    It's got more security holes than Swiss cheese.
    - samus 3y ago
      You're living in the past. Applets and Flash lost against the HTML/JS/CSS stack and Oracle owned up to it. Applets are terminally deprecated now. Edit: admittedly, one of the reasons for that was that the sandbox was indeed prone to security holes. Also, the developer ergonomy of the SecurityManager was unsatisfying for both JDK and app developers. Good riddance.
      - mnd999 3y ago
        Applets are still a thing. We just call them webasm and canvas these days.
        samus 3y ago
        The crucial difference is that these technologies are embedded differently. Java Applets had access to dangerous APIs that had to be restricted by the SecurityManager. Also, the JVM was installed externally to the browser, turning it into an uncontrollable component which made the browser vulnerable in turn. The newer technologies were designed from the beginning with a well-defined security boundary and are based on a language that was designed from the beginning to be embedded. Everything is implemented within the browser and can be updated together with it.
      - mikrotikker 3y ago
        I'm living in the future. We have golang and rust now. Java is a pile of junk and should be relegated to the past.
        samus 3y ago
        Golang's only consistent advantage over Java is lower latency on compilation, startup, and GC. OpenJDK will eventually level the playing field with Project Valhalla. In terms of FFI and language features Java has already caught up. And faster startup can be achieved with CRaC. Rust in turn is not competing with Java.
creesch 3y ago
Java simply has a much higher barrier of entry. Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. Electron isn't just cross platform, it is cross platform based on technologies (html, css and javascript) that also by a huge margin have the largest amount of developers available.
- whartung 3y ago
  > Not only in regards to figuring out the language and resources available but also the fact that creating a GUI still requires external dependencies. What external dependencies does Java need that's not in the JDK itself? I have an app with Mac and Windows installers (and thus bundles JDKs), it also runs on Linux (via a fat jar), I tested it on Ubuntu, but for the life of me I couldn't figure out how to package it properly. It was more complicated that I cared to invest it at the time. As for the barrier to entry, I feel the same way about the web. I find the JS and Web ecosystem to be utterly overwhelming, one reason I stuck with Java over something like Electron, and the installers/footprint of the app are smaller to boot.
  - creesch 3y ago
    > What external dependencies does Java need that's not in the JDK itself? I mean that it doesn't come with Java itself, but you as a developer need to pick a UI framework and not all of them actually work all that well cross platform or will get you an actual modern interface. Edit: I should also note that the threshold for entry I am talking about is for people just generally starting out. There simply are way more resources available for web related development than there are for java. Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore.
    - ElectricalUnion 3y ago
      > Also, when you start bundling your JDKs I am not sure you can talk about a smaller footprint anymore. What, do you bundle Electron source and Electron build environment with your Electron app? Why would you do the same and bundle Java source code + Java compilers in your Java app? Why would you do the same and bundle <any language> source code + <any language> compilers in your <any language> app? If you need to create a "just works without dependency b.s." experience in Java, you use the correct tooling for that, jlink.
zlg_codes 3y ago
It's the JS kiddies. They got Node and then decided the whole world should be written in Javascript, lol.
chefandy 3y ago
Java is great for making huge well-organized codebases with a lot of developers, especially if you've got good tooling support or a rich ecosystem of existing code to work with. Outside of that... If it was a good development ecosystem for native gui-based apps targeted at end users, why wouldn't the preponderance of native user-facing apps be written in Java, anyway? Ask nearly any experienced mobile app developer if they're more productive in Java on Android or Swift on iOS-- it's not even close. Sure, some of that is the OS itself, but a whole lot of it isn't. On the desktop, the one time I tried to make something with Swing I wanted to Fling my computer out the window. Clunky.
- skydhash 3y ago
  It’s about branding. Swing and JavaFX looks like other desktop app (aka not cool to a lot of designers). And it has a high barrier of entry (ever tried QT, AppKit or Win32). Electron is easy, but it’s shoehorning a document process to software interfaces.
  - chefandy 3y ago
    Yeah the architecture for electron is absurd, but it's important to not relegate UI flexibility to mere aesthetics. For most of my career, I was a back-end web developer, but more recently I've done a lot of interface design after getting some formal education in it. The overwhelming majority of developers I've worked and interacted with conflate aesthetic and interface usability. Heck, even I did before I really started digging into it professionally. I think it's because applications that have experienced designers make a good, usable interfaces will also likely hire visual designers to do aesthetic/branding work, and especially in waterfall environments, developers get it all handed to them as a "design." And for many reasons I will (uncharacteristically) not rehash here, FOSS lacks both. However, a good interface and a pretty interface are not the same thing-- both are communication mediums that communicate through the software interface, but visual/branding/identity designers communicate things to the user about the brand as a marketing device, and interface designers figure out how to communicate the software's features, status, output, etc. with the greatest efficiency and reduce unnecessary cognitive overhead. Branding and identity is a very specialized form of design that's usually done by design houses-- even huge companies with big teams of designers often contract this work out to specialists. They might go so far as to recommend certain animations for interaction, but you don't want them designing your interface. In small companies, the designer will probably have to implement their design to conform to the design document, but they're using tools like gestalt, alignment, color grouping and type to create information hierarchies, existing expectations for layout and functionality, etc. that tell the user what they need to know as effectively as possible, and how to act on that in the ways they need to. A good example of the power of interface design is in many dark patterns. You can simply have a plain system-standard dialog box asking if a user consents to some creepy analytics that nobody really wants, but instead of "OK" and "Cancel" in their normal spots, put "Off" in bold letters where "Ok" would normally be, and "Consent" in non-bold letters where "Cancel" would normally be, and I'll bet you at least 60% of users would choose "Consent" having only skimmed the familiar pattern. That experience isn't branded or styled in any way-- it solely uses juxtaposition, pattern expectations, and context to influence users behavior. When you've got an inflexible, counterintuitive UI kit that developers must fight with to get the results the interface designer carefully put together, you hurt the usability of that tool for end users a hell of a lot more than mediocre performance does. This is very counterintuitive for most developers because of the curse of expertise. We have a working mental model of how software works on the back end and consider the interface a tool to expose that functionality to the user. To users, the interface is the software, and if you're design is more informed by the way the software works under the hood than the way a nontechnical user thinks about solving the problem they're trying to solve, it's going to be very frustrating for everyone who isn't a developer. Developers like to talk about marketing as the primary reason commercial software is king, and it's definitely a factor, but developers aren't magically immune to marketing, and you can't get much more compelling than "Free." To most users, the frustration of dealing with interfaces designed by and (inadvertently) for developers is worse than paying for software--- hence FOSS nearly exclusively being adopted by technical people.
em-bee 3y ago
when i see a java application i think, hmm, this is likely going to be bloated (but not necessarily) but for sure it's going to run. if i want to create a cross platform application where i don't even have to think about testing on multiple operating systems, then java is going to be a serious contender. and if i have to choose between an app written in java or electron, i'd probably pick the one in java. so yeah, i don't understand what happened here either.
paulddraper 3y ago
If Java applets were anywhere as popular as JavaScript web apps, I'm sure Java desktop would be as popular as Election. But Java applets aren't popular.
account42 3y ago
The JRE itself is an external dependency that you need to bunle because it is not part of most Linux distributions. And even if there is a JRE installed it is not guaranteed to be able to run your Java application. So yeah if you redefine your problem to "run on systems with the right JRE" then Java makes things "easy" (your program will still stick out like an unpolished turd). But if you can just require stuff like that than you can also require the right dependency versions for native programs.

zlg_codes 3y ago

As someone who uses Linux as a daily driver, I can recognize these gargantuan apps a mile away and stay away from them. They are absolute hogs of system resources, and for something simple like Etcher there's no excuse. Things like Electron are good for devs but bad for users. We have more computation power than ever and yet programs still run slow.

FirmwareBurner 3y ago
Oh, it gets better. Even the default Weather app shipping with Windows 11 is also an Electron pile of trash that uses ~520 MB of RAM. Just let that sink in. 500MB of RAM just to show you the weather forecast for the day and week. That was my entire system RAM of my Windows XP gaming rig. Same for the Widgets app, it's not only bad because it shows you news and ads when you open it, it's worse because it's also, you guessed it, an Electron app. Some VP in Redmond must be off their meds. I assume Microsoft just can't find devs to write C#, their own damn programing language for their own OS, and one of the dozens of frameworks they have for Windows GUI, that they need to resort to using Electron for what are just Windows-only apps.
- ziml77 3y ago
  The Weather app in Windows 11 a UWP .NET Native wrapper around WebView2 controls. It's exceptionally silly that it's basically just a web browser with predefined tabs and that it uses so much RAM, but it's not Electron.
  - FirmwareBurner 3y ago
    Oh my bad. I think I saw it call some Edge system components in task manager and I assumed it must be Electron.
- zlg_codes 3y ago
  Good lord, that's crazy, haha. You'd think with all of their different frameworks, one would have been more suitable than starting from scratch with a browser tab, jeez. I recently upgraded to 10 because of Steam requiring it in a few weeks, and it's been an adventure. Lots of crashes and restarts that I didn't ask for. I really don't know who exactly modern Windows is for, because I'm a gamer and programmer and it's not been good for either of those tasks... Windows 7 was solid and I almost never had issues out of it. It booted and got out of the way.

nmz 3y ago

I like to shit on electron because plain old tcl/tk is a better/leaner alternative. Apart from the myriad of other[0] alternatives that exist. [0]: https://github.com/sudhakar3697/awesome-electron-alternatives https://github.com/sudhakar3697/awesome-electron-alternative...

chefandy 3y ago
I think that anyone who recommends Electron to a young developer interested in learning native application GUI programming should be slapped. It's the wrong tool for a specific job. That's a pretty niche use case to judge overall worthiness against, though.
zer0zzz 3y ago
I suspect the biggest issue with electron is that it leads to lots of devs packaging various V8 versions individually with their app. On windows they have been trying to get devs to switch to something called WebView2 where the OS provides an electron compatible chromium where unlike electron the resources are centrally managed by the OS.

account42 3y ago

I'd rather use Wine than Electron tbh.