Collaborator-8-3-CTA-banner

Forked! Where WebKit Goes From Here

webkit-fork-in-road

WebKit long has been the dominant open source Web-rendering engine, but with Google’s Blink fork, its future has turned murky.

For years, WebKit was easily the most popular Web-browser rendering engine. It was the foundation for no fewer than three of the most popular Web browsers: Chrome, Safari, and Opera. Then, Google forked WebKit with Blink, and now it’s not at all clear where WebKit is headed.

At LinuxCon in New Orleans, Juan Sanchez gave his take on what’s going on with these open source projects. Sanchez is a member of both the WebKit and Blink teams and co-founder of Igalia, a Spanish open source consulting company that specializes in Web browser software.

Sanchez opened with WebKit’s history. It started as an Apple fork of KDE’s KHTML and KJS for Safari in 2001. The project went open source in 2005, after which it quickly became popular in other Web browsers and for other Web user-interface based programs. WebKit was always meant to be a Web browser engine (a set of core classes that can display Web content in a window), as is Blink; they are not browsers in and of themselves.

In April 2010, Apple introduced WebKit2 to support a split process model. WebKit2 was not an updated version of WebKit. Instead, WebKit2 added three different processes: a UI process, the WebView widget, and an application UI.

Chromium, Google’s open source Web browser that backs its Chrome Web browser, has its own multi-process architecture. This is quite different from WebKit2′s method. In fact, they were incompatible.

Most browsers stuck with the far simpler-to-use WebKit. At this time, there are only two major WebKit2 desktop browsers: Apple’s Safari and KDE’s Konqueror. Nevertheless, Sanchez said, WebKit was on its way to being the maintenance platform and future work would all be on WebKit2.

The ground was laid for a WebKit fork.

Three years after WebKit2′s introduction, in April 2013, Adam Barth, a Google Software Engineer, announced that because of the difficulties in supporting multiple architectures for both the WebKit and Chromium projects, the collective pace of innovation had slowed down.

Thus, Google decided to introduce Blink.

Webkit_LogoAccording to Sanchez, Google’s move came as a shock to the WebKit development community. It shouldn’t have.

Chrome’s architecture didn’t fit well with WebKit2′s structure, Sanchez explained. In addition, Google actually had more developers working on WebKit than Apple did (albeit the numbers of patches that both companies contributed to the program was about the same). Despite the coding parity, Apple had been seizing more control of WebKit. Apple recently introduced the new top-level role of “owner,” and only owners could commit changes to WebKit2.

And there’s always the element of the “browser wars,” including everything from performance issues to personal preference. It can’t be ignored that software developers, such as John Siracusa, have found that “Google’s Chrome has proven to be far more stable and resilient in the face of misbehaving web pages than Apple’s WebKit2-based Safari.” Others suggested that “WebKit is long in the tooth” and called it “a product of PC thinking.”

So where does WebKit go from here? Well, so far, Blink is winning the hearts and minds of developers, Sanchez claimed. Opera immediately followed Google to Blink and Qt just announced that it too, is moving to Blink because of a lack of cross-platform support. Other WebKit programmers are still trying to make up their minds, Sanchez said.

What’s that mean to the community process? It is safe to say that Google’s leaving will slow down WebKit development. Sanchez also fears since Apple is the largest remaining stakeholder, it will become much harder for other developers to have a say in WebKit2 development.

It’s not clear how “open” Google will be to external changes to Blink. Still, non-Google developers’ patches are beginning to show up in the Blink tree.

During the presentation, Sanchez said that the WebKit2 source code is, just considering C++, Objective-C, and C files alone, more than 1.6-million lines of code.

Worse, Sanchez confessed, that code is quite complex and there is “no single centralized place to follow all WebKit/WebKit2 development process. There are no core blogs, mailing lists, IRC, etc.”

Wow.

With this lack of organization, it’s a miracle that WebKit has been as successful as it has been. Now that Google has Blink as a WebKit-based alternative, which has a bug tracker and mailing lists, I anticipate that, outside of Apple, Blink will quickly become the dominant open source Web-rendering engine.

Technically speaking, the two rendering engines are already beginning to diverge. For now, code is still portable, but within a year Sanchez is sure that will not be the case. Despite that problem-in-the-making, Sanchez thinks it is a positive development that open source Web developers have two engines from which to choose.

Still, Sanchez, who’s near the heart of both projects, thinks that “It remains to be seen how the situation in terms of open source dynamics and project health and quality will be in a few months.” And his company, which is a top-five contributor to both projects, plans to continue to support both for the time being.

Personally, I left the speech much more certain that Blink is the future.

See also:

Collaborator-8-3-CTA-article

subscribe-3

Comments

  1. Actually, I think Opera joined Blink after it forked from WebKit. Before this they had their own proprietary web engine.

    • IIRC – Opera dropped their own engine for webkit first, then moved to blink when the fork happened

      • Yes, I think you are right, Opera switched a month or two before the great fork. Not sure if it made it into production, but hey, not important :)

Speak Your Mind

*