Is Electron really that bad? If so, are there any good alternatives that solve the two issues I mention above?
This is half the problem with Electron apps. I know perhaps Windows users are used to the random bullshit UI every developer comes up with (heck even Microsoft between it's own different software), but macOS users generally get very consistent UI's from native applications. Whatever you create using CSS is not going to fit in with that. If you need your app to be some special snowflake of UI design to stand out, it sounds like the actual functionality of it is commonplace or marginally different at best.
Also consider usability/accessibility. A native (i.e. Cocoa) macOS app gets lots of accessibility features 'for free'. I've heard it's possible to provide some/all of the same via Electron, but that its more work, and it's not done by default because it hurts performance even more than regular Electron apps.
Your argument about your reasons is literally the argument people use against the concept of Electron. "I want to do this, but I dont know how.. can I take a giant shortcut, and expect no repercussions?".
Electron is like those old Road Runner cartoons, where Wile E Coyote orders a "DIY Rocket" from ACME Corp, and sure enough, blows himself up.
If you know web dev, make a web app. If you want to make a native app, learn C/C++/Swift/ObjC/Java whatever.
Edit: I will clarify this with context. I do not write native applications. I have written a very quick (like, ~1-2 days total dev time) Cordova/PhoneGap app using similar tech, as an internal data-capture solution for people on a project (at the time, Safari on iOS didn't allow browsers to upload photos, and we needed to capture a lot of images quickly from our team on location, so I wrote a simple phone gap app and backend server, ran it from my laptop and installed the iOS apps from my laptop - it was never intended to be distributed)
So, that is one situation where Electron-type apps might be acceptable - if you need to do something quickly for an internal project, where a native browser doesn't give you the API, but Electron does. But Thats a lot of qualifiers, and you wouldn't be asking about it here if that was your intention, I imagine.
I've downloaded a fair number of Electron apps, and ultimately deleted or aborted the download of most of them. VSC is the one that currently survives.
If it's something that needs most of a browser and HTML - like an email client that cropped up as a Show HN recently, or a client for a wholly online service, Electron may be the right choice.
If it's something more trivial like a notepad, reminder, or timer, Electron is just needlessly making it unfriendly thanks to start time, and memory load. Multiple MBs shouldn't be necessary for a timer or calculator but Electron will make that so.
You may say that we have lots of memory these days, and we do. But I run lots of things these days, and if I have half a dozen such apps running in background I basically have half a dozen instances of Chrome. That's quite an extra load on memory and start times. It's also going to be one of the early casualties if my (or family tech support) laptop is starting to run low on memory.
Last, I think there is something to be said for Electron as an early version while testing, especially while still exploring UI and feature changes as you can focus on that not platform issues. Once you know what is needed, 9 times out of 10, give them a proper native program.
I disagree. These are cases where it's especially bad to use a HTML view as the application UI.
If your application is essentially a HTML page, and it's meant to render content from a foreign source, which is also HTML, JavaScript, what have you - how do you do that? An IFRAME?
You know that Electron apps have lower security sandboxing than a regular web browser right? Who in their right mind would use a web browser to render a html page as the UI of a web browser, and hope that the foreign source page doesn't break out of it's rendered context, to influence the appearance or routines of the 'browser' that loaded it?
That being said, I think the styling thing is a really important point that is often undervalued. I've written UIs in GTK, Qt, and Swing, and perhaps this is close-minded but I honestly can't take anyone who says that they're just as easy as HTML/CSS seriously. I mean, literally just look at how many beautiful websites are out there, and then how many beautiful, not just functional, native programs there are (in my opinion, very few). UX/UI is important, and I think not having to pull your hair out every time you want to move a button to the right 3 pixels and give it a prettier border is a big plus for Electron.
It is hard to understand people cares about memory useage when desktops nowadays have a lot of RAM. What average Electron apps annoys me is their constant high CPU load. Some apps take ~10% of CPU load all the time.
I think Electron itself is fine. Look at VS Code. It is fast even though it is written in Electron. The real problem is the bad habits of average Electron apps developers. The Electron devs usually come from Web where users can just press a refresh button or close it when browsers are slow. They don’t care about optimizing stuff.
The problem with the RAM consumption is not when you run a single Electron app in isolation, it's when you try and run a few of them and suddenly you're running hundreds of Chrome threads and you've used 8GB RAM.
How about a compromise. Instead of c++ why not learn Python instead and use pyside QT. This was actually what I ended up doing coming from webdev. You don't get the steep learning curve and can get a lot of the benefits from native apps. It won't be as fast as C++ but you won't have the overhead of electron. And besides most apps probably aren't going to need to brute performance of C++.
If your intended audience is a 'Show HN' expect to be damned for it. If your audience spans say Windows and Mac and are technical but perhaps less technical than HN readers it can be an easy way to extend your web app onto the desktop.
Also it might depend on whether your app needs to always run in the background or not. For example I use Pencil [0] for UX mockups, it doesn't bother me that it's an electron app because I only need it for a few days a month. However the persistent RAM use of Slack eventually annoyed me enough that I uninstalled it.
It's a great prototyping environment, and people have built businesses around Electron apps (VSCode is built on Electron, I believe). The apps I've built are big, kinda slow, and as others have mentioned tend to eat memory.
Wat. Microsoft isn't "built around" VSCode.
