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.
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!
- Stick with WebEngine. It’s simple, easy, fast, supported. Fiber already has WebEngine running.
- 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.
- 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.
Finally, if you have comments, please post them below and elaborate on what drove your decision.