Electron doesn't come without its drawbacks to the end user (though here we're talking more about developer experience than everything else):
every app shipping a web browser (big size)
a lot of RAM usage
We keep using VS Code as an example of a poster child for great usage of Electron but that's not an app for "regular" users (and has Microsoft's budget behind it).
Most desktop apps are not written by thousands of engineers and most users don't have 16 GB of RAM.
I'm not saying "bad Electron, bad" but I think that in context we should take into consideration both aspects seriously. Slack, which is famously a resource hog, it's an app that non developers might use and complain about.
I don't have hard numbers on this but I think it's likely that not caring about lowering resources occupation also drives the hardware industry (at least for people who can afford upgrading a computer because software developers give up optimizing).
In a sense it's like web programming: we create apps on shiny computers with fast networks and then comes the disadvantaged regular user that's going to curse us because they have a 700$ computer with a slow network.
I think we just do a disservice to everyone by plugging our favorite tool of the day all the time without considering their impact.
On the other side of the argument there's developer velocity and time to market, which are definitely important. I'm just saying everything should be weighed.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
You're not giving me any information that you didn't write before so I'm not sure how to answer this comment but I might have misunderstood it so my bad.
You don't have to ship Electron in every app.
How can you not ship Electron in an app that's based off Electron? You mentioned the possibility of sharing an Electron installation among multiple apps, but how can you be sure the end user already has at least one app? And what happens if the end user uninstalls the app that shipped with Chrome inside of it? Do the others stop working?
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
Yeah you're right but at least if you have multiple applications, it only requires one electron just like you don't have to install the .net framework for every application that uses it. Basically a global npm install.
And if you delete the.net framework and your application requires a minimum version it will stop working too.
Anyway long discussion, I was only recommending something I like to someone who seemed to be looking for it.
Yeah you're right but at least if you have multiple applications, it only requires one electron just like you don't have to install the .net framework for every application that uses it. Basically a global npm install.
Ok I understand. There's a slight difference though. .NET is guaranteed to be present in every modern Windows installation (setting aside various versions compatibility for a sec), so you might be guaranteed a minimum functionality (and maybe you can then install a powered up .NET version separately and wait for the next restart?).
If you look closely though there's not much to be shown for cross platform desktop apps written on .NET and I think one of the reasons is exactly because .NET on MacOS and Linux doesn't come prepackaged. Another possible reason is that Windows is a big enough market for smaller software vendors to prioritise.
Which, in a sense, it's the reason why Electron apps ship with their own Chrome. Yes, it might be technically possible to use the "shared Chrome", but you risk shrinking the user base to "only users with Chrome version xyz and onwards".
There's no easy answer here, which makes me think that's also one of the reason why people ship web apps instead of desktop apps. They don't want to deal with all of this hassle. The fact that Electron helps bringing "web screens" to the desktop is great by the way, at least for developer velocity and visual coherence for the end user.
I'm sure there's room for innovation in the space of cross platform UI runtimes, for example:
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
You are right there is no simple answer but in my experience (my personal opinion) when you want to develop a platform agnostic application you are better off using Electron than trying .NET core to run smoothly on each os. Also, .net core is great and all but not everything you do with .net on windows works on Linux or MacOS.
The System.Speech.Synthesis namespace for instance which is one I use a lot. Electron is a lot more consistent.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
Pellentesque nec neque ex. Aliquam at quam vitae lacus convallis pulvinar. Mauris vitae ullamcorper lacus. Cras nisi dui, faucibus non dolor quis, volutpat euismod massa. Donec et pulvinar erat.
Electron doesn't come without its drawbacks to the end user (though here we're talking more about developer experience than everything else):
We keep using VS Code as an example of a poster child for great usage of Electron but that's not an app for "regular" users (and has Microsoft's budget behind it).
Most desktop apps are not written by thousands of engineers and most users don't have 16 GB of RAM.
I'm not saying "bad Electron, bad" but I think that in context we should take into consideration both aspects seriously. Slack, which is famously a resource hog, it's an app that non developers might use and complain about.
I don't have hard numbers on this but I think it's likely that not caring about lowering resources occupation also drives the hardware industry (at least for people who can afford upgrading a computer because software developers give up optimizing).
In a sense it's like web programming: we create apps on shiny computers with fast networks and then comes the disadvantaged regular user that's going to curse us because they have a 700$ computer with a slow network.
I think we just do a disservice to everyone by plugging our favorite tool of the day all the time without considering their impact.
On the other side of the argument there's developer velocity and time to market, which are definitely important. I'm just saying everything should be weighed.
You don't have to ship Electron in every app. That was the point. Also it is still smaller than his Hello world.
You're not giving me any information that you didn't write before so I'm not sure how to answer this comment but I might have misunderstood it so my bad.
How can you not ship Electron in an app that's based off Electron? You mentioned the possibility of sharing an Electron installation among multiple apps, but how can you be sure the end user already has at least one app? And what happens if the end user uninstalls the app that shipped with Chrome inside of it? Do the others stop working?
Yeah you're right but at least if you have multiple applications, it only requires one electron just like you don't have to install the .net framework for every application that uses it. Basically a global npm install.
And if you delete the.net framework and your application requires a minimum version it will stop working too.
Anyway long discussion, I was only recommending something I like to someone who seemed to be looking for it.
Ok I understand. There's a slight difference though. .NET is guaranteed to be present in every modern Windows installation (setting aside various versions compatibility for a sec), so you might be guaranteed a minimum functionality (and maybe you can then install a powered up .NET version separately and wait for the next restart?).
If you look closely though there's not much to be shown for cross platform desktop apps written on .NET and I think one of the reasons is exactly because .NET on MacOS and Linux doesn't come prepackaged. Another possible reason is that Windows is a big enough market for smaller software vendors to prioritise.
Which, in a sense, it's the reason why Electron apps ship with their own Chrome. Yes, it might be technically possible to use the "shared Chrome", but you risk shrinking the user base to "only users with Chrome version xyz and onwards".
There's no easy answer here, which makes me think that's also one of the reason why people ship web apps instead of desktop apps. They don't want to deal with all of this hassle. The fact that Electron helps bringing "web screens" to the desktop is great by the way, at least for developer velocity and visual coherence for the end user.
I'm sure there's room for innovation in the space of cross platform UI runtimes, for example:
Revery - Cross-Platform Desktop Apps With Reason
K
Flutter is also another space where Google is trying alternative approaches to desktop development.
The status quo doesn't appeal to me :D
You are right there is no simple answer but in my experience (my personal opinion) when you want to develop a platform agnostic application you are better off using Electron than trying .NET core to run smoothly on each os. Also, .net core is great and all but not everything you do with .net on windows works on Linux or MacOS.
The System.Speech.Synthesis namespace for instance which is one I use a lot. Electron is a lot more consistent.
This attempt to popularize .Net and C# for this is cute but ultimately going to fail.
I don't think we're discussing to proclaim winners or losers, just to understand more about each platform's and approach's limitations.
I don't use either so I'm definitely learning new things :)
I recognize that (I feel this way about React and Angular) When I suggest Electron it is not because it is a 'favorite tool' that I want to insist on.