3 ms·

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 re

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.

mattkol 8y ago
Thank you. True. Simpler is more appropriate.
sebazzz 8y ago
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 8y ago
  Not an option with Chromium. There was once a barely supported single-process option, but I think they even removed that.
  - mattkol 8y ago
    So far there are CEF1 and CEF3 - https://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Overview 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 https://github.com/mattkol/Chromely/wiki/Configuration
jug 8y ago
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)?
- xobs 8y ago
  Web-View (https://github.com/Boscop/web-view https://github.com/Boscop/web-view) and Tether (https://github.com/quadrupleslap/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 8y ago
    The Boscop one is just bindings for https://github.com/zserge/webview 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 8y ago
      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?

mattkol 8y ago

Thank you. True. Simpler is more appropriate.

sebazzz 8y ago

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 8y ago
Not an option with Chromium. There was once a barely supported single-process option, but I think they even removed that.
- mattkol 8y ago
  So far there are CEF1 and CEF3 - https://en.wikipedia.org/wiki/Chromium_Embedded_Framework#Overview 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 https://github.com/mattkol/Chromely/wiki/Configuration

jug 8y ago

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

xobs 8y ago
Web-View (https://github.com/Boscop/web-view https://github.com/Boscop/web-view) and Tether (https://github.com/quadrupleslap/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 8y ago
  The Boscop one is just bindings for https://github.com/zserge/webview 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 8y ago
    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?