> 2) Don't use Electon. Your users WILL notice and complain about performance. Instead, use the native WebBrowser control in .NET for Windows and WebView using macOS to display your UI. Disable right clicking and highlighting using HTML/JS. To the user, it'll feel like any other native app. Add this meta tag to the HTML file to ensure the WebBrowser control knows to use new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge"> (and/or look up how to add the FEATURE_BROWSER_EMULATION registry key)
Going to heavily disagree here. Whether or not your user's will notice is debatable in itself, but you shouldn't really factor that into your decision making.
Instead you should ask if your users would care that it uses Electron, and more whether they would be sufficiently put off to look for alternatives. And in a vast majority of cases the response to that question is going to be 'No'.
But the second part of this comment, I disagree with even further. DO NOT USE A NATIVE WEBBROWSER CONTROL FOR YOUR DESKTOP APP's UI.
Sorry for yelling, but that really is that terrible an idea. Most native webview components lag behind the embedded chromium instance Electron uses by a lot. Basic things that would work in IE10 are known to break on desktop webviews. Primary reason for this is that these webviews are only updated with OS updates.
End result is you will have to bend over backwards to get your UI working as expected on all these native webviews. This is just too much work and will end up diverting attention from developing core features of your app to fixing rendering bugs instead.
> Instead you should ask if your users [...] would be sufficiently put off to look for alternatives.
This is probably sound business advice, but it's also a bit sad to shift the goal from trying to create "great software" to "not horrible enough to make all potential users run away".
Well here's the thing - developers have a finite amount of time on which they can work on something. Instead of spending that finite amount of time trying to create great software causing the release to be delayed, you could focus on the core functionality, with a slightly subpar user experience, and start delivering value to your users earlier.
I seem to remember a lot of Windows programs back in the day were webviews (backed by IE of course) and it was the most horrible unprofessional looking thing, especially when an Alert would pop up which revealed it was just an IE page.
> I seem to remember a lot of Windows programs back in the day were webviews (backed by IE of course)
Just how far "back in the day are we talking? 'Cause I've see stuff ranging from VB (just VB, no .NET or WinForms) all the way back to MFC based UIs back in _my_ day. :)
I just feel like we should get our timescales calibrated.
IMHO, I guess for 'us' (this community of savvy power-users/developers) they'll be flaky when it comes to logging-in whilst switching apps to generate passwords and 2FA codes...
But to the average user that reuses the same login and password on several websites, it'll probably be good enough.
I think they just missed the memo that Windows now has a modern Chromium-based Edge option for a web view component. I mean, before that, the situation was really pretty bad, but now I'd expect it to be fine. (Have not tested it yet.)
Actually this is not just a Windows issue, it's also something that impacts Mac OS. There have been instances where the native webview on MacOS had bugs that were not resolved until the next major release of OSX. (Can't seem to find a link, will add one later).
In addition, while Windows may now have an up to date version of Edge based on Chromium, which it now uses to render it's webviews, do you know that these Edge installations are not auto updated like Chrome/Firefox for Enterprise installations?
That means they will quickly fall behind from the current latest Chromium, and will throw bugs at some point in the future, when you rely on newer Chromium features. In addition, you will also get bug reports about your app being broken on some windows installations but not others and you will spend way too much time trying to figure out the issue, only to come to the conclusion that you can't really do anything other than change your code back to the older feature-set.
In addition, using Electron and bundling the Chromium along with it, allows you to control the Chromium version used, and you can be 100% certain that everything that works on that Chromium version will continue to do so, irrespective of the edition or number of updates installed on the user's computer.
Webapps have been dealing with this for years, it's not anywhere as painful as you are making it seem. Pick a base version to support, use feature detection to add anything new, and you're golden. The existing browser APIs cover 99% of all apps' needs already, and when you're doing this you can always hand-off things to the native layer as needed.
Electron sets a very unrealistic eternal-greenfield-development standard that is nothing like developing for the web.
It still might be a reasonable tradeoff for me, for some projects but regardless: thank you, that adds some nuance that I didn't get from your earlier comment.
> irrespective of the edition or number of updates installed on the user's computer.
That is the problem though, some user expected software to meet the platform he is using, use latest function the platform introduce, meet the brand new style guide. Claims the software is creepyware if it isn't.
And of course, the developer don't have infinite time and can't meet every demands the users request.
Making functions works between different platform is tough enough. The developer is unlikely to have enough time handles all extra optional platform best practices under the situation that developer don't have enough time to make one software for each platform at first place.
Going to heavily disagree here. Whether or not your user's will notice is debatable in itself, but you shouldn't really factor that into your decision making.
Instead you should ask if your users would care that it uses Electron, and more whether they would be sufficiently put off to look for alternatives. And in a vast majority of cases the response to that question is going to be 'No'.
But the second part of this comment, I disagree with even further. DO NOT USE A NATIVE WEBBROWSER CONTROL FOR YOUR DESKTOP APP's UI.
Sorry for yelling, but that really is that terrible an idea. Most native webview components lag behind the embedded chromium instance Electron uses by a lot. Basic things that would work in IE10 are known to break on desktop webviews. Primary reason for this is that these webviews are only updated with OS updates.
End result is you will have to bend over backwards to get your UI working as expected on all these native webviews. This is just too much work and will end up diverting attention from developing core features of your app to fixing rendering bugs instead.