QtWebKit vs. KHTML - again...
Posted by George Wright Tue, 30 Jun 2009 23:00:00 GMT
After reading Will’s latest post, I feel I have to chip in.
I am a long time user and huge fan of KHTML. I still use KDE 3, and my day-to-day browser is still Konqueror from KDE 3, using an old version of KHTML. For 99% of websites that I visit, this is sufficient. Notable exceptions are YouTube and Facebook, both of which are very AJAX-heavy, and I keep a separate Firefox (well, Iceweasel) window open for them on a permanent basis.
Why do I keep both browser windows open? Well, for general Googling, random surfing, wikipedia, etc, I love the sheer speed of Konqueror, and its configurable web shortcuts (such as gg:, wp: etc) are insanely useful. Scrolling is blisteringly fast on just about any webpage and everything happens instantly. This is one of the major reasons why I don’t use KDE 4 yet - Konqueror 4 just doesn’t seem that fast anymore. I realise this is all very subjective, but things don’t quite feel so fast anymore.
However, this is a very suboptimal solution. As Will says, KDE needs a good web browser that can integrate with the rest of the desktop, and people shouldn’t need to resort to alternatives like Gecko. Personally, I hate Gecko. It’s got a massive memory footprint and it’s not as fast as I would like.
I’m not going to be flavour of the month for suggesting this (am I ever?), but I’d say the best thing to do at this point is for the developers to forget about KHTML, and start working upstream on WebKit, as well as work on integrating WebKit with Konqueror. Yes, there are probably some very good reasons as to why this is not great for KDE, but are they good enough to justify hindering the entire project’s success? WebKit Qt isn’t perfect yet (it can’t handle Facebook Chat particularly well, for example), but it’s still a lot better than KHTML at the moment. There’s a KPart being developed to allow WebKit to render inside Konqueror, and all it needs is a bit of polish before we can maybe start using it full time. In fact, now that I have time and I’m going to be working on WebKit as part of my job, I’ll look seriously into getting into core Konqueror development.
Call me crazy, but back in ‘02 Konqueror was the browser to have - it was fast, it worked on every website (back then), it was slick and it was KDE. I’d like to be able to go back to that, but fast forwarded 7 years!
@I’ll look seriously into getting into core Konqueror development.
Hugs and kisses for this statement..
Well, one can have aspirations, right? :P
I use also use Konqueror as my primary browser (and only occasionally pull up firefox when I want to watch something on Hulu). Konqueror (even in KDE 4) is SO much faster and more responsive than firefox that I can’t ever imagine switching. I like WebKit a lot, but if switching means a slower browser, I’d MUCH rather have TWO browsers available to me – a fast but not necessarily feature complete browser for 99% of my daily browsing and a slower browser that can handle the few instances where I need something else.
I’m a KDE4 and Konqueror user and while the KDE4 version may feel slower it’s still way way faster than Firefox and renders pages that look much nicer. So far I have not come across a single site that the current release of Konqueror can’t handle (including youtube. I think the 64-bit version of Flash is a huge help here).
Note: In my experience just about everything in KDE4 is faster than KDE3, including Konqueror. Though as you said, it’s a purely subjective viewpoint.
@Well, one can have aspirations, right? :P
Sure one can.. I actually wanted to encourage you… coz of all the discussions today in 3 different blogs, I did not see anybody say they would work on the problem..
I very much appreciate your commitment and hope I can contribute may be some time in future..
“Personally, I hate Gecko. It’s got a massive memory footprint and it’s not as fast as I would like.”
Have you tried it recently? I’ll not believe anything about ‘massive memory footprint’ without numbers, and it’s pretty darned fast nowadays…
May we ask who you’re working for? :)
2033 george 20 0 468m 363m 24m S 16 9.1 256:15.62 firefox-bin
Resident memory usage of 363MB… Not so good.
Perhaps more importantly, having firefox open causes my system to use an additional 1-2W of power, courtesy of futex_wait.
@Patcito - I’m working for Torch Mobile starting in August.
My biggest beef is that never over the years did I feel that Konqui worked well enough for the sites I wanted to visit.
KHTML was a great start, which WebKit has improved. And thanks to the higher visibility of Safari and Chrome, more web designers are conscious of Webkit compatibility.
Firefox on Linux is a disappointment, not only in the GTK file dialogs, but in overall speed. I would love to see a nice KDE browser, and I think Rekonq will be a fantastic KDE browser.
But today, I still have to use Firefox.
I recommend you look into Firefox 3.5 betas, which are faster. You can also do configurable url shortcuts in Firefox as well.
@T. J. Brumfield firefox 3.5 final is out already.
Re memory, “Firefox 3.5 showed the best memory efficiency in the average, maximum and final measurements” (over Chrome, Opera, Safari). http://dotnetperls.com/chrome-memory However, that’s on Windows, it would be interesting to test Linux similarly.
I’m typing this from Firefox nightly (bleeding-edge, past Firefox 3.5) on Kubuntu 9.04. FF 3.6 prealpha feels fine to me. I tried Konq for a few weeks, didn’t really notice any Konqeror speed advantage, and its different set of features can’t compensate for its brokenness on sites like Blogger and technologies like interactive SVG (yes I’ve filed bugs).
I think I originally installed FF from ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu and now Help > Check for Updates gets me nightly 64-bit Mozilla builds, currently “Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2a1pre) Gecko/20090628 Minefield/3.6a1pre”
As a Linux n00b, I notice that the rest of KDE/Kubuntu looks and works slightly differently than my browser, but I live in the browser (plus a terminal), so I don’t really care. KDE is just a nice panel strip and Kickoff menu below my browser windows ;-). (And someday, the promise of Nepomuk/Strigi/whatever, should Kubuntu ever deign to turn it on and explain it to me.)
Cheers, YMMV.
hey gwright,
I, like you, have always used and loved konqueror, for the brief periods of time I tried anything geckish I had bad experiences with speed/stability/memory footprint/integration, and I have to say konq4 is better than ever with regards to the few sites I had to break out the fox for.
I can’t wrap my head around everybody’s comments practically telling khtml developpers, to whom we owe the best browsing experience from konq3 to webkit, to stop doing what they like and work for apple/qt/grumpy-kde-user. Instead of shutting up about it and gathering efforts to improve the situation as a community that we are supposed to be.
I don’t particularly feel the need for switching away from khtml myself since the only places it doesn’t work for me are either ill-designed websites, or horribly (read totally unnecessarily) overflowed with slow javascripts/flash/moon-whatever/w$ndows-media-player-plugin for features that should be done with proper xhtml/css/simple-javascripts maybe html5 even. And I try to avoid those sites anyway, because they make me sick.
Apart from this, I know that jane doe, penguin lover, doesn’t care and just wants her gmail/facebook/whatever flashy thingy to work, and as such I feel the, heavily expressed, need to have better ill-designed-sites-compatibility right there, in konq, if we ever want jane doe to use it, and find out about the amazing and unique features of konqueror.
So I feel the need to build a community of developpers around this goal, and since you are the first guy to talk about this that actually is going to do something about it, I would like to ask you if I could help you on this endeavour. I’m willing to use some of my vacation-time in august/september to get up to speed on the webkit kpart, what needs to be done, and whatnot. Are you willing to help me get started and if so where can I contact you once I have some free time?
Thanks
As a web developer I use firefox (with firebug & co.) as my main browser. I tried konqueror several times and check my pages with it every time. But I have never seen that konqueror is faster than firefox. (using Core2Duo, 4GB RAM, KDE 4.3, Gentoo 64bit)
I totally agree with you that KDE desperately needs volunteers to work on the WebKit integration. However, these people need not be the existing KHTML developers. We are not paying to these people and we cannot tell them how they should spend their time. If they find KHTML more fun, let them play with KHTML. There can be others, like you (you admitted being interested!), who can do the WebKit stuff.
Notable exceptions are 80-90% of the top most visited sites in the internet, all of which are very AJAX-heavy.
””“I totally agree with you that KDE desperately needs volunteers to work on the WebKit integration. However, these people need not be the existing KHTML developers. We are not paying to these people and we cannot tell them how they should spend their time. If they find KHTML more fun, let them play with KHTML. There can be others, like you (you admitted being interested!), who can do the WebKit stuff.”“”
Well sure. They are certainly allowed to pursue whatever they want.
It’s just that if they want to push KDE to be competitive with other desktops then they should probably stop flogging the KHTML horse.
The thing is that WebKit has lots of developers from lots of different arenas. There are GTK webkit browsers in the form of Epiphany and Midori. There is Google Chrome. There is Apple’s Safari, and probably a half a dozen others.
With KHTML you have one group of Konqueror folks working on it and that is getting rapidly outclassed by it’s competitors.
If KDE folks are interested in Webkit as a replacement for KHTML they better get their fingers into it now.. because as time has shown the people that develop on Webkit are not going to cater to KDE’s needs.. More then likely it will continue to get more and more difficult to integrate as KDE and Webkit matures on their seperate paths. it’s up to KDE to work on Webkit and improve it to the point were it can benefit KDE heavily.
So it’s a question of goals. To the Konqueror developers.. is it a playground you want to have fun in or do you want to have KDE competive? Or both? Whatever gets choosen by the majority of the people will certainly require choices to be made.
Hell, I could be entirely off base here. It could be that the KHTML designers are onto something that will propell that engine further and maybe KHTML will start to kick ass heavily. But so far it’s does not seem that way.
You are free to do what you want. I would be really happy if a good kde webkit browser was available too. But telling developpers : “stop working on your project, because many people prefer that you do that” is not how open source works.
I think this is the main problem about all the ‘KHTML vs Webkit’ discussions. Actually, discussing this is quite pointless. I’m under the impression that people think this way : “we can’t have a good webkit browser because khtml is the default on kde”. And they start blaming khtml developper… (I’m not talking about you George, but about a lot people that leave comments on blogs)
I’m not blaming any KHTML developer. I really appreciate their work.
What I blame is the missing common direction in the KDE project to help to deliver an usable web experience to the normal user.
Trying to get KHTML on an usable level has failed and the suboptimal experience with some of the new Web 2.0 sites are really a delabreaker for a lot of people.
I think the KDE project as a whole has to make a decision that Webkit is the only solution for the future.
As long as KHTML is supported as the standard HTML engine in KDE, people will not give Webkit integration the work it deserves.
There really no technological reasons not to use Webkit in KDE which aren’t solvable in the near future. The only problem is that some people are needlessly clinging to KHTML and are preventing the KDE project as a whole to evolve in the right direction.
Scrapping KHTML is not the optimal solution however. We should have a WebKit KPart to do the rendering, but KHTML should be continued alongside it till it eventually achieves this equality necessary for the rest of the users. Choice is not a bad thing, and there’s no reason why one shouldn’t be able to switch bbetween WebKit and KHTML
In the meantime, if you want a browser that uses WebKit, you could give Arora [1] a try. My opinion is that it would be better to work on WebKit since there seems to be a lot more developers involved and there is no need to duplicate a lot of effort.
[1] http://www.arora-browser.org
I think Kristian ask the most important question:
It is obvious that KHTML will not deliver anything to the end-user in the near future. That’s why using WebKit as the DEFAULT engine is imho the best choice to make. And this should happen as soon as possible. Hopefully George will make WebKit really usable with Konqueror. Still kdelibs are centered around KHTML and as such KHTML is the official engine to use. I think it really should be considered to remove it from the core framework in the future and make it an optional API. Qt already offers the WebKit API and there are basically no projects which use KHTML as a rendering engine instead of WebKit.
Of course KHTML developers can continue to work on KHTML if they like. And even if some rightfully say that telling developers what to do is not the “open-source way”, I think encouraging KHTML developers to join WebKit is another thing. Maybe some of the developers realize how bad KHTML is for public perception of KDE as a whole and join forces with the WebKit team. After all the code is not THAT different. It’s probably more an ideological dogma that stops the rest of the KHTML developers to switch to WebKit.
“There really no technological reasons not to use Webkit in KDE which aren’t solvable in the near future.”
I’m afraid there are. There is a different distribution of concerns in the QtWebKit world compared to the KPart/KHTML one. For example, Konqueror and QtWebKit both keep track of history. History management in KParts cannot be moved to the parts themselves, nor QtWebKit history moved to the containing app, because that would be BIC. There are other examples as well, such as use of SSL in KIO vs. QtNetwork.
Also, a truly compatible KHTML drop-in would also not work, largely for the same reasons.
Kristian and others,
Everyone talks about switching, but to what? A barely functional, poorly integrated Webkit kpart? A webkit browser that is still in developement and not yet complete?
Unless the Webkit kpart or some other satisfactorily working solution is available, declaring KHTML “non-standard” would do more harm than good: Leave the everyone (developers AND users) with an unmaintained KHTML AND no fully functioning viable replacement. The simple fact of the matter is that if a compelling enough Webkit solution becomes available (as a result of people putting their efforts where their mouths are) that is actually functionally better (rendering AND KDE integration) than what KHTML provides, then we can start talking about switching defaults.
So, by all means, advocate that work get done on a Webkit solution if you think that’ll solve your browsing problems. But it simply does not makes sense to insist that KHTML developers stop working on what they enjoy, and ultimately prevent the rest of us from benefiting from that work.
Loinur, Why bother speculating about code being “not THAT different” and the so-called “ideological dogma” of the KHTML developers? It would make more sense for you to actually inspect the Webkit code and the KHTML code and understand the differences before talking about them. It would make more sense for you to actually read what the KHTML developers say and realize that they are not preventing anyone from working on a Webkit solution.
@Michael:
I don’t think anyone is suggesting that it is an easy thing to do. Yes, Konqueror is very tied in with KHTML, and there are KHTML-specific extensions present that allow the browser to act like a browser (that sort of compliment KParts in a weird and wonderful way, or so I’m told).
What’s to stop us from looking at the exposed APIs from WebKit and KHTML, and then designing a “Common Browser API”, KBrowserPart if you will, that would allow us to hopefully embed /any/ browser component into Konqueror.
Personally, I want KHTML to stick around, but I’d like to be able to have WebKit as an option as well. Yes, it will require some work on the API for KHTML, but I’d think it would be worth it so that we can get a better designed system that’s more generic and less specific to one particular implementation.
I’m guessing that you are using a really really old and broken version of Firefox?
“and its configurable web shortcuts (such as gg:, wp: etc) are insanely useful.”
Firefox has had this feature for as long as I have been using firefox but its much much nicer in that you don’t have to append the ‘:’ to the end of keywords. Just right click on a search box and select ‘add a keyword for this search’.
“Resident memory usage of 363MB… Not so good.”
363 MB - your distro has seriously broken something there, no wonder Mozilla want that crap rebranded! I have never seen Firefox above 110MB even after many days use however Konqueror is still much much better:
four tabs open: Google Mail, Google Reader, Metcheck, here
14330 dave 20 0 247m 86m 22m R 4.0 17.5 1:17.30 firefox-bin
14318 dave 20 0 220m 68m 29m S 0.7 13.7 0:13.85 konqueror
Konq is about 20 meg less and that is about right however open some flash and you have to account for nspluginviewer which is 38 meg alone. So in my experience Konqueror is a little better on the whole but Firefox isn’t that much worse.
I am using version 3.5 - released a week ago or so.
“Firefox has had this feature for as long as I have been using firefox but its much much nicer in that you don’t have to append the ‘:’ to the end of keywords. Just right click on a search box and select ‘add a keyword for this search’.”
Having to point and click several times to make a simple search instead of just pressing ^L and type gg:something, or rae:palabra is a lot more annoying.
Wasting space of the toolbar for the search box is also a dumb thing, and having to delete the old text to make a new search is pretty annoying too.
And even adding custom (or adjusting the parameters of them) search engines in firefox is a lot harder than in konqueror.
Besides these points, firefox has another big drawback, it does not support kio nor gio nor anything, that means I can’t browse using sftp with it.
A last thing I’d like to ask, is that firefox not using nspluginwrapper is more crash prone at bugs from plugins (sadly a common thing in the flash plugin from adobe)
This is just to say that both browsers have good and bad things.
s/mention/note/
s|s/mention/note|s/ask/mention/|; # :P
Check out rekonq (for kde 4). Its a qtwebkit based browser (like arora) that aims for full kde intergration. It really is the future of kde web browsing IMHO! Though its not very feature ritch at present.
Hi, I know it’s a bit late, but anyway…. I had been using Gnome for years and switched to KDE for a try. I really like it.
In Konqueror 4.4.1 (on up to date - of today -) you can choose the rendering engine : khtml or webkit.
However i don’t see much difference…
I actually switched to konqueror because my usual webbrowser, google-chromium, use gtk as a file manager when you download stuff. This was pretty irritating cause sometimes the file you just download are not displayed in Dolphin… So now, thanks to konqueror, i have a really good webkit browser. Actually it’s even faster then chromium. As i don’t use the “themes and plugin stuff”, it’s very conveniant to me. However, it’s sad it’s so tied up to KDE. I like my tools to work as well on any Unix or even Windows. Konqueror will never go farer than KDE. I really like it’s fine tuned configurator!
Cheers
good articles
I really loved it the way of the stuff provided in this article. I definitely enjoying every little bit of it.
I admiring time and effort you put in your blog, because it is obviously one great place where I can find lot of useful info..