[kodablah]

Nice project. However, I think Chrome is what people are talking about when they say Electron in heavy, not node. I have built apps with CEF and they are not really any lighter weight. You still have multiple processes of Chrome that are memory hogs. It's not like Electron's Chrome build has much more than CEF's.

[jug]

Since all major operating systems in their normal desktop-use configurations now come bundled with one of four browsers - Edge (Windows), Safari (macOS), Firefox or Chrome/ium (*nix) which are actually also all supporting at least HTML5 and CSS3 pretty well, I think it would be an interesting idea if a framework that turned web pages into "apps" could have the app configured to fire up the app in the system browser and not just embed Chromium.

It shouldn't be that horrible anymore to do it cross browser like that, at least as long as you follow web standards and ignore Internet Explorer, requiring Windows 10 support there.

And it would make these apps, of course, absolutely tiny.

How about using that as a starting point, and have that Electron alternative focus on making cross-browser development as painless as possible instead via built in Javascript shims/polyfills where necessary, and special API calls to integrate it into the underlying OS of course (OS native notifications etc)?

[pwa_examples]

Some example progressive web apps: https://pwa.rocks/

The enabling technologies, like service workers and web assembly are in the early stages of being supported across evergreen browsers. These are progressive, because they work in all modern browsers, but have extra capabilities like being "installable" on forward looking systems like, Android and Chrome OS.

It is a big deal when industry is willing to work together.

[xobs]

Web-View (https://github.com/Boscop/web-view) and Tether (https://github.com/quadrupleslap/tether/) are two examples of what you're looking for. Web-View is built for Go, but has bindings for several other languages.

[kodablah]

The Boscop one is just bindings for https://github.com/zserge/webview which is only MSHTML on Windows not Edge. The tether one appears Rust only which means I have to expose my own C FFI layer to use in other langs. I want them to combine and give me the best of both! :-)

[zserge]

Hey! Original Webview author here. I am aware of the issue of MSHTML vs Edge, and I would really love to support Edge. With the new cppwinrt included into Windows SDK it should be possible - it's just plain C++17 (and then we need a small C wrapper to make it compatible with Cgo). But so far I'm failing miserably to even build a minimal WPF app using cppwinrt. Still, the hope remains, and any help is highly appreciated.

Or maybe we should build a separate DLL for Edge and call it from the webview library? Not sure how that will work with the UWP packaging. Any expert knowledge is highly welcome and I'm open to the discussions.

I was also thinking about adding CEF bindings using dlopen, so that one could compile a binary, drop it into CEF "Release" directory and run. But I'm not sure whether it's a good idea. CEF is heavy. But it's the same on all platforms. I wonder what do people think about it?

[kodablah]

Oh for sure. I am watching https://github.com/zserge/webview/issues/85 like a hawk and have even tried to do some self-contained binaries w/ the new WinRT libs myself with limited luck (because of the UWP packaging). I personally won't use it from Go if I can't distribute a single binary.

I have used CEF and while I love the abstraction, it comes w/ baggage. I ship CEF along w/ an app (it's the browser I'm typing this from now) and just libcef.dll is 91MB, not counting some of the tiny ancillaries. I think you are on the exact right approach and even if you want a CEF, just make sure it's not the preferred option on any platform. I have heard that MS people are working towards a usable Edge shared lib elsewhere, we'll see.

[butz]

It's called Progressive Web Apps. Already supported in Chrome, coming (or released already) on Edge. Still waiting for Firefox and Safari to catch up.

[WorldMaker]

The major support for PWAs for Edge was released in this recent Windows 10 April Release.

That also includes Microsoft Store support for PWA apps.

Several applications in the Microsoft Store for Windows 10 have already launched or switched to PWAs (one of the most noticeable one was Twitter replaced their increasingly outdated Windows 8 application with a PWA as soon as the April Release happened).

The Android Store also supports PWAs directly in recent versions (the "Twitter Lite" application on Android is the same PWA that Windows users now get by default, and presumably will be the only first party Android Twitter client once usage of PWA-capable versions of Android rises).

Microsoft's Bing crawler is supposed to start adding "high quality" PWAs directly to the Microsoft Store as soon as it finds them on the web and minimally vets them (and will provide tools to PWA website owners to control/enhance their listings).

Google's search crawler team is also supposedly investigating lighting up automatic app ingestion into the Android and/or Chrome Stores.

[oceanswave]

Safari 11.3 shipped with PWA support including service workers. FFx 58 as well

[Willamin]

It's very early and certainly not production ready, but this is the idea behind Electrino (https://github.com/pojala/electrino)

[mattkol]

Thank you. True. Simpler is more appropriate.

[sebazzz]

I wonder why Electron doesn't use less processes or even only one process. Reliability for normal chat apps etc. is less important and I believe in practice one of the sub processes never crashes.

[kodablah]

Not an option with Chromium. There was once a barely supported single-process option, but I think they even removed that.

[mattkol]

So far there are CEF1 and CEF3 - https://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Ov... CEF1 is single process - no longer supported. CEF3 is multi-process - current.

CEF3 still allows single process, but it is only advisable for testing/debugging only. Multi process is recommended for optimal performance and likely some functions may not work well without it. My experience is for simpler apps, single process can still be used.

Chromely is fully configurable and allows single process usage. Please see configuration wiki page at : https://github.com/mattkol/Chromely/wiki/Configuration