I’ve switched browsers the last couple of days because I wanted to test Webkit as an alternative to KHTML. Although I liked WebKit I’ve now returned to KHTML with Firefox as a backup for the time being.
I first wanted to test Webkit under Konqueror using the WebKitPart that’s available, it was to unstable however and I hope the GSoC-project around it will help with it’s development. To test QtWebKit I switched browsers to Arora for a few days, which was an interesting experience to say the least.
Speed
If WebKit deserves special credit it’s because of it’s speed. It’s lightning fast, even in the beginning when I didn’t have any cache in Arora. Small pages are about on par, although it feels faster in WebKit. When pages get larger and more dynamic KHTML really starts to jog slowly. WebKit surely wins in the speed department, forgetting the little trouble it has with Guildlaunch.
Compatibility
Both QtWebKit and KHTML have compatibillity problems but the nature of them varies. KHTML has a lot of trouble with web 2.0, it simply can’t load GMail at all for example whilst WebKit has no problem at all. WebKit seems to render all the populair web 2.0-sites without any trouble and it’s a lot faster at it then Firefox.
A clear win for WebKit? No… WebKit does well on populair web 2.0-sites but it seems to fail on quite simple things. For example, I can’t get to the admin panel of my blog while it works perfectly in KHTML, it simply doesn’t log in with Arora. WebKit also tends to randomly not load the CSS-stylesheet of certain sites and won’t load it till I clear the cache, although it might be an Arora-problem but I remember something similar with WebKitPart when it was still working.
I believe WebKit is more compatible in the populair range and KHTML currently is overal. so I can’t point out a clear winner.
Features
I won’t go into detail about the features between Arora and Konqueror, Arora is really a simple browser that still has to evolve whilst Konqueror is a enormous beast. To compare QtWebKit with KHTML you should only look at the browsing-widget as it can be embedded in other applications.
The number of features in QtWebKit is really astonishing: you can cut, copy, paste, change text-typing direction and reload the page. That’s all there is, really. KHTML does much better and gives me all the options I would expect in KDE.
KHTML integrates all native KDE-widgets and that’s a plus for the options get by doing that. I can understand that WebKit uses fake widgets for potability but I would at least have expected some things to be integrated. KHTML also seems to do much nicer with displaying images, the quality of resized images is much better in KHTML.
Conclusion, what should be the future?
I don’t thing we should keep KHTML as the main engine for Konqueror, of course it has it’s advantages but WebKit has more potential to be the most speedy and compatible engine and that’s what matters in a browser for users. QtWebKit should be polished and made the primary engine for Konqueror. KHTML shouldn’t go away though, it’s important to keep it for other applications that need an embedded HTML-engine. KHTML’s native widgets is a real plus for embedding in other applications as it keeps the consistent look and feel with the rest of KDE.
For the time being I’ll stick with KHTML at least till WebKitPart is stable, as I can’t live without Konqueror’s advanced features. 
It’s actually quite awkward at the moment.
Nevertheless, well done to both KHTML and WebKit. 
)