13 ms·

If you require a UI that is pretty heavy, here is my pro* tip to save time when developing for both Windows and macOS. 1) Buy a basic HTML template online for

If you require a UI that is pretty heavy, here is my pro* tip to save time when developing for both Windows and macOS. 1) Buy a basic HTML template online for your app's dashboard. 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) 3) Use the built in script calling functions to transfer settings back and forth between the UI and main app in JSON. Do the back end stuff in native code. 4) You can then re-use most of the UI code you wrote to easily port over to macOS. Use the same functions and logic you wrote on Windows to make your Swift functions. * I've been making a living from building/maintaining my desktop application for about 5 years and had no regrets setting it up this way. I've also seen a number of other expensive, high-end, "professional" software using the FEATURE_BROWSER_EMULATION registry key trick. Good luck!

itwy 6y ago
But you'll lose quite a few things offered by Electron, such as notifications, taskbar/menubar, FS access, etc.
- ido 6y ago
  Most of the app will still be c++/c#/java/whatever & be able to do these, only the UI will be HTML/css/js via the OS's web view.
ffhhj 6y ago
I also do this on my mobile apps given how difficult it's to work with Android layouts.
nepthar 6y ago
Can you provide an example of an app that does this? I'm just curious to see how to looks.
- ma2rten 6y ago
  You can look at OP's profile.
ma2rten 6y ago
Don't use Electon. Your users WILL notice and complain about performance. How will people notice if you are using Electon, but not if you are doing this? Is Electron doing something that makes it unnecessarily slow or are you saying that people are just conditioned to think Electron apps are slower?
- ddek 6y ago
  Electron is a full instance of chromium. Running an electron app is essentially running a browser, which is a heavy application. All that heft translates to inefficiency.
  - toastal 6y ago
    With options like Firefox's SSB, you can use pages like 'apps' but at use the browser's resource pool instead of spinning up multiple Chromium instances.
    - mijoharas 6y ago
      ... but that's not what electron does. Unless I'm missing something that I really don't understand...
      - toastal 6y ago
        It's my understanding that since each app is shipping with its own Electron version/runtime, that the resources of these are not and can't be shared or managed centrally. A chromeless web app running via the browser would effectively be just another tab use the current browser's resources (and extensions +1).
        mijoharas 6y ago
        Agreed. Sorry, I took your previous comment as arguing against the comment it was in reply to. I was quite keen on chrome apps, as they allowed you to share the chrome browser runtime in a similar way. If you add a native desktop shortcut, and use the chrome-hiding features then you can basically replace electron with a shared runtime. I have a dim memory that it may have been killed/hobbled now though...
sime2009 6y ago
Can you give us any idea of the kinds of apps you've been doing with this approach? What kind of UI complexity are we talking about here? I suspect that the needed complexity of the UI factors in heavily as to how well this approach will work.
bgdam 6y ago
> 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.
- ricardobeat 6y ago
  > Basic things that would work in IE10 are known to break on desktop webviews Do you have examples of that? I believe the majority of users will be running a quite recent version of Safari and Edge in these circumstances.
  - chaz72 6y ago
    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.)
    - 6y ago
benbristow 6y ago
> 1) Buy a basic HTML template online for your app's dashboard. I've never had good experiences with templates. They usually have too many dependencies or too many custom tweaks. There's one I'm using on a project at work (was chosen before I joined) and it's a huge mishmash of Bootstrap/Material Design and other stuff. Proper mess. Much easier to just choose a style framework like Bootstrap and build it yourself. 2> Instead, use the native WebBrowser control in .NET for Windows Use WebView2 instead. It uses the new Edge/Chromium rendering engine - https://docs.microsoft.com/en-us/microsoft-edge/webview2/ https://docs.microsoft.com/en-us/microsoft-edge/webview2/
- ChrisSD 6y ago
  According to those docs: > The WebView2 Preview is intended for early prototyping and to gather feedback to help shape the API. You should not use the preview in your production apps because there may be breaking changes.
  - benbristow 6y ago
    A preview build vs Internet Explorer/Trident based rendering engine. I'd take my chances. Or just use Electron
- dkersten 6y ago
  I agree regarding templates, the ones I’ve used all were pretty low quality. Something like this may be more appropriate: https://news.ycombinator.com/item?id=24030581 https://news.ycombinator.com/item?id=24030581
