[mwcampbell]

This trend of a hundred desktop applications all bundling their own copy of Chromium really bothers me. I know the situation sucks on Windows, but on Mac, why not use the system WebKit framework? I know the decision was made upstream of this project, in Electron, but this project will increase the proliferation of app-private copies of Chromium.

For the past year or so, when thinking about software bloat, I always come back to this sad bit of dialog from the novel _Off to Be the Wizard_:

Phillip (time traveler from 1984): What on earth can a person do with 4 gigabytes of RAM?

Martin (from 2012): Upgrade it immediately.

Do we really want to make that situation even worse?

[koko775]

> why not use the system WebKit framework?

Same reason people often like to statically link. The system is guaranteed to be a moving target sooner or later, so new bugs may appear or disappear depending on a user-controlled action that's tedious to track if it's possible at all.

Bundled code, on the other hand, is a fixed, known quality against which bugs can be tested, or source inspected, or otherwise debugged in a way system libraries typically cannot.

[mschuster91]

> I know the situation sucks on Windows,

It sucks on Linux even more. On Windows, at least everyone (including the build tools) is used to shipping dependencies, on Linux not so much.

You have all sorts of crazy dependencies on (system) libraries (not to mention libc versions), and you probably don't want to fool around with dozens of package managers (apt-get, rpm, whatever Gentoo is using, hand-rolled distros), and you pretty much don't want to store stuff in /usr/local because you might overwrite stuff already present there.

> but on Mac, why not use the system WebKit framework?

Because Chrome is far faster to pick up new stuff than Safari. Also, most people these days prefix and test only for Chrome, which disqualifies embedding a Firefox runtime.

[jiahaog]

I do agree with you on that, and there should be some form of Chromium that can be shared across applications to reduce the bloat of such packaged apps. Perhaps this is an issue with the architecture of Electron itself, which requires all such apps to contain their own version of Chromium?

I wanted easy cross platform compatibility with minimal code, and Electron seemed like a good choice across for apps across Windows, OSX and Linux.

[mwcampbell]

On OS X, a little Cocoa application in Objective-C using the system WebKit framework would probably do the trick.

On Linux, a little GTK application in C using WebKitGTK would probably work.

On Windows... I don't know. I know from firsthand that embedding the IE engine via the WebBrowser ActiveX control really sucks. I'm going to see if the WebKit WinCairo port is any good these days.

If we must use CHromium, then the Chromium Embedded Framework is worth a look. It's a DLL, so in principle, it can be shared between applications. You'd still need some platform-specific code to create the window containing CEF, though.

[monkmartinez]

All these "little native applications" require lots of work. If I want to share these "little applications" with people that do not share my OS, I am forced to make at least 2 different versions of the "little application"... then maintain them.

Good enough, is good enough. Yes, the web is not as performant as native... the question becomes; is it good enough? The bonus in wrapping Chrome is that I don't have to dive into 3 or more system level API's to get a "little application" up and running.