Hacker News Reader

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

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

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.

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

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.

You can use asterisks to emphasize something, it will turn it into italic. See guidelines.

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

Webviews are okay on mobile though.

> Webviews are okay on mobile though.

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

Slack uses electron if I am not wrong.

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?

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.

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.

... but that's not what electron does.

Unless I'm missing something that I really don't understand...

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

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

As opposed to a "native webview", which is totally not essentially running a browser.

My impression was that running 10 Electron apps would be like having 10 separate installations of Chromium running at the same time (with no shared memory). But running 10 WebView apps would be like having one browser with 10 tabs open, but where a lot of the the browser resources are shared.

In that case, I would expect a large difference in memory footprint, although both options would be bad in terms of having a non-native user interface and user experience.

Is this incorrect?

The native webview use another instance of the engine, without running a complete web browser. If all apps did, the amount of resources required would be lower as they would share some common components.

To be fair, I haven't used Electron. At some point, I did try using Essential Object's EO.WebBrowser component for .NET which used similar amounts of RAM. People complained about the RAM usage, not performance.

I think the biggest problems with electron are memory usage, startup time, and possibly disk usage. All of which are because it's running a full browser instance.

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

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.

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://videohubapp.com/

Simplest File Renamer: https://github.com/whyboris/Simplest-File-Renamer & https://yboris.dev/renamer/

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

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.

A preview build vs Internet Explorer/Trident based rendering engine. I'd take my chances.

Or just use Electron

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

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

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

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.

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

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?

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.

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

You can look at OP's profile.