karyon 6y ago
that's how the start page of Autodesk Civil3D's and InfraWork's are built (steps 2 and 3 only). Screenshot here: https://knowledge.autodesk.com/support/infraworks/learn-explore/caas/CloudHelp/cloudhelp/ENU/InfraWorks-UserHelp/files/GUID-01AABC51-386E-4E5B-A901-C317CBC050E3-htm.html https://knowledge.autodesk.com/support/infraworks/learn-expl... There's not much more to it than you can see, there's the BIM360 tab on the left that allows browsing through a cloud directory structure, and Civil3D also has a learning content tab. Qt-based Software uses Qt WebEngine instead of the .NET stuff. The reason we're using HTML + JS is that we wanted to share the start page between different applications and HTML + JS is the lowest common denominator so to say, something that every team could integrate.
loarabia 6y ago
I do agree on avoiding electron if possible as users do notice. I've seen folks who perhaps don't know the intricate details of software run into performance issues. A public example: Dwyrin is a YouTube streamer playing Go/Baduk. After most streams he reviews the game and likes an app called Sabaki. About 8:10 minutes in, he remarks on the performance of the app (https://youtu.be/vrX4qlbpQfU?t=492 https://youtu.be/vrX4qlbpQfU?t=492). Sabaki is an electron based app. I do however disagree with removing right click / highlighting. That makes copy paste difficult or impossible for the typical user. I spent years working on Silverlight and UWP and one of the things I recall the team looking back on particularly with Silverlight and regretting was that TextBlocks by default didn't have highlightable text. Its too useful for users sharing error messages with you as the developer or data with each other to get their jobs done.
- Tarks 6y ago
  When I see apps going Electron to me they're saying "I care more about making this easily available and focusing on features other than performance" - which is absolutely fine it's a value statement. Electron likely helped Sabaki focus on other features with good enough performance, while being the best looking and most skinnable Go app by a country mile (I created a How to train your Dragon skin to temp my partner into learning Go :D) Only so many hours to dedicate to a project, you have to pick what you value most. This comme T is partially because I'd hate for the people involved with Sabaki to not hear that at least some of their users "get it" and love it.
yboris 6y ago
A blanket statement about Electron is just bad advice. If you are making an application that you expect users to run as a background process, perhaps Electron isn't the best option. If Electron is for an application users will open, use, and close, Electron is an excellent tool for the job. My two electron applications as examples: Video Hub App: https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App & https://videohubapp.com/ https://videohubapp.com/ Simplest File Renamer: https://github.com/whyboris/Simplest-File-Renamer https://github.com/whyboris/Simplest-File-Renamer & https://yboris.dev/renamer/ https://yboris.dev/renamer/
m-p-3 6y ago
It's awful how many apps have to rely on their own separate engines though. Isn't there a way to rely on the new "Edgium" engine, which should be mostly at the same version that Chrome is and kept updated by the OS?

itwy 6y ago

But you'll lose quite a few things offered by Electron, such as notifications, taskbar/menubar, FS access, etc.

ido 6y ago
Most of the app will still be c++/c#/java/whatever & be able to do these, only the UI will be HTML/css/js via the OS's web view.

ffhhj 6y ago

I also do this on my mobile apps given how difficult it's to work with Android layouts.

nepthar 6y ago

Can you provide an example of an app that does this? I'm just curious to see how to looks.

ma2rten 6y ago
You can look at OP's profile.

ma2rten 6y ago

Don't use Electon. Your users WILL notice and complain about performance. How will people notice if you are using Electon, but not if you are doing this? Is Electron doing something that makes it unnecessarily slow or are you saying that people are just conditioned to think Electron apps are slower?

ddek 6y ago
Electron is a full instance of chromium. Running an electron app is essentially running a browser, which is a heavy application. All that heft translates to inefficiency.
- toastal 6y ago
  With options like Firefox's SSB, you can use pages like 'apps' but at use the browser's resource pool instead of spinning up multiple Chromium instances.
  - mijoharas 6y ago
    ... but that's not what electron does. Unless I'm missing something that I really don't understand...
    - toastal 6y ago
      It's my understanding that since each app is shipping with its own Electron version/runtime, that the resources of these are not and can't be shared or managed centrally. A chromeless web app running via the browser would effectively be just another tab use the current browser's resources (and extensions +1).
      - mijoharas 6y ago
        Agreed. Sorry, I took your previous comment as arguing against the comment it was in reply to. I was quite keen on chrome apps, as they allowed you to share the chrome browser runtime in a similar way. If you add a native desktop shortcut, and use the chrome-hiding features then you can basically replace electron with a shared runtime. I have a dim memory that it may have been killed/hobbled now though...

sime2009 6y ago

Can you give us any idea of the kinds of apps you've been doing with this approach? What kind of UI complexity are we talking about here? I suspect that the needed complexity of the UI factors in heavily as to how well this approach will work.

bgdam 6y ago

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

ricardobeat 6y ago
> Basic things that would work in IE10 are known to break on desktop webviews Do you have examples of that? I believe the majority of users will be running a quite recent version of Safari and Edge in these circumstances.
- chaz72 6y ago
  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.)
  - 6y ago

