Fiber Update; WebEngine vs CEF

Fiber has seen some active development, and over the course of a long 3-day weekend full of hacking I’m glad to say that exactly 0 progress has been made! Of course that would be a bit of a fib, I’ve spent the weekend re-factoring all of the profiles code and organising the codebase structure.

I also spent a good chunk of my time reading Qt and KDE coding guidelines and documentation on how files and classes should be structured, and then I applied that information to Fiber. The result now is well commented code, and consistent naming conventions in-line with other Qt/KDE projects.

But re-factoring code isn’t what I’m really interested in talking about…

WebEngine vs CEF

When I started Fiber I worked under the assumption that WebEngine would be the engine for this browser; it’s an official Qt extension, being actively developed, and isn’t going anywhere. After Fiber kind of came into the light I had a comments and emails pointing me to CEF, the “Chromium Embedded Framework” as an alternative to WebEngine.

After doing research it’s severely divided my thoughts on what to use.

What is it?

CEF started as a Chromium-based project meant to create a stable API relative to the rapidly changing engine, something non-qt applications could use as easily and reliably as Qt applications do with WebView . While it started off as just an implementation CEF has a defined stable enough API that it turned into a sort of pseudo-standard. Servo, Mozillas new wonder engine is actually building itself to be a native CEF implementation, meaning that future Firefox will actually be a CEF-based browser.

CEF, despite being not so well-known, is actually used by some very high-profile companies which lends credence to the longevity of the project. Adobe, Valve, Blizzard, Amazon, and other big names have thrown their chips behind CEF. Valve in-particular bases their Steam client on the thing.

Pros and Cons


Not everything is rosy and bright in the world of CEF; there are always downsides. The first and biggest downside is the fact that CEF doesn’t have a Qt library. The Qt guys didn’t decide on this arbitrarily as they have a different goal for the WebEngine API. At minimum CEF means more complicated work than using an established Qt API.

CEF and having multiple engine options also means that we may see two entirely different sets of bugs coming in, depending on whether or not a person is running Fiber-Chromium or Fiber-Servo in the future. This doesn’t even include potential future CEF implementations; who knows what might show up in 5 years.

I would also like Fiber to be extremely portable, which makes CEF more of a concern; WebEngine currently supports mobile, but CEF will only have Android support ‘in the future’. Since Plasma Mobile includes a more malleable stack I have less doubts that Fiber will run fine on that, but I would like to see Fiber eventually run on Android.

Finally, CEF will add a lot of weight to the browser as an external dependency, to the tune of at least 40MB at minimum. This is more due to WebEngine being part of Qt and already being on the system – but CEF isn’t, and so the rendering engine is a separate binary to distribute. If a distro ever eyes Fiber as a default browser it means there’s over 40 extra reasons to consider a slimmer browser which makes use of more common libraries. Granted, just about every major browser is packing pretty big binaries anyway – but it’s still wasted space.


One thing that’s kind-of well-known is that WebEngine doesn’t have a particularly deep API (yet). For most applications this is fine as the utility is just used to display some content and hook a few things in so the app can talk to the page in an efficient manner. Fine for the use-case that Qt envisions. For a full-on browser though WebEngine lacks a lot of important interaction points, and though I Initially doubt Fiber will be able to make use of deeper integration in a meaningful way, as time goes on it’s a serious advantage to lose, especially since I don’t know the roadmap for WebEngine and what they plan to add.

WebEngine and WebView also have bad security reputations – I don’t know the specific issues, I just know those issues are prominent enough to see Fedora choose not to ship it. CEF doesn’t seem to have this perception as far as I know. That being said I’m not a guru-level C++ programmer so I’m not disillusioned to the fact that I’ll inject my own security shortcomings; though I won’t have the worry of breaking downstream applications in the quest to fix those issues.

There’s concern in the web development community of a WebKit/Blink monoculture. Outside of Gecko, there’s no longer any rendering engine variety for the Linux community. While I doubt Blink will ever “slack off”, the fact is Blink has undue weight over the web because of its sheer dominance. With more variety it means Blink has to keep in-line with the wider browser community rather than driving it. Gecko, Trident, Edge, and Servo all push Webkit/Blink harder in the same way many desktop environments push KDE to be better.

But the absolute biggest advantage in my opinion is the fact that CEF will offer Servo in the future as well as Blink. It means that we will be highly portable in our choice of rendering engines, able to swap out quickly. If we tightly integrate with Webengine it means Fiber won’t have mobility in the future, but through CEF if one of the engines gains a significant technical lead we can change the engine easily.

The Poll

We have three options for Fibers engine of choice, and I’d like the people who may ultimately use the browser to decide, as I’m really truly torn!

  1. Stick with WebEngine. It’s simple, easy, fast, supported. Fiber already has WebEngine running.
  2. Start with WebEngine and just get the browser up-and-running, later make the transition to CEF. It would be fast at first, but it will complicate things later on as we make the transition, especially if there’s several extension APIs connected with WebEngine.
  3. Write Fiber to use CEF natively. This will probably result in a more performant browser, and will allow deep integration; though it would still be slower to develop than just using WebEngine.

