I’ve just read on Techcrunch that Flock was going to switch from Firefox to Chrome. This is not completely news to me because at the time I was still at Flock, one colleague (Chris Campbell) was doing experiments with Chrome to see the feasibility of the switch. I don’t know what’s going on inside Flock now, so I don’t know if they’re still just playing with Chromium or seriously planning a switch.
The supposed switch revived a recurring discussion about how Gecko is a pain in the arse to embed, and how it’s a breeze to embed WebKit. Additionally WebKit is young, shiny and buzzy while Gecko is old and supposedly tired.
It is true that Gecko is much harder to embed that WebKit. It is also true that Mozilla is not spending a lot of time helping people who want to embed Gecko (their priority is Firefox), while embedding is the main purpose of WebKit. The natural consequence is that I don’t know any recent project choosing Gecko as their rendering engine.
But that’s not the point. Flock is not embedding a rendering engine, they are taking a full blown browser - currently Firefox - and tweaking it. Flock is not a browser based on Gecko, it is a browser based on Firefox. That explains a lot of similarities between the product, and that also explains why most Firefox extensions work in Flock.
That means that if Flock switches to Chrome (actually Chromium, the Open Source version of Google Chrome), it doesn’t matter how easy it is embed WebKit: what matters is how easy it is to hack Chromium. And it doesn’t matter how responsive and nice the WebKit community is: what really matters is how Google will deal with external contributors and patches from external contributors. And as Chromium is young, this is still unsure.
But even if Chromium appears to be open to contributors, how they would react to a company building an other browser based off Chromium is pretty unknown. It’s just like with Mozilla: they release their code under an Open Source license so they explicitly allow that kind of derivative work and can’t prevent it to happen. But whether they will see Flock with a better eye than Mozilla did is a different question.
I can really see only one good reason for Flock to switch to Chrome: the “process-per-tag” system.
Flock have always suffered of Mozilla’s single thread, single process logic. For example, when you fetch the Facebook friends list of a rockstar, you have to merge lists of thousands of friends then refresh the UI to reflect that. This operation happening in the main thread (the only thread) it will literally block your browser. To workaround that, Yosh wrote a simple Scheduler that sets timer to yield to the UI once in a while. It’s really a hacky way to get threads-like things, and since we didn’t apply it everywhere there were still code that were freezing the browser. With Chromium, Flock’s sidebars or topbars would run in separate process and be less disruptive for usual browsing.
It’s hard for me to see how that single reason would outweigh the cost of switch for the team and for the users. This is going to be a completely different product with new bugs, features disappearing and alienated users. I do not know Flock’s current strategy but I can only assume they are seeing more benefits to the switch that I can’t see.
That kind of controversy about what Flock should use (or will use) as a “host browser” is pretty irrelevant for extensions companies. Foxmarks, CoolIris and the company I currently work for are all examples of companies who provide a rich browser feature while letting the user choose his browser.
At its early days, Flock decided to be a browser instead of a set of extensions. This choice makes sense for Flock’s general strategy, but today I can’t help but think that if Flock was an extension company, it could just have released a Chrome version along with versions for other browsers.
Send support requests to support at caffeinelab dot net.
Other emails should go to me at caffeinelab dot net. I can speak English, French and Japanese.