Sadly all of this was solved years ago with Adobe Air (single engine, real automated updates, plus a more sane Javascript syntax with AS3). I haven't used it in years but I just took a quick look and the last release was today - https://labs.adobe.com/downloads/air.html

I know there is a lot of Flash hate out there but Air+Flex(+FlashDevelop) was a pretty nice solution for building , debugging and distributing cross platform apps.

I was a Flash dev for years, and then kept on doing Adobe Air apps for museums and mobile. Adobe dropped the ball on it pretty quick once HTML5 went mainstream. New features and bug fixes take ages.

I still think AS3 is one of the best languages I've ever used. It was really ahead of its time.

"New features and bug fixes take ages."

ORLY?

It has been many years that Adobe AIR is updated on a quarterly basis, every March, June, September and December

https://www.adobe.com/devnet/articles/flashplayer-air-featur...

So?

Major features are the ones that matter. It took Adobe like 3-4 years to bring concurrency to iOS. AS4 was killed after years of promises. Etc.

Maybe I’m remembering this wrong, but doesn’t Adobe Air work on Windows and macOS only?

I was trying to install an Adobe Air app on a Linux machine a while back and ran into this problem.

They stopped Linux support in 2011 - https://helpx.adobe.com/air/kb/install-air-2-64-bit.html

support has stopped true but it does not prevent to publish on Linux desktop targeting AIR 2.6

ironically you can also embed Flash into an Electron app to use the latest v28 runtime

other workaround exists with the latest NPAPI that you can embed in a C++ app (like good old WxWidgets)

I've been using the Sciter bindings for Rust, lately. It might be worth a look if you want a more performant option for a HTML/CSS GUI. The documentation is pretty rough, though.

https://sciter.com/

https://github.com/sciter-sdk/rust-sciter

Interesting. Any indication of why Sciter seems to be the go-to UI framework for antivirus software?

I appreciate you sharing that more for their shared-source licensing model than anything else. I don't have many examples of paid source to draw on in those discussions.

> 1) There is no way to separate the Electron engine from your app, so you have to bundle Chrome and Node with each app.

I'm really curious (as a non-Electron developer) why that's a problem at all, let alone a big problem. You have to provide the entire package, but you have control over what the user gets and ultimately, what you'll have to support.

What's old is new again. Same problem shared libraries solve:

1. Disk space. Electron, node, shared dependencies, that adds up. 300-500mb/app is not reasonable. 10 apps installed? 5 gigabytes! Wtf?

2. Security updates. Security issue in blink/v8? You need to update 10 apps instead of 1 lib. And I sure hope those apps are responsible enough to update themselves.

3. Bonus: CPU&RAM. Want to run 3 apps? Well, have fun with your 3 instances of chrome running. It adds up. I have 16GB of ram, I used to think it would last me forever and then the electron craze started to seriously limit me in the amount of concurrency I can have on my desktop.

Like GP said, Electron for UI is a valid pattern that has some pretty extreme issues preventing it from being a straight up good pattern. My bet is that an electron server on the desktop solves all this.

Re: disk space

Just glanced at my Applications folder on OSX. Slack's looks to weigh in at 180 MB and VS Code at 160 MB. Am I missing something?

It means a lot of extra space. You are duplicating installations of Chrome and Node for each Electron app that is installed, instead of having one install and each app using the common dependency.

So yes, the developer gets complete control over which version of Chrome and Node is used, but you end up with a 150 MB text editor, a 150 MB chat app, and a 150 MB music streaming app, when you could probably get all three done with 152 MB using common dependencies.

Is storage space really that big of a concern, with many multiple terabyte drives being commonplace? Out of all of the issues with electron, I don't think wasting 150MB is one of them.

Those are common, but small SSD are just as (if not more) common, so yes it matters. It's also a matter of RAM, which is not as abundant as disk space

OP is talking about wasting 300MB for each Electron-based app you install.

With many of the lower-end laptops, price-wise, having ~128GB of SSD space, yes, it's a concern.

I'm not sure that would fix the problem since the common dependencies would still be having to store different versions of Chrome.

I think it worked pretty well for NPM where there was the high possibility of duplication between the modules you depend on and the additional modules required by them.

Since you're doing .NET have you looked at https://github.com/AvaloniaUI/Avalonia for cross platform UIs? I haven't messed with it, but it just hit beta and I was hoping for some insights.

AvaloniaUI is only in alpha right now. Also, until there is integration with the native menu bar on macOS, it’s a non-starter for Mac apps[0].

[0]: Judging solely on the screenshots provided, which show a menu bar inside the app window on macOS. I’m sure things will improve with time.

>AvaloniaUI is only in alpha right now

Beta was released a week ago, actually - http://avaloniaui.net/blog/2018-02-18-avalonia-beta1.html

Or release it as a web application and let the user use chrome's "add do desktop" ... I don't like that you're dropping Linux compatibility, but understand the the reasoning.

We've done that on mobile, but most of users don't even know that feature exists and another big chunk still don't trust a website vs an app.

I've never seen this feature in desktop.

Closes thing I know are these "hosted web app" in Windows 10. https://docs.microsoft.com/en-us/windows/uwp/porting/hwa-cre...

The feature is only available in the Windows and Linux versions of Chrome.

https://www.lifewire.com/create-shortcuts-in-google-chrome-f...