A lot has happened with Web technologies in general since we introduced the first version of Qt WebKit in 2007. From having a couple of percent market share, the WebKit open source project nowadays has became the most widely used browser engine in the world. While the Qt port of WebKit was pretty much the first non-Apple port of WebKit, many other projects and companies joined the project over the years to follow.

The Chromium project took an especially big role in the project and became over time the biggest contributor to WebKit (followed by Apple and with Qt on the third place). The cooperation between different companies on one open source project was, however, never without difficulties, and this spring Google decided to leave the WebKit project in favor of their own fork of WebKit, Blink.

Since then, Blink, which really is a very integrated part of Chromium, and WebKit have been going separate ways, and the two code bases have been rapidly diverging. Because of this, the Digia Qt R&D WebKit team decided to have a closer look at both Chromium and WebKit to decide how we could offer the best possible Web engine for Qt in the future.

After spending some time researching and looking at both alternatives, we have now come to the conclusion, that we will base our future Web engine on Chromium. The Qt WebEngine. There are many reasons that lead to this decision:

• Chromium has a cross-platform focus, with the browser being available on all major desktop platforms and Android. The same is no longer true of WebKit, and we would have had to support all the OS'es on our own in that project.
• There are many things that are available out-of-the box from Chromium, which would require a lot of work for us to support ourselves in WebKit. One example, is the whole platform/OS adaptation that we can simply re-use. Multimedia and new HTML5 features such as WebRTC are working out-of the-box and don't require any Qt-specific code.
• As using Chromium simplifies handling the OS integration, this allows us to spend additional time to focus on the upper layers to provide a great and easy-to-use API and a seamless integration into Qt as possible.
• We are seeing that Chromium is being developed with very strict control on quality. This simplifies our testing efforts and will allow us to provide a more stable and higher quality Web engine.
• Chromium will allow us to do a better and more performant integration with both widgets and the Qt Quick scene graph than we would be able to do with WebKit

Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available. Basing our next-generation Web engine on Chromium is a strategic and long-term decision. We strongly believe that the above facts will lead to a much better Web engine for Qt than what we can offer with Qt WebKit right now. We also believe that the combination of the best-in-class browser engine with Qt as a native framework gives an incredibly strong offering especially for the creation of embedded devices that require a Web browser in addition to best-in-class UI performance.

One of the fundamentals of Chromium is that all rendering of Web content happens in a different process for security and stability reasons. This does, however, make it impossible to provide certain aspects of our current Qt WebKit API with Chromium. One notable part is probably the QWebElement API. We will also have to change how QObject embedding is being done, since all communication between the QObject and the web page will have to happen asynchronously.

What does all of this mean for users of Qt WebKit?
First of all, there's nothing to be afraid of. For many use cases, where Web content is being embedded into applications, Qt WebKit works fine right now, and will continue to do so in the years to come. After the release of Qt 5.2, we will focus most of our new development efforts on the new Qt Web Engine. So, if you want to have all the lastest and greatest HTML5 features available for your application or device, you should consider moving over to Qt WebEngine once we have a release that covers the API features you require.

We will do our best to make moving over from Qt WebKit to the new Qt WebEngine as easy and seamless as possible. For the Qt Quick WebView element, we can most likely provide a close to 100% compatible API. For people using the basic QWebView API, we also have good news. Most of that API is available in an almost source-compatible fashion in the new Qt WebEngine. If you use the QObject bridge or the QWebElement API, we recommend you wait a bit longer with moving, as a replacement API for those will most likely not be part of the first version of Qt WebEngine.

While we no longer will do any feature development in Qt WebKit, the existing version will continue to be available. Digia will continue to support Qt WebKit for Qt Enterprise commercial license holders as defined in the license agreement, and can also offer extended lifetime support.

Work is now ongoing to provide you with a Technology Preview of the new Qt WebEngine as fast as possible. Our goal is to have that available together with the Qt 5.2 release this autumn. The first fully supported release will then, most likely, come as part of Qt 5.3 next spring. For the first version, we are planning to support the new Qt WebEngine module on Windows, Mac OS X, Linux and embedded Linux.

For more information on the Qt WebEngine have a look at the Qt Project wiki. There you can also find more detailed information about how to build the Web engine yourself, how to port existing code and what our future plans for the module are.

While this is a rather large change for Qt, I strongly believe this will give us a much better and more competitive Web platform in the years to come.

The best way to find out what is going on with Qt WebEngine and our future direction is to join us at Qt Developer Days where our lead developers on the project will talk about the latest developments. Make sure to register to Qt Developer Days at www.qtdeveloperdays.com.