benbristow 6y ago

> 1) Buy a basic HTML template online for your app's dashboard. I've never had good experiences with templates. They usually have too many dependencies or too many custom tweaks. There's one I'm using on a project at work (was chosen before I joined) and it's a huge mishmash of Bootstrap/Material Design and other stuff. Proper mess. Much easier to just choose a style framework like Bootstrap and build it yourself. 2> Instead, use the native WebBrowser control in .NET for Windows Use WebView2 instead. It uses the new Edge/Chromium rendering engine - https://docs.microsoft.com/en-us/microsoft-edge/webview2/ https://docs.microsoft.com/en-us/microsoft-edge/webview2/

ChrisSD 6y ago
According to those docs: > The WebView2 Preview is intended for early prototyping and to gather feedback to help shape the API. You should not use the preview in your production apps because there may be breaking changes.
- benbristow 6y ago
  A preview build vs Internet Explorer/Trident based rendering engine. I'd take my chances. Or just use Electron
dkersten 6y ago
I agree regarding templates, the ones I’ve used all were pretty low quality. Something like this may be more appropriate: https://news.ycombinator.com/item?id=24030581 https://news.ycombinator.com/item?id=24030581

karyon 6y ago

that's how the start page of Autodesk Civil3D's and InfraWork's are built (steps 2 and 3 only). Screenshot here: https://knowledge.autodesk.com/support/infraworks/learn-explore/caas/CloudHelp/cloudhelp/ENU/InfraWorks-UserHelp/files/GUID-01AABC51-386E-4E5B-A901-C317CBC050E3-htm.html https://knowledge.autodesk.com/support/infraworks/learn-expl... There's not much more to it than you can see, there's the BIM360 tab on the left that allows browsing through a cloud directory structure, and Civil3D also has a learning content tab. Qt-based Software uses Qt WebEngine instead of the .NET stuff. The reason we're using HTML + JS is that we wanted to share the start page between different applications and HTML + JS is the lowest common denominator so to say, something that every team could integrate.

loarabia 6y ago

I do agree on avoiding electron if possible as users do notice. I've seen folks who perhaps don't know the intricate details of software run into performance issues. A public example: Dwyrin is a YouTube streamer playing Go/Baduk. After most streams he reviews the game and likes an app called Sabaki. About 8:10 minutes in, he remarks on the performance of the app (https://youtu.be/vrX4qlbpQfU?t=492 https://youtu.be/vrX4qlbpQfU?t=492). Sabaki is an electron based app. I do however disagree with removing right click / highlighting. That makes copy paste difficult or impossible for the typical user. I spent years working on Silverlight and UWP and one of the things I recall the team looking back on particularly with Silverlight and regretting was that TextBlocks by default didn't have highlightable text. Its too useful for users sharing error messages with you as the developer or data with each other to get their jobs done.

Tarks 6y ago
When I see apps going Electron to me they're saying "I care more about making this easily available and focusing on features other than performance" - which is absolutely fine it's a value statement. Electron likely helped Sabaki focus on other features with good enough performance, while being the best looking and most skinnable Go app by a country mile (I created a How to train your Dragon skin to temp my partner into learning Go :D) Only so many hours to dedicate to a project, you have to pick what you value most. This comme T is partially because I'd hate for the people involved with Sabaki to not hear that at least some of their users "get it" and love it.

yboris 6y ago

A blanket statement about Electron is just bad advice. If you are making an application that you expect users to run as a background process, perhaps Electron isn't the best option. If Electron is for an application users will open, use, and close, Electron is an excellent tool for the job. My two electron applications as examples: Video Hub App: https://github.com/whyboris/Video-Hub-App https://github.com/whyboris/Video-Hub-App & https://videohubapp.com/ https://videohubapp.com/ Simplest File Renamer: https://github.com/whyboris/Simplest-File-Renamer https://github.com/whyboris/Simplest-File-Renamer & https://yboris.dev/renamer/ https://yboris.dev/renamer/

m-p-3 6y ago

It's awful how many apps have to rely on their own separate engines though. Isn't there a way to rely on the new "Edgium" engine, which should be mostly at the same version that Chrome is and kept updated by the OS?