[Development] Qt WebEngine

[Konstantin Tokarev]

12.09.2013, 16:04, "Knoll Lars" <Lars.Knoll at digia.com>:
> Hi,
>
> As many of you know, we've been doing some research on a (chromium based)
> new web engine for Qt during spring and summer. I wanted to let you know
> that we've now come to the conclusion that we want to continue these
> efforts in the future.
>
> Please check
> http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/ for
> all the details.

IMHO, this is a really bad decision. WebKit is a meritocracy-driven community project with many large and small contributors, while Chromium seems to be driven solely by Google employees. If Google needs to do some ground-breaking changes in the engine, they will do it, and don't hope they to care about 3rd party products being broken.

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

To run QtWebKit on embedded platform with unsupported native graphics API, it's enough to write gfxdriver for Qt 4, or QPA plugin for Qt 5. Basically, if Qt works, QtWebKit works too. To run Chromium I will also need to port Skia, and maybe other things. IIRC, it does not even support DirectFB out of the box.

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

This implies larger size of binaries for embedded users because of massive duplication between Qt and Chromium cross-platfrom layers.

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

Does Chromium provide any C++ API warranties? You may end up overhaul your fancy integration layer each time you update.

>We are seeing that Chromium is being developed with very strict control on quality.

WebKit also has solid testing infrastructure.

>Finally, we are seeing that Chromium is currently by far the most dynamic and fastest moving browser available

WebKit is moving slower because it has to care about all its ports. All significant architecture changes are discussed by community. Chromium is fast because they don't care about anyone else.

>One of the fundamentals of Chromium is that all rendering of Web content happens in a different process for security and stability reasons.

WebKit 2 multiprocessing model is much better designed and provides stable API. Also, single process mode of Chromium in unofficial and often breaks (and it's usually worthless to be multi-process on single-core embedded CPU).


I hope there will be some folks to keep maintaining Qt port in WebKit upstream. Otherwise, NIX port looks like a good alternative, though it requires OpenGL-capable hardware.

-- 
Regards,
Konstantin