(Don’t see the poll? Click here!)

Finally, if you have comments, please post them below and elaborate on what drove your decision.

16 thoughts on “Fiber Update; WebEngine vs CEF

  1. CEF lacks behind Chromium as much as QtWebEngine does. Integrating new branches into the project is huge amount of work on both projects, and not easily done. CEF stable is currently at 41, QtWebEngine stable at 40, the next QtWebEngine will be at 44 or 45. The main delay for QtWebEngine is the feature freeze which is 3 months before release, so we have the latest Chromium minus 3 months plus security patches.


  2. It isn’t an easy decision. I wanted to go for QtWebEngine+Port to CEF later, but then I decided for CEF directly.
    CEF isn’t simple and has quite some pitfalls. For example CEF has it’s own event loop, just like Qt. That would have made it impossible to use CEF without nasty workarounds. It made my choice easy. Until I read further on the GeneralUsage page. It solved my problem. CEF has full support for this scenario and provides good documentation about it.

    So, why I decided to vote for CEF is:
    – There’s a lot of applications out there using CEF that aren’t webbrowsers, so it can’t be that hard to use it
    – There are simple experimental projects out there, integrating CEF into Qt without too much hassle
    – CEF seems to have great documentation
    – it has a C++ API and uses CMake
    – I’ve seen example code (using Qt, windows only though) loading flash with <10 lines of code
    – It has a solid architecture that seems to support our use case, including all of the KDE/Qt integration we want to do
    – it's future proof – CEF seems to have a lot more manpower behind it than QtWebEngine – to be honest I do not ultimately trust QtWebEngine to still be here in 5 years
    – finally, I think we'll want the deep integration CEF provides


  3. I’d definately go with CEF as it doesn’t pose the following problems as stated already by other commenters:
    *) doesn’t lack behind x-Chrome versions as QtWebengine does (security issues come to mind)
    *) this could make it easier to to support existing chrome extensions in addition to custom fiber extensions
    *) there are already enough QtWebkit browsers out there without a real USP
    *) this could end up as a KDE native version of Chrome/Firefox which would just be great 🙂

    Hope I could help 🙂


  4. CEF please, we don’t need just another WebEngine browser.
    It’s harder I know, but the browser is the application which users run for 90% of their time and so we need a first class engine. I’m not going to use another Rekonq, I’ll stick to Chromium if you don’t use CEF.


  5. I don’t know about technical questions, but as an user (KDE user), I’ve always tried every new Qt browser, and I’ve always switched back to Firefox (then) or Chrome (now). IMHO, it doesn’t make sense all of this work if it’s not intended to make a web browser for everyday use, a browser for everything. I asume using CEF natively will bring it more compatibility and less craches (with konqueror, rekonq, qupzilla, etc. in mind), so that’s my choice.


  6. The problem with WebEngine and Linux distros is how Chromium bundles so many libraries, which could potentially be trouble when security updates are needed, but this is the same problem for CEF, and the Chromium browser itself for that matter. Fedora do not even package the Chromium browser, and Debian had to make an except to do so.


  7. I’d say to choose the choice that will bring you fast to the (90%) finished product. Then, if you have the time and CEF proves to be a good choice (I’m really intrigued by the Servo-in-kde idea), switch to it.

    BTW, Fedora is not the only distro that does not want to ship the WebEngine, Debian Qt packagers decided the same for too many deps and build problems (can’t find the relevant mail atm).

    Liked by 1 person

  8. I voted for CEF for a couple of reasons:

    1. It’s differentiator for Fiber. There are browsers like Otter and Qupzilla that use/ will use Qtwebengine, so choosing CEF is a plus (of course this reduces the scope for collaboration, so there’s that to consider).

    2. Servo, as you said. After all konqueror did support two engines, so you’d be following in the grand KDE tradition.

    I have a question, that may have some bearing on the decision: how easy is it to follow upstream using CEF vs QtWebengine? Independently of the problems with packaging, the Qt 5.5 Webengine is based on Chromium 40 (I think), so it’s already 4 versions behind the upstream. This may be a security problem. Can one just plop a new version of chromium in CEF and be good to go?

    And seriously, thanks for all the effort Ken.


    1. Considering that the Servo team’s been testing their CEF implementation by LD_PRELOAD’ing it into existing CEF-based stuff that doesn’t know Servo from Adam, I’d say being able to sub out versions of Chromium is a pretty safe bet 😛


  9. I think you misconstrue at least one thing regarding Servo – in particular, there are no plans at this time to *replace* Gecko with Servo in Firefox. Far more likely is that a new browser, without the XUL baggage, would be built around Servo/CEF – as the XUL GUI is tightly wedded to Gecko, and there’s not a huge amount of interest in _perpetuating_ XUL into a nice, clean new engine.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s