Hacker News Reader

Comment by dangoor | Hacker News Reader

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...

View on HN

I 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.

Author 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).

SWT (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.

One 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

chrome app <- websockets -> go service

Reply on news.ycombinator.com