QtWebKit: I'm back!

Hello world!

 

Five years have passed since the last entry in this blog, and almost 3 years since infamous "Changes in QtWebKit development" thread at webkit.org. Fortunately, we've made quite different kind of change in QtWebKit development lately, and it is much more exciting.

QtWebKit is back again!

If you were following QtWebKit development after 2013, you know that actually development have never stopped: each release was getting a bunch of bugfixes and even brand new features. However, WebKit engine itself has not been updated since Qt 5.2 release. That's why it didn't support recent changes in Web standards that happened after 2013, including: new JavaScript language standard ES2015 (also known as ES6), as well as improvements in DOM API and CSS.

However, things have changed in 2016, and now we have revived QtWebKit! Core engine code was updated to it's actual state, and as a result we (and you!) can use all improvements made by WebKit community during these 3 years without any changes in code of existing Qt applications!



You may be wondering, why anyone would like to use QtWebKit in 2016, when shiny new QtWebEngine is available? There is a number of reasons:

• When used in Qt application, QtWebKit has smaller footprint because it shares a lot of code with Qt. For example, it uses the same code paths for drawing and networking that your regular Qt code uses. This is especially important for embedded systems, where both storage space and memory are scarce resources. It's possible to go further and cut away features which are not crucial for your application, using flexible configuration system of WebKit.
• On Linux QtWebKit uses GStreamer as a default media player backend. This means that application users will be able to use patent encumbered codecs (if this is legal in their areas) without getting you (as application developer or distributor) into legal troubles.
• Lots of existing open source applications depend on QtWebKit, but without security updates their users are left open to vulnerabilities. The are only two ways to work around this problem: port applications away from QtWebKit (which is often a hard task because QtWebKit allows much deeper integration with application code than alternative solutions), or update QtWebKit itself, which makes these large porting work unnecessary.
• QtWebKit is more portable than Chromium: it can run on any CPU architecture supported by Qt and on virtually any Unixish OS (as well as Windows and Mac). The only requirement is a C++11 compiler.
• Non-interactive user agents like PhantomJS or wkhtmltopdf don't gain any benefits from multi-process architecture, so using single-process WebKit 1 API allows them to have less resource footprint and simpler flow of execution.

Q: I've heard that WebKit engine is not relevant anymore, since the crowd is working on Blink these days!

A: This is not true. Despite of the Google departure, WebKit remains on of the leading browser engines, and is progressing at a fast pace. If you don't believe, read on! Also you may want to read release announcements of Safari Technology Preview and WebKitGTK, which higlight other WebKit features under development.

Now let's see what can we do with QtWebkit in 2016!

JavaScript engine improvements and ES2015 status

 

Most of features are supported now (QtWebKit 5.6 has 10% rating). Note that WebKit is the first web engine providing proper tail calls, which means you can enjoy functional programming without unnecessary stack growth in tail recursion!

WebKit gained new tier of JavaScript JIT compilation, called FTL. First implementation was based on LLVM compiler infrastructure, but now we are shipping B3 compiler which is more lightweight, does not pull in additional dependencies, and also compiles faster. FTL usually gets activated for computationally-intensive JS code, and is especially useful for running native code compiled to ASM.js.

Code produced by JavaScript JIT now uses normal C stack, reducing overall memory usage and fragmentation.

JIT compiler now uses background threads, so compilation does not block execution of other code.

New (and old) CSS properties

Web standards evolve rapidly, and more and more CSS properties find their way into specification. Most of them have already been available for a long time, but used -webkit vendor prefix as they were non-standard extensions at a time of their introduction, and now they (finally!) have formal description which all vendor are obliged to follow (though sometimes standardization process changes behavior of old properties). Standardized properties are available without vendor prefixes, and web page authors start actively using these new spelling.

Unfortunately, sometimes they break compatiblity with old browsers, which implement prefixed properties, with disastrous consequences. Here are screenshots of site that uses unprefixed flexbox properties, defined in CSS3:

QtWebKit 5.6

QtWebKit TP3

CSS Selector JIT

Besides JavaScriptCore, WebKit now features yet another JIT compiler. Its aim is to speed up application of CSS style sheet to elements of page DOM, so called style resolution. Average performance gain is about 2x, however for complex selector and/or pages with lots of DOM nodes gain may be substantially larger.

Selector JIT also makes querySelector() and querySelectorAll() faster, but speed up factor may differ.

-webkit-initial-letter

This is new CSS property, allowing page author to create "drop cap" effect without much hassle. In order to make this effect work correctly with calligraphic fonts, Qt 5.8 (not yet released) is required.

Other improvements

• Responsive images support (<picture> element, srcset and sizes attributes)
• ellipse() method in Canvas API
• CSS selectors ::read-write and ::read-only
• HTML <template> element 
• APNG images

We also support following web features with experimental status and only for GStreamer media player backend:

• Media Source Extensions
• WebAudio

The path ahead

Unfortunately, porting Qt-specific code to the new WebKit is not always easy, and we had to disable certain features until all code behind them is ported properly. So far, following prominent features are not yet working:

• QML API
• WebGL and CSS 3D transforms
• Accelerated compositing
• Private browsing

However, don't be discouraged! Work is in progress and we hope to get these feature available soon. But we are short on manpower so we cannot work on many things in parallel. If you want to get your favorite feature ready sooner rather than later, please join our project. We have a lot of work to do, most items don't require any prior knowledge of WebKit, and some even don't require you to know C++ (yes, there is work for those of you who know only HTML + CSS + basic JavaScript, or only Python). Another way to help us is to report bugs you have found, or help to track down known issues.

You can follow development of QtWebKit at GitHub repository; however if you want to obtain get bleeding edge sources, use another repository - the latter one is much smaller than original, but still contains all files required to build QtWebKit. See our wiki for build instruction and additional information about the project.

P.S.

Today is 10 years since the first chunk of QtWebKit code have been merged into WebKit repository. See https://bugs.webkit.org/show_bug.cgi?id=10466 for more details.

Update

Technology Preview 3 is now available: release notes, tarball. Binaries for Windows and macOS will be uploaded a bit later.

Update 2

Technology Preview 5 is available now. It includes binaries for Windows (MSVC, MinGW), macOS, and Linux, that are fully compatible with official Qt 5.8.0 SDK.