Rise, WebKit, Rise!
I was originally going name this “QtWebKit Bridge and QWebChannel Are Not the Same.” Then it changed to “Please, Please, Please Bring Back QtWebKit.” It turns out I don’t have to write that either because QtWebKit is making a comeback, and thank goodness for that!
Why is this good new? Because when Qt was owned by Digia, they would have us believe that QWebEngine is a superior product to QtWebKit. This is true, but is also misleading because it leaves out a lot of truth. The complete story is more like this: QWebEngine is a superior technology in some cases under which your application is not likely to fall. In his blog post entitled QtWebKit: I’m Back!, Konstantin Tokarev provides a deep-dive into some advantages to continuing to use QtWebKit. I’d like to add a point or two to that list.
QWebChannel != QtWebKit Bridge
The move to QWebChannel from the QtWebKit Bridge is a major sore point for me, and the main driver behind my refusal to move to QWebEngine. Deal breaker number one is the requirement of the client side to load qwebchannel.js. This is not acceptable as I will not always have control over the client’s content which I am exposing my API to. I once saw it referred to as a “wart” and I agree completely. Think about how silly/hacky I sound when I have to tell all of my front-end developers, “Hey, make sure you include this weird-looking wart with your fancy-schmany Angular application to access new shiny on my hardware.” Not happening.
A quick read of the history of QWebChannel tells me that this implementation was the best they could come up with after the poor design choice to base Qt Quick 2 on the Webkit2 API, a choice that I’m sure was driven by the industry’s fetish for async-all-the-things and mobile mania. When asked in a comment on the QtWebKit developer blog why Digia abandoned QtWebKit, Mr. Tokarev responded, “It was a combination of executive meddling and failure to find efficient development process.” That sounds closer to the truth.
Personally, I feel QWebEngine has the stink of corporate strategy tax all over it. Don’t get me wrong; I’m not saying QWebChannel is bad (remember, there is some truth to what they’re saying). I’m saying it is no replacement for the QtWebkit Bridge.
The other significant reason I won’t use QWebEngine is the trust factor. This is more of a personal/religious reason, I admit, yet I argue still a valid one that I’m not alone on. I trust the WebKit project (despite Apple meddling). It has been open-source from the beginning. The Blink fork of WebKit for the Chromium project is run by Google. It’s difficult to put “Google” and “trust” in the same sentence. The Blink fork is inevitably going to follow a design path that suits Google’s proprietary ambitions. It will help me do what Google envisions, not help Google’s software do what I envision. I’ve even actually had a few customers complain that our embedded devices were phoning home to Google on their networks, thus helping to fuel our push to abandon Chromium. Basing QWebEngine on Chromium defeats the purpose of us using Qt technology altogether.
I’m biased, of course. This is my personal blog and I’m no journalist. I’ve liked WebKit since the day I discovered it was a fork of KHTML (gee, I’m a KDE fanboy, more bias). But with a little digging, it’s easy to see why picking up development on QtWebKit is a good thing. Help out! Fork away and contribute some new code or fixes! Spread the word! Jump on irc.freenode.net and join #qtwebkit. Mr. Tokarev (who goes by annulen on git and irc) is super easy to talk to. Help QtWebKit become a part of the future (pretty please)!