4 ms·
A framework like this would be awesome if it used the browser engine on the system rather than CEF, or allowed that as an option. You'd be able to get Mac progr
by dangoor 10y ago
A framework like this would be awesome if it used the browser engine on the system rather than CEF, or allowed that as an option. You'd be able to get Mac programs that are just a couple of MB then, rather than having each of these programs weigh 50-60MB. The runtime characteristics might not be much better, but at least every binary is a bit smaller.
Of course, this is a minor complaint on modern systems...
- falcolas 10y agoI believe the reason people don't want to use the OS-native web interface is because of the need to support multiple frontends. It's easier to keep your presentation layer consistent across OS when you have a shared rendering platform.
- mmgutz 10y agoOne can run Chrome in app mode and it will run a Chrome app from a directory. A proof of concept is here https://github.com/mgutz/chromeapp https://github.com/mgutz/chromeapp chrome app <- websockets -> go service
- etwigg 10y agoSWT (the eclipse widget toolkit) takes this approach. It's very difficult to maintain API compatibility with the myriad browser versions out there, not to mention having the content in those browser windows display reliably. The real killer-feature of Electron et. al. is only having one browser version to test against. I think embedding CEF is definitely the right call.
- alexflint 10y agoAuthor here. Yes this is a significant price to pay, but being able to test once and be sure that your users' experience will match your testing is worth a lot. It should be possible to have an updater that avoids downloading the main chromium dylib on most updates. This is actually not based on CEF, btw, but on libchromiumcontent (the Electron alternative to CEF).