WebKit Gives Konqueror a Speed Boost (Past Firefox)

An anonymous reader writes "We always knew that WebKit is going to make Konqueror fast; but how much faster? Today we test that by putting Konqueror with KHTML through the SunSpider JavaScript Test and the then do the same with WebKit. To get an idea of how fast they are compared to other browsers, we also decided to put Firefox 4.0 Beta 2 through the tests."

Comments

I Guess ...

[WrongSizeGlass]

I Guess they finally Konquered that speed barrier they were dealing with. If you look at their old speed numbers you'll see that they used to perform like an old lady crossing the street. Now it's more like the car racing away after running over the old lady.

Re:I Guess ...

[sznupi]

"...like an old lady krossing the street. Now it's more like the kar racing away after running over the old lady.
--
"If I'd asKed my kustomers what they wanted, they'd have said a faster horse." ~ Henry Ford"

^fixed...

Re:I Guess ...

[Anonymous Coward]

Uh, the "racing away after running over the old lady" thing is not a good description of speed. Either it is only an accident and the driver lost sanity after realizing what has just happened, raced away like mad at crazy speed and crashed into something else afterwards... or a deliberate killing, in which the murderer slowly wanders around trying to cover the tracks and pretending to be innocent... wasting lots of time in the progress. And both of them are not "fast".

Also, oh God free software kills old ladies!

Re:I Guess ...

[Anonymous Coward]

WOW! What a great opportunity for a pizza analogy!

Too bad I don't give a fuck.....

Re:I Guess ...

[Anonymous Coward]

Also, oh God free software kills old ladies!

At least it finally stopped killing kittens and puppies.

Re:I Guess ...

[Anonymous Coward]

"...like an old lady krossing the street. Now it's more like the kar racing away after running over the old lady.
--
"If I'd asKed my kustomers what they wanted, they'd have said a faster horse." ~ Henry Ford"

^fiksed...

WOW!

[Anonymous Coward]

Faster than Firefox? HOLY SHIT!

Re:WOW!

[Anonymous Coward]

Faster than Firefox? HOLY SHIT!

Hard to imagine, eh?

Re:WOW!

[Runaway1956]

Actually - Firefox's strength hasn't been speed for quite some time. It's that ADDONS and personalizations that make fans now. Back in the day, Firefox was blazing fast when compared to IE. But, even IE has evolved since then.

Re:WOW!

[Anonymous Coward]

Whoosh

Fucking DUST 2 DUST man !

[Anonymous Coward]

It's like the end. Death is at the door. Welcome him, do not fight ! Those opensorces cost you in the end, and in the middle, and in the beginning, as it is, as it was. Ahhhhmen.

Mixed tenses

[Anonymous Coward]

The mixed tenses in the opening paragraph set my teeth on edge:

"We always knew that WebKit is going to make Konqueror fast"

You knew it is going to make it faster? FFS.

Re:Mixed tenses

[X0563511]

You need to getting laid.

What about Firefox Beta 3?

[Anonymous Coward]

Firefox 4 Beta 2? Firefox 4 Beta 3 is out and has even better Javascript performance.

Re:What about Firefox Beta 3?

[Anonymous Coward]

How the hell is this a troll?

To get an idea of how fast they are compared to other browsers, we also decided to put Firefox 4.0 Beta 2 through the tests

Beta 3 came out several days ago and does indeed have better JavaScript performance.

What the hell

[Anonymous Coward]

Yea I can make up a chart that shows that my ass is faster than a geforce480 at crysis but it doesn't mean anything without facts

oh and I love how they ignore test's to get higher overall averages

Re:What the hell

[Runaway1956]

Would you consider breeding your ass with some nice quarterhorses? I'll split the profits I make when we start burning the barrels up at the rodeos!

How important are JavaScript times?

[mickwd]

How important are JavaScript times to the overall speed of rendering pages?

Is it like comparing 0-60 times for cars (a decent indication of performance, though not the best)? Or is a bit like measuring the time from 0-10 in first gear - a rather insiginificant proportion of the whole time taken to render a cross-section of typical web pages?

Do sites just concentrate of JavaScript performance so much because it's easier to measure?

Re:How important are JavaScript times?

[arose]

How important are JavaScript times to the overall speed of rendering pages?

That is the wrong question. How important is Javascript speed for advanced web applications and HTML5 games?

Re:How important are JavaScript times?

[phantomfive]

It's looking towards the future. HTML 5 is designed to replace Flash, but it can't do it if Javascript is slow. Performance is going to be an important differentiator in browsers, for how well they are able to run web apps (of course, if all browsers speed javascript up to roughly the same performance level, it won't be a differentiator).

Re:How important are JavaScript times?

[bjourne]

I know nothing about cars so I can't give you a car analogy, sorry. However, javascript performance isn't very important at all unless "the page" really is a full javascript application ala gmail. The reason for that is that you delay the javascript execution until after the whole page has rendered by hooking up your code with the body onload event. This avoid the page lockups you can encounter on badly coded pages where the browser can't render the page before the javascript has been run to completion.

Of course, the above is only true if all the javascript on the page follows best practices. That is seldom true if the page includes javascript from ad networks which has the bad habit of running document.write calls during the loading of the page. Since document.write can modify anything on the page, when such a function call is executed, the browser has to stop everything else until the javascript is run and then continue rendering. In that scenario, faster javascript execution would definitely lead to much faster page loads.

Re:How important are JavaScript times?

[X0563511]

I don't know about you, but the only time a page doesn't load instantly is when it has large content waiting for data to come down through my Internet "Service" "Provider" or chew on some Javascript. I've never seen HTML take long at all, unless it's a 200k+ behemoth.

Re:How important are JavaScript times?

[tepples]

How important is Javascript speed for advanced web applications and HTML5 games?

Cue the inevitable weenies who protest that the web is intended for documents, not applications, and applications should be written in native code, not JavaScript. In fact, queue them too because there seem to be so many of them.

Re:How important are JavaScript times?

[TheRaven64]

JavaScript performance is important because everything else is already so fast you won't notice. A web browser first needs to parse the [X]HTML to construct a DOM. Any reasonably fast computer is bottlenecked on I/O doing this, even with quite a poor implementation. Then it has to build a layout tree. Even pdftex, which produces nicer output than most browsers and runs incredibly slowly can do about ten pages a second of text-and-image layout and a web browser only needs to finish laying out one screen full quickly - anything off the screen just needs to be finished before the user scrolls that far down the page. Pretty much all browsers are still bottlenecked on I/O here too. If you watch the scroll bar growing on a large page sometime, also watch the network usage; the layout is still going on because the page is still loading. If it comes from the local disk, it may take a couple of seconds, but only for really huge pages.

And then there's JavaScript. Once the DOM tree is built and rendered, the scripts run. They're usually badly written, and even when they're not, they're still difficult. JavaScript is a very dynamic language. It basically has three primitives: closures, dictionaries, and double-precision floating point values. Everything else in the language is constructed from this. I've written a JavaScript compiler, so I can say with some authority that making this stuff go quickly is hard.

A lot of interactive things in a page use JavaScript. Things like dynamic menus, drawing in the canvas, and so on. Poor performance on code that runs the UI is immediately noticeable for the user.

Re:How important are JavaScript times?

[Anonymous Cowpat]

I know nothing about cars so I can't give you a car analogy, sorry.

You must be new here...

Re:How important are JavaScript times?

[turgid]

It will be a sad day indeed when the majority of the world does its business in JavaScript.

Re:How important are JavaScript times?

[Gerard Ketuma]

important when we want to create true dynamic content without using flash.

Re:How important are JavaScript times?

[Anonymous Coward]

How important are JavaScript times to the overall speed of rendering pages?

Is it like comparing 0-60 times for cars (a decent indication of performance, though not the best)? Or is a bit like measuring the time from 0-10 in first gear - a rather insiginificant proportion of the whole time taken to render a cross-section of typical web pages?

Do sites just concentrate of JavaScript performance so much because it's easier to measure?

JavaScript is either a total nonissue, or it's huge one, depending on the page.

With simple pages, bandwidth and latency are the primary factors, and JavaScript doesn't come into the equation. But there's not much browsers can do about your connection.

With web apps, JavaScript can make or break your page. And there's still quite a bit of difference between the laggards (IE) and the mid-pack (Firefox) to say nothing of the leaders (Chrome/Safari)

Re:How important are JavaScript times?

[jeremyp]

Who cares? The fact is that most of the web is documents, not applications. Javascript performance is largely irrelevant when rendering Wikipedia or Google. So why does anybody care about its speed?

Re:How important are JavaScript times?

[dingen]

Since the majority of business is still being handled by COBOL, you really haven't got anything to worry about yet.

Re:How important are JavaScript times?

[tepples]

Javascript performance is largely irrelevant when rendering Wikipedia or Google.

MediaWiki sites such as Wikipedia don't use a lot of JavaScript, but Google does. Google Search's live suggestion was one of the first applications of the paradigm now called AJAX, and Gmail is an outright web app.

Re:How important are JavaScript times?

[fast turtle]

Of course, the above is only true if all the javascript on the page follows best practices. That is seldom true if the page includes javascript from ad networks which has the bad habit of running document.write calls during the loading of the page. Since document.write can modify anything on the page, when such a function call is executed, the browser has to stop everything else until the javascript is run and then continue rendering. In that scenario, faster javascript execution would definitely lead to much faster page loads.

And that's exactly why I use NoScript and white list only those pages that need JavaScript working. IMO the damn advertisers are the worst ofenders for using jscript wrong and I figure they can eff off and die because I've got no interest in supporting their business model.

Re:How important are JavaScript times?

[Frosty Piss]

Performance is going to be an important differentiator in browsers, for how well they are able to run web apps

Well, that knocks Firefox out of the running. Slow as a snail, memory hog... I gave up FF for Chrome / Safari (WebKit) many moons ago. Until they get a handle on memory management and the speed of their JS engine, I'll not return.

Re:How important are JavaScript times?

[Anonymous Coward]

It's like he just got his Slashdot learner's permit...

Re:How important are JavaScript times?

[kamikaez]

It's important, but it's just one piece of the puzzle.
I for one think MS have done the right thing here, at the level V8/ Opera and probably soon IE9 & FF4 is, hardware accelerated graphics are just as or more important when creating games and applications with rich interfaces and graphics.

Re:How important are JavaScript times?

[bonch]

Well, it is. Using the web as a platform for applications is adding a completely pointless, slow-performing layer on top of native APIs that companies have spent decades creating. The story behind the iPhone SDK (how Apple initially offered web-only application development, but developer protest led to a native SDK) is an example of how native application development is superior to the web. Hell, web apps haven't yet figured out how not to break the functionality of the Back button.

Re:How important are JavaScript times?

[Anonymous Coward]

How important is Javascript speed for advanced web applications and HTML5 games?

Cue the inevitable weenies who protest that the web is intended for documents, not applications, and applications should be written in native code, not JavaScript. In fact, queue them too because there seem to be so many of them.

Can I queue your girlfriend ..?
(Please don't tell me I have to queue for this as well !)

Re:How important are JavaScript times?

[Anonymous Coward]

Their business model is putting stuff up on the web to attract people so that the people see their advertisements. So, when you say you don't want to support their business model you are saying you don't want stuff on the web? Or that not only does information want to be free, so does bandwidth, servers, administrators, and web developers? I get it that you think the world owes you the internet for free, but if you stop to think about it that isn't a very realistic view of the world.

Re:How important are JavaScript times?

[aliquis]

protest that the web is intended for documents, not applications, and applications should be written in native code, not JavaScript.

Come back when Firefox can render the equivalent of * on a 7 MHz machine with 512 kB of RAM.
Enigma - Phenomena
Andromeda - D.O.S
Sanity - World of Commodore 92
Silents and Anarchy announcetro of the Silents France

Re:How important are JavaScript times?

[tepples]

Using the web as a platform for applications is adding a completely pointless, slow-performing layer on top of native APIs that companies have spent decades creating.

You have to be administrator to install a native application. You don't to use a web application.

Re:How important are JavaScript times?

[masmullin]

Shes not a queue, shes a stack.

Re:How important are JavaScript times?

[Anonymous Coward]

They became important because IE had(?) a slow JS Engine :) How else would people feel that righteous nerd-rage leaving a negative comment on a website about a successful multi-billion dollar company and ultimately having no effect whatsoever on their revenue.

Re:How important are JavaScript times?

[Anonymous Coward]

Or is 0-60 relevant at all when most people use their car to drive to and from work, to and from soccer practice, and in fact make purchasing decisions based on interiors, features, etc...(or add-ons, ad blocking, and interface)

Re:How important are JavaScript times?

[gfody]

the scene is still alive you know there's a whole category for js http://www.pouet.net/prod.php?which=18327

Re:How important are JavaScript times?

[Runaway1956]

This post might be more informative if you specified the speed of your connection. If you happen to live next door to a university, and have access to their fiberoptic trunk - you'll seldom wait for anything. I mean, can you download movies in less than a week? Less than a day? Less than an hour?

I can download an ISO in 12 to 20 hours, if I don't mind listening to the wife and kids bitching about the lack of internet on their machines. Throttling my download so that I don't have to listen to their bitching means that the ISO of BackTrack4 R1 takes about 3 days.

Re:How important are JavaScript times?

[smash]

A LIFO stack? Hmmm messy.

Re:How important are JavaScript times?

[Anonymous Coward]

Remember that Flash basically runs JavaScript as well (ActionScript2 is basically what EMCAScript4 was going to look ilke - and Adobe is still sharing the backend with Mozilla in Tamarin).

The slow part isn't the JavaScript; it's interacting with the DOM and other things. It's not admitting that, really, JavaScript execution shouldn't block the rest of the browser from working.

Out-of-process web pages the way chrome does can make it better for interactivity.

Re:How important are JavaScript times?

[valeo.de]

Only an ignorant (or should that be arrogant and stupid?) dev chooses a language that is strongly typed and requires compilation when a less strict scripting language is the right tool for the job.

Re:How important are JavaScript times?

[bonch]

Most people are running accounts with installation capability. If you're running a system that you're not an administrator on (i.e., a corporate desktop), chances are the web application you run would be an enterprise app that requires a username/password too.

Re:How important are JavaScript times?

[Joe Tie.]

One of the main reasons webapps on the iphone didn't take off is that apple just did a piss poor job of it. Their html5 support is piss poor now. Beck then it was even more of a mess. And they also lacked extra functionality to make a webapp take on the feel of an app app. Android recently received JIT compilation for JS, and it made me take back a lot of my previous bias about webapps. I have a couple on there right now, and with froyo they really are pretty much indistinguishable in terms of performance.

Re:How important are JavaScript times?

[WhyMeWorry]

I know nothing about cars so I can't give you a car analogy, sorry.

You must be new here...

So new that he hasn't learned that knowledge is to his detriment when posting here.

Re:How important are JavaScript times?

[advance-software]

WebGL enables implementation of 3D graphics engines in-browser in javascript.

3D graphics engines must be fast in order to provide a fluid end user experience (60 fps).

The WebKit js engine apparently compiles down to native (machine) code.

Does the mozilla equivalent yet, or does it still run through a byte code interpreter ?

This ain't about pages :)

Re:How important are JavaScript times?

[Bert64]

Native APIs are not native across different platforms, so the browser offers a standardised abstraction layer on top of that..

Performance hasn't been terribly important for years, and developers are already coding in high level languages which have multiple performance killing abstraction layers between the user and the hardware.
Even those native APIs you talk about have over those decades been getting slower and slower...

Re:How important are JavaScript times?

[Rich0]

I dunno, but when I ditched firefox years ago Konqueror was the first browser I went to. The reason? Page rendering times.

For whatever reason when opening multiple tabs firefox would occasionally go into la-la land and tab after tab would just end up frozen in a loading state (tabs that had rendered worked, new fetches were frozen). It was as if some thread held a lock keeping anything from doing anything. Then all the sudden they'd all load in rapid order (maybe 1-2 mins later). Yes, I checked the various about:config settings on number of parallel fetches and all that...

Not sure if they've gotten their act together. I think I read somewhere that Firefox had re-optimized much of their engine, except that they hadn't done it for 64-bit linux so it was still in the stone ages. Webkit worked just fine, however.

Also, knoqueror was a lot less fussy about locked profiles, which meant I could actually use it in two different X11 DISPLAYs at the same time. For some reason almost nobody else supports this.

Now I'm on chromium/xfce, because KDE decided to stop supporting any system that wasn't bought in the last 2 years, and knoqueror doesn't work so well if the rest of KDE isn't installed. I just wish they'd fix their multiple-DISPLAY problems.

Re:How important are JavaScript times?

[jisatsusha]

In the case of ad networks, the actual running time of the javascript is rarely an issue. The biggest problem is that when the browser encounters a script tag on a page, it stops rendering until the javascript has fully downloaded and run (because, as you say, of things like document.write). So the biggest factor in this case is how fast the script downloads, and a lot of ad servers are so overloaded, this can take tens of seconds, making the page appear much slower.

Re:How important are JavaScript times?

[X0563511]

I pay $30/m for Comcast Cable. Burst speeds do reach up to 1mb/s on occasion - real throughput seems to live around 300k/s to 600k/s.

Connection speed shouldn't make too much of a difference unless you have something like dialup, slow DSL, or a poor vsat link. Even then, those would be content downloads hanging it up, not text. Hopefully.

Re:How important are JavaScript times?

[Anonymous Coward]

I know nothing about cars so I can't give you a car analogy, sorry.

You must be new here...

Is that like a car just bought from the dealer, driving around a new town? Or a car looking for a parking space at a out-of-state mall, where the locals know all the good parking spots and all the intended parking behaviour and courtesies, but the new car doesn't?

I guess my Dutch heritage makes me more partial to bike analogies...

Re:How important are JavaScript times?

[Anonymous Coward]

Javascript is the COBOL of the 90's

Re:How important are JavaScript times?

[commodore64_love]

Maybe you should switch to DSL?

A throughput of 300k to 600k/s is only 40-70 KB/s. In contrast with DSL I pay only half what you pay but I get a consistent 90 KB/s on downloads and torrents.

Re:How important are JavaScript times?

[CodeBuster]

The problem comes when people begin expecting that anything which can be done in a native application can also be done on the web just as easily. Is it possible to build large and complex applications with dynamic languages, like JavaScript, that do not enforce static types? Yes, it is possible (obviously Google manages to pull it off), but I would argue that once a certain level of complexity is reached, the dynamic nature of languages like JavaScript becomes more of a hindrance than a help. It is in these large and complex applications where static languages prove their worth. Should we try to emulate a complete virtual OS in JavaScript inside a browser window? How about a complete suite of office applications or a complex 3D game? Could these sorts of things be done in JavaScript? Probably. Should they be done in JavaScript? Probably not and therein lies the problem. Web apps raise the expectations of users, but many ultimately fail to deliver the goods when user demands increase and features or behaviors, which users have come to expect from similar native apps, remain unfulfilled.

Re:How important are JavaScript times?

[Compaqt]

I'll admit that it's slower than native code.

But it's not "completely pointless".

For one, from the user perspective, you don't have to install applications. Leaving aside the permissions issue, it's an advantage that you don't have to give full access to your computer to 10 random apps off the Web when you're evaluating, say a mail program or a graphics program.

Second, again you don't have to install programs. It's easier and faster to get to the point where you're running the program. You don't have to go through the download, run, click through the "Are you sure you want to run this dangerous program" dialog, click through the installer, and then find the program in Start>Programs. And there's no uninstall, no VB/VC/.NET runtimes or other detritus left on your system.

Third, again from the vendor perspective, the user doesn't have to run install programs. If you want to make an update, or fix a bug, you do it, test, and roll out. The change is instantly available to users without having to go through and upgrade process.

Finally, you while you lose the nicety of some native widgets, you gain the link paradigm, which is great because you can easily connect various portions of an application.

Re:How important are JavaScript times?

[Anonymous Coward]

what do you mean by rich?

Re:How important are JavaScript times?

[mortonda]

Bonus points for using cue and queue properly! Are you sure you intended to post this to /. ???

Re:How important are JavaScript times?

[tepples]

Native APIs are not native across different platforms

What different platforms? A company can shut out Mac and Linux users and still make a profit.

so the browser offers a standardised abstraction layer on top of that

Since when is Internet Explorer standardized?

Re:How important are JavaScript times?

[Anonymous Coward]

Probably an error in units. An equivalent $30 Comcrap offer in my area would be about 1MB per second (8Mb/s) advertised with closer to 600kB/s observed throughput.
 

Re:How important are JavaScript times?

[X0563511]

I was talking bytes. Sorry for the confusion.

I can (on occasion) pull down a solid megabyte/second, though the common rate seems to be half that.

I can upload about 1/4 of those numbers.

Not a useful comparison (yet)

[Anonymous Coward]

I don't think it's all that useful to compare the JavaScript engine in Firefox's beta releases to other engines at this stage. JaegerMonkey, Mozilla's new method JIT compiler, is not yet integrated into the beta releases. JaegerMonkey is making steady progress in improving performance and in a couple of months or so will likely be on par with Nitro and V8. See http://arewefastyet.com/ for charts of JaegerMonkey's progress and for a breakdown of each of the individual tests see http://arewefastyet.com/individual.php. The regress chart is interesting to see the performance gains to be had when TraceMonkey and JaegerMonkey are used in combination.

Re:Not a useful comparison (yet)

[amicusNYCL]

JaegerMonkey is making steady progress in improving performance and in a couple of months or so will likely be on par with Nitro and V8.

You mean, in several months Mozilla will be approaching the level that Google is at now. It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.

Also, Opera is faster than Mozilla as well, I'd like to see it included on that chart to compare with the others. Maybe even IE9, if it doesn't skew the Y-scale too much.

Re:Not a useful comparison (yet)

[Anonymous Coward]

You mean, in several months Mozilla will be approaching the level that Google is at now. It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.

No. I mean in a couple of months Mozilla's JavaScript engine will likely match Google's. In several months Mozilla's engine may have surpassed Google's.

Also, Opera is faster than Mozilla as well, I'd like to see it included on that chart to compare with the others. Maybe even IE9, if it doesn't skew the Y-scale too much.

Read the FAQ.

Re:Not a useful comparison (yet)

[Anonymous Coward]

Firefox is a monster now. I can't even fathom why I would want to use it, unless I felt like watching my memory usage skyrocket. I've kept it around for the occasional site that doesn't suport Chrome or Safari, but lately I've found myself just falling back on IE instead. At least IE doesn't have the memory leaks of Firefox.

Re:Not a useful comparison (yet)

[Anonymous Coward]

You mean, in several months Mozilla will be approaching the level that Google is at now. It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.

You may find this four browser HTML5 speed test video instructive.

Re:Not a useful comparison (yet)

[Abcd1234]

It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.

It is? Huh. I mean, sure, they've done great work on their Javascript engine, and kudos to them for that. But according to Wikipedia, it was first released in September 2008. It took until January *2010* for them to implement a freakin' extension system. Hell, it took them 8 months just to implement mouse wheel support and full screen mode!

No, I think its more accurate to say Chrome has just had a lot further to go, and so their pace of development looks impressive when compared to an established project like Firefox.

Re:Not a useful comparison (yet)

[amicusNYCL]

But according to Wikipedia, it was first released in September 2008. It took until January *2010* for them to implement a freakin' extension system.

To be fair, the time between Phoenix 0.1 and Firefox 1.0, when the extension system was implemented, was 25 months, longer than the 16 months it took Google.

No, I think its more accurate to say Chrome has just had a lot further to go, and so their pace of development looks impressive when compared to an established project like Firefox.

The impressive part is that Chrome has managed already to beat Firefox in several areas, even though Firefox has a head start of 6 years and has been actively developed for all 8 of its years.

Re:Not a useful comparison (yet)

[amicusNYCL]

No. I mean in a couple of months Mozilla's JavaScript engine will likely match Google's. In several months Mozilla's engine may have surpassed Google's.

Are you assuming that Google is going to stop developing Chrome, that Mozilla is going to manage to reverse the trend and significantly outperform Google, or that we have reached the pinnacle of Javascript engines with V8 and no further development is possible?

Re:Not a useful comparison (yet)

[Abcd1234]

The impressive part is that Chrome has managed already to beat Firefox in several areas

In a few areas, yes, and only because they could benefit from the many years of experience gathered in the development of web browsers. When Firefox first hit the scene, a JITing JS engine wasn't even a consideration, as top-notch JS performance simply wasn't that important. The same goes with things like tab and plugin isolation, etc.

I mean, don't get me wrong, Chrome is a very nice piece of work, and Google has the advantage of having a number of paid engineers working on it full time, with a focused vision. My comment was only meant to inject a little perspective into the discussion.

Re:Not a useful comparison (yet)

[amicusNYCL]

That's an interesting demonstration, but the topic under discussion is Javascript performance, not HTML5 rendering speed. Considering YouTube's usage of HTML5, I think it's likely that Google will begin investing more into the HTML5 development side of Chrome than they have in the past, and seek to gain the same type of performance increases that they have achieved with V8. I would, however, like to see a version of that test with each browser running individually in fullscreen or maximized. It may be the case that the CPU is at 100% usage and that IE and Firefox are more effective at getting CPU time than Chrome and Opera.

Re:Not a useful comparison (yet)

[amicusNYCL]

In a few areas, yes, and only because they could benefit from the many years of experience gathered in the development of web browsers.

Well.. that's kind of like saying that the only reason they're ahead is because they have more and better programmers. In the top 5 browsers, Firefox's Javascript engine is fighting with IE for 4th place.

It's probably just the case that Mozilla has focused on things other than Javascript, where Google has a very real need for a browser that can handle large Javascript applications quickly. The two orgs just have different priorities, but I do think that Google is working very quickly, maybe even quicker than any other browser vendor. The IE team has shown a lot of good work lately, but it's taken a really long time, and Opera seems to work at a pretty good pace. Safari doesn't often include very many new features, but the base technologies are certainly improving.

Re:Not a useful comparison (yet)

[Anonymous Coward]

Are you assuming that Google is going to stop developing Chrome, that Mozilla is going to manage to reverse the trend and significantly outperform Google, or that we have reached the pinnacle of Javascript engines with V8 and no further development is possible?

V8 has gone about as far as it can go with its current approach. Google needs to start exploring alternative approaches to improve V8 further. i.e. follow a similar path to Mozilla's approach using method and tracing JIT compilers in combination.

Look at the charts. On the x86 chart, from the 22nd of July to the 13th of August V8 is 6.4 millseconds worse on Sunspider (let's call it no change) and 17.4 milliseconds better on the V8 benchmark.

On the x86_64 chart you've got V8's performance from the 12th of May to the 13th of August. In three months Google has only achieved a 20.9 millisecond improvement on the SunSpider benchmark and an 89 millisecond improvement on the V8 benchmark.

Re:Not a useful comparison (yet)

[Elektroschock]

Chrome uses Webkit!
Apple Safari uses Webkit!
Nokia uses Webkit!
KDE Konqueror uses Webkit, in fact it was invented by them under the name KHTML.

So imagine that KDE's Konqueror will benefit from Webkit progress, now that they support webkit along KHTML

Re:Not a useful comparison (yet)

[Anonymous Coward]

That's an interesting demonstration, but the topic under discussion is Javascript performance, not HTML5 rendering speed.

The usefulness of fast JavaScript is limited without fast rendering go to with it. That video demonstrates both JavaScript engine performance and layout engine performance. You said "Google is able to develop Chrome much faster than Mozilla is able to develop Firefox" but it seems clear there are significant areas in which Google's browser is currently extremely deficient.

Google didn't start Chrome from scratch. They took the WebKit layout engine and built Chrome around it. WebKit grew out of KHTML which was started in 1998. There's 12 years of history in Chrome and much of WebKit is developed by Apple. Google relies heavily on the contributions of others to make Chrome work and is no faster at development than anyone else.

Re:Not a useful comparison (yet)

[cbhacking]

Maybe even IE9, if it doesn't skew the Y-scale too much.

Last I checked, IE9 was faster than Firefox 4 beta by a substantial margin, and has in fact also passed Safari 5 (WebKit-based, of course). Chrome and Opera are still very slightly ahead, but not by much.

http://ie.microsoft.com/testdrive/benchmarks/SunSpider/Default.html

Re:Not a useful comparison (yet)

[cbhacking]

Admittedly it's not even in beta yet, but I think you sorely misunderstand the improvements that IE9's JavaScript engine has made. It's more accurate to say that it's clawing with Safari for 3th place, and as of the most recent preview it's winning. Firefox has been left far, far behind. Opera and Chrome are still ahead, but it's down to less than 100ms difference between IE9 and Opera 10.6.

Re:Not a useful comparison (yet)

[amicusNYCL]

V8 has gone about as far as it can go with its current approach. Google needs to start exploring alternative approaches to improve V8 further.

I agree, do you think they're not going to do that? I don't think they're going to let their Javascript engine of all things become stale. Mozilla has made impressive gains, but they started so much higher and still have a lot of work to do.

Re:Not a useful comparison (yet)

[amicusNYCL]

That may be true, I haven't looked at IE9 numbers in a while and I don't yet have a machine that can run it.

Re:Not a useful comparison (yet)

[cbhacking]

It's also worth considering that both Chrome (via WebKit) and Firefox have come from even older beginnings. Konqueror, and KHTML, is probably not as old as Netscape and Gecko, but neither modern browser (Firefox or Chrome) is using an engine that was created from scratch.

Re:Not a useful comparison (yet)

[lpq]

Comparing Mozilla resources to Chrome? Why not compare them to IE? Makes as much sense.

IE and Chrome are corporate browsers owned and developed by large corporations.

Konquerer, Firefox and Opera are not.

Re:Not a useful comparison (yet)

[Anonymous Coward]

Firefox is a monster now. I can't even fathom why I would want to use it, unless I felt like watching my memory usage skyrocket. I've kept it around for the occasional site that doesn't suport Chrome or Safari, but lately I've found myself just falling back on IE instead. At least IE doesn't have the memory leaks of Firefox.

Let's test your memory usage theory. I have three browsers on 64 bit Linux, running all without extensions or plugins. I've opened two tabs in each of the browsers - one tab on http://slashdot.org, the other on http://arstechnica.com. Memory usage:

Opera 10.60 - 111.8
Google Chrome 6.0.472.33 beta - 85.7
Firefox 4.0b4pre - 76.9

Huh. Firefox uses the least memory. Maybe your alleged memory usage and memory leaks come from extensions or plugins.

Re:Not a useful comparison (yet)

[uvajed_ekil]

Also, Opera is faster than Mozilla as well, I'd like to see it included on that chart to compare with the others. Maybe even IE9, if it doesn't skew the Y-scale too much.

I'm beginning to think all this talk about which browser is faster,and by how much, is really kind of pointless. I'm not a gamer and don't use bleeding-edge hardware, though I retired my 386sx before ever venturing onto the internet, and since Firefox was first released, I've never thought it was too slow. Maybe some of the others are faster, but Firefox is plenty fast enough for me on Windows and linux. I've tried lots of other browsers but never been amazed by the speed (or lack of speed) of any of them. This seems kind of like 0-60mph times for cars these days - a Corvette Z06 is a good deal quicker than say, a V6 Accord, but the Accord will never be too slow to merge onto the highway or get you into trouble with the fuzz. Maybe that's a bad analogy - swap out the grocery-getter for a non-M BMW 3-series or RX-8, or something else fun.

Re:Not a useful comparison (yet)

[arkhan_jg]

At the bottom of the fine article is a link to a previous benchmark they ran between opera 10.6, chrome 5, chromium 6, and firefox 4 beta 1.

In the sun spider test, Chromium 6 is fastest, opera second, and firefox 4 last - but the difference is fairly narrow, apart from firefox which is heavily beaten.

In the V8 test, chromium 6 beats all, and chrome 5 edges out opera. Firefox 4 again is beaten heavily.

Yes, jaegermonkey will make a big difference to mozilla performance - but given the rate chrome 6 is better than chrome 5 (and 6 was recently promoted to beta) it does seem likely that google will continue to outperform mozilla, even when jaegermonkey comes out.

Of course, this is rather the point of chrome - google uses AJAX heavily in its services (gmail, google docs, google apps etc etc) and if it wants to win at shifting the desktop away from local apps and into SaaS aka the cloud, then it needs a browser that can do that as fast as possible. Mozilla has a much broader set of goals - and of course a lot of legacy code to deal with.

Re:Not a useful comparison (yet)

[Anonymous Coward]

Does the mozilla js engine compile to native code like the Chome js engine does yet or does it still execute via a byte-code interpreter ?

Re:Not a useful comparison (yet)

[tenco]

It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.

And yet Chrome (or to be more precise, webkit) still doesn't support MathML. No wonder Chrome seems to develop faster if it's support for W3C standards is narrowed down. Plus, Chrome doesn't maintain it's very own rendering engine but uses one that's supported by at least one other major browser vendors.

Re:Not a useful comparison (yet)

[amicusNYCL]

Maybe your alleged memory usage and memory leaks come from extensions or plugins.

That doesn't really matter though if you only use Firefox because of the extensions. The only reason I run Firefox is so that I can use Firebug when I'm developing. If I see it taking up 800MB of memory, it doesn't really matter to me whether that's Firefox, or Firebug, or an issue in the Firefox extension architecture, etc. The leak is still there, it's not going to get fixed by everyone blaming someone else.

Re:Not a useful comparison (yet)

[amicusNYCL]

That depends on your definition of "large company", but I would agree with that. Opera is developed by a company which exists almost exclusively to develop that browser, so they may have an advantage also. They might not have a lot of resources, but all of them are devoted to one thing. It looks like they have around 750 employees, but I would imagine several of those are involved in sales and administration.

Re:Not a useful comparison (yet)

[amicusNYCL]

I can understand that, speed doesn't matter for most people. I'm looking from a web developer's point of view, where some of the stuff I'm involved in really is so complex that it's possible to see some pretty big differences in speed. The most dramatic example would be comparing Opera 10.6 or the latest Chrome build to IE6, there are several orders of magnitude in Javascript execution speed between IE6 and the current state of the art.

But even then, the web sites that a normal person would visit aren't going to perform much differently, you would need to use a big application like Gmail or Google Maps to see much of a difference.

Re:Not a useful comparison (yet)

[amicusNYCL]

Indeed, all of these contribute to why Google is able to develop their browser at a quicker pace than the competition.

google chrome

[Anonymous Coward]

Why not use google's javascript engine. Isn't it the fastest? Open source too...

Re:google chrome

[larry bagina]

v8 only runs on ARM and x86.

Re:google chrome

[tepples]

v8 only runs on ARM and x86.

That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?

Re:google chrome

[kripkenstein]

v8 only runs on ARM and x86.

That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?

x86_64 :P

Re:google chrome

[david.given]

Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?

TV set-top boxes are traditionally MIPS. Lots of them have web browsers in them these days (albeit limited, crappy ones).

Re:google chrome

[larry bagina]

debian has konqueror packages for:

• alpha
• amd64
• arm/armel
• hppa
• i386
• ia64
• mips/mipsel
• powerpc
• s390
• sparc

sid also had an unofficial m68k port.

Every one is still in use and all but alpha are still manufactured.

Re:google chrome

[cbhacking]

Why not use google's javascript engine. Isn't it the fastest? Open source too...

Actually, it looks like Opera is *still* faster than Chrome, even the nightly builds. Consider the data on this page (last updated a week or so ago). Yes, it's focused on IE9, but MS has no reason at all to try and make Opera look better than it is. http://ie.microsoft.com/testdrive/benchmarks/SunSpider/Default.html

Re:google chrome

[Anonymous Coward]

That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?

Toshiba's REGZA 55X1 TV uses a Cell processor and has an Opera based browser.

Re:google chrome

[cbhacking]

You jest, but this is a decent point; while the thought of a web-app that can use more than 4GB of RAM at once is frightening, it's not terribly unlikely that browsers will start moving to x64 in the next few years. IE is already available in both architectures, and I think Firefox is too. Konqueror definitely is. Not sure about Safari or Chrome, and I don't think Opera is. Nonetheless, 64-bit is the direction of the future.

Speaking of which, there are still Itaniums out there being sold and used. Admittedly they're being sold and used for servers, which really ought not run a web browser if they can help it, but IE, most likely Konqueror, and probably Firefox (and probably at least a few other browsers) all have Itanium ports.

Re:google chrome

[Bj�rn]

I think Firefox is too

This reply is posted with a x64 version of a nightly Firefox 4.0 (pre-b4) build.

Re:What the frak is Konqueror?

[jonbryce]

It is the default browser in KDE, unless your distro changed it to Firefox. If you use Gnome, or OSX or Windows, you probably won't get to see it.

Re:What the frak is Konqueror?

[Anonymous Coward]

it is the predecessor of webkit. webkit was forked from konquerors html rendering engine.

So the real question is

[dlenmn]

Is work continuing on KHTML, and -- if so -- why? I mean, KHTML surely has some stuff going for it (it was the basis for WebKit), but it seems like there's a really clear winner.

Re:So the real question is

[Anonymous Coward]

It's not your baby. You wouldn't understand.

Re:So the real question is

[icebike]

The speed changes in webkit are being backported to KHTML.

As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison on you.

Re:So the real question is

[Cley Faye]

This might be an explanation : http://geekandpoke.typepad.com/geekandpoke/2010/08/simply-explained-dead-code.html

Re:So the real question is

[dlenmn]

The speed changes in webkit are being backported to KHTML.

Is that the actual plan? At one time, I thought the plan was an "unforking".

As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison on you.

Oracle is wielding patents. If Apple decided to do that, then it wont make any difference if these are two projects or one.

Re:So the real question is

[Anonymous Coward]

How many developers are working on both projects? Does KHTML even have a chance of catching up to WebKit, or is it being forced to constantly reinvent everything?

Re:So the real question is

[Ilgaz]

KHTML may live on (!) as System HTML renderer, help renderer, whatever renderer and for people who chooses stability/robustness over "web 2.0" things like most insane javascript performance ever!

Not just that, Webkit stuff comes to KHTML too. They could be just a bit conservative since they have a OS (yea, minus drivers and kernel) which runs happily on 3 different architectures which has nothing to do with each other.

You wouldn't want Konqueror to crash while you move critical files around with it, you know there is no cool "plugin dead, disabled" dialogue in that case :)

Funny that Webkit is kinda sponsored by "us", Apple users and yet we understand the importance of a stable, standards compliant, low memory using and dependable light html renderer.

Re:So the real question is

[sombragris]

Is work continuing on KHTML...?

It seems so. Check this.

Re:So the real question is

[commodore64_love]

So what is Konquerer? I've never even heard of it, and I've tried a lot of different browsers including text-only and "low memory" browsers.

(searches wikipeida) - "Konqueror came with the version 2 of KDE, released on October 23, 2000. It replaces its predecessor, KFM (KDE file manager). With the release of KDE4, Konqueror was replaced as a file manager by Dolphin..... The name "Konqueror" is a reference to the two primary competitors at the time of the browser's first release: "first comes the Navigator, then Explorer, and then the Konqueror."

Re:So the real question is

[Ant P.]

Konqueror was a faster and more HTML/CSS standards compliant browser than Firefox, at least until Firefox 3.0 came out. It doesn't have the enormous mountain of resources Mozilla, Google and Apple do so it's been left behind since then.

Re:So the real question is

[xant]

I wouldn't have bothered with KHTML, even if WebKit being Ellison'd was not only possible but imminent.

The alternate to WebKit is WebKit, forked.

Re:So the real question is

[Golddess]

I'm curious, why did you feel the need to ask that question again when it was already answered the first time?

And yes, I checked the time stamps.
Question asked: Saturday August 14, @04:41PM
Question answered: Saturday August 14, @04:53PM (a mere 12 minutes later)
Question re-asked: Sunday August 15, @11:23AM

Re:So the real question is

[Golddess]

You're wasting your breath. They asked the same question yesterday, and apparently ignored everyone's responses.

Re:What the frak is Konqueror?

[sznupi]

It's what spawned Webkit; which in turn is the most mature modern browser engine available on current Amigas, you know...

So yesterday.

[Anonymous Coward]

Firefox 4 Beta 2 is so yesterday, today Firefox 4 Beta 3 is all the rage.

Re:So yesterday.

[supersloshy]

Firefox 4 Beta 2 is so yesterday, today Firefox 4 Beta 3 is all the rage.

True: 4b2 is outdated. 4b3 is much more recent. And who modded him as funny? This is informative.

Re:So yesterday.

[Anonymous Coward]

Firefox 4 Beta 2 was released on Tuesday. Firefox 4 Beta 3 was released on Friday. That's why it's funny. Beta 2 was so shitty and full of bugs that they had to release Beta 3 that quickly just to bring it to a level where even basic beta testing could begin.

Re:What the frak is Konqueror?

[icebike]

Yes its come full circle.

Kong (KHTML) was ripped off by Apple, and they began the work on webkit as a closed source project. After some serious (legal) prodding, Apple finally did the right thing and returned their changes to the community. Everybody is all friendly again, but some have long memories.

Now webkit has taken on a life if its own, and is the heart of many fast browsers, and is a plug in replacement for Kong's own engine.

I wish Google Chrome was also part of the test. It seems faster than any of the others.

So you get fast JavaScript, but NO JAVA

[xiando]

It must be noted that the WebKit support in Konqueror is very limited in many ways, and this may matter more to many people than a JavaScript speedboost. It does NOT, for example, allow you to run Java applets. http://websvn.kde.org/*checkout*/trunk/KDE/kdelibs/kdewebkit/ISSUES

My personal opinion is that all other written-for-WebKit browsers are better choices compared to Konqueror+kpart for those who want a browser with WebKit rendering at this point.

Re:So you get fast JavaScript, but NO JAVA

[Anonymous Coward]

While you're at it, you might want to note that these are issues to be fixed, and Konqueror+webkit isn't exactly intended as release software. As far as lacking Java goes, I have it turned off already.

Re:So you get fast JavaScript, but NO JAVA

[Enderandrew]

Honestly, I don't know why they put so much effort into maintaining Konqueror instead of helping to get rekonq up to speed.

http://rekonq.sourceforge.net/

Re:So you get fast JavaScript, but NO JAVA

[CRCulver]

It does NOT, for example, allow you to run Java applets.

Oh noes! Does it at least support the Gopher protocol and the <blink> tag?

Re:So you get fast JavaScript, but NO JAVA

[Anonymous Coward]

I've had it uninstalled for 3 years. Who the fuck uses Java applets anymore, apart from outdated corporate intranets?

Re:So you get fast JavaScript, but NO JAVA

[haruchai]

A little patience, please.

If you check the entries on the page that you're linking to, you'll find this - https://bugs.webkit.org/show_bug.cgi?id=33044
On that page, there are already some patches that have been submitted, although not yet reviewed and developer resources have been allocated
to having a deeper look at the issue of getting Java applet support working.

Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.

Re:So you get fast JavaScript, but NO JAVA

[rrohbeck]

What, nobody has written a Java VM is JavaScript yet?

Re:So you get fast JavaScript, but NO JAVA

[the_womble]

ReKonq is just a browser.

Konqueror is an extremely flexible browser, file manger and document reader. It can browser remote file systems over ftp or ssh (OK, lots of file managers can do that, but not all). You can spilt views arbitrarily - so a vertical split can emulate an old-fashioned FTP app, but you can split within those views as well.

Re:So you get fast JavaScript, but NO JAVA

[Enderandrew]

Yes, but in KDE 4 Okular is now the default document reader and Dolphin is now the default file manager.

It wouldn't be unprecedented for them to replace the default web browser with a better browser.

Even Konquerer developers have admitted the interface is less than optimal because it tries to be all things to all people.

Re:So you get fast JavaScript, but NO JAVA

[RichiH]

> Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.

Webkit has been "in" since KDE 4.3 or 4.4. I have been submitting bug reports like crazy and things have become a lot better. Yet, in 4.4.5 the Webkit Kpart degraded so badly that I had to stop using it altogether to stop Konqui Segfaulting after mere seconds of use.

The people who think they like Webkit will find out what the seperate thread for Flash in KTHML is worth. A _lot_.

I hope that by the time 4.6 comes around more people than just me report bugs and that Webkit gets the features it lacks when compared to KHTML.

As an aside, I think Webkit will be better in the long run. But it _definetely_ can not fully replace KHTML, just yet.

Re: How important are JavaScript times? zero?

[xiando]

How important are JavaScript times to the overall speed of rendering pages?

Try (ab)using Konqueror/KHTML as your primary/only browser for a month and you will soon get frustrated by simple things like the What You See Is What You Get on your blog software not working.

I personally do not give a damn about JavaScript performance. It matters zero to me. JS runs "fast enough" in all browsers.

It does matter a whole lot to me that the JavaScript on sites runs as expected.

I do not care if a piece of JavaScript does not work slow or fast.

Re:What the frak is Konqueror?

[Anonymous Coward]

Konqueror is actually a container that is used to display various kioslaves, of which one is khtml, the predecessor of webkit. Now apparently the webkit ioslave is ready to use.

Re:What the frak is Konqueror?

[TheRaven64]

Everybody is all friendly again, but some have long memories

And some have very faulty memories:

Kong (KHTML) was ripped off by Apple,

KHTML was forked by Apple.

and they began the work on webkit as a closed source project

They worked on it internally, more-or-less secretly until the first version of Safari, when they released their code at the same time they shipped the binaries.

After some serious (legal) prodding,

After a number of KHTML developers bitched publicly.

Apple finally did the right thing and returned their changes to the community

Apple moved development into public svn rather than providing large (and difficult to merge) patch drops with each release. They also began soliciting external contributions from companies like Nokia, Adobe, and so on, as well as from the wider community.

Comparing performance against Beta Software?

[Anonymous Coward]

You ran a performance test against a full blown Beta version of Firefox? What for? You should have gone up against the fastest production browser on the market which is Google Chrome.

Re:Comparing performance against Beta Software?

[Anonymous Coward]

You should have gone up against the fastest production browser on the market which is Google Chrome.

Is it? Then why is Chrome 5 slower than Safari 5 on OS X? Additionally, why is Chrome 6 slower than three other browsers on Windows?

Re:What the frak is Konqueror?

[theaveng]

People think you're joking but here's what wikipedia says:

"There is also a project synchronized with WebKit (sponsored by Pleyo) called Origyn Web Browser, which provides a meta-port to an abstract platform with the aim of making porting to embedded or lightweight systems quicker and easier.[37] This port is used for embedded devices such as set-top boxes, PMP and it has been ported into AmigaOS 4.1 for PowerPC, AmigaOS 3.9 for Classic 68000 machines, AROS and MorphOS."

Why Fx 4 beta 2?

[Anonymous Coward]

If beta 3 has been out for about a week?

From the release notes:
> JavaScript speed improvements due to engine optimizations.
> More responsive page rendering using lazy frame construction.
> Link history lookup is done asynchronously to provide better responsiveness during pageload.

Re:Why Fx 4 beta 2?

[Anonymous Coward]

Obviously because it wouldn't make their stuff look as good
same reason they didn't bench chromium

same reason it has been submitted to every news site cuz it looks like bad press for firefox which makes view which makes advert moneys. basics.

Re:Why Fx 4 beta 2?

[Shimbo]

If beta 3 has been out for about a week?

It wasn't. Beta 3 was released on the 11th, the article was published on the 12th.

Re:What the frak is Konqueror?

[sznupi]

Well, it was mostly just @GP & his sig; apparently still a bit into Amiga, and haven't heard about the browser which, ultimately, some time ago gave that platform (or rather a group of them) a modern browsing experience?

Results for Firefox3.6,Chromium,Opera Ubuntu

[rHBa]

Sunspider Test

Firefox-3.5.9-Linux: 2331.6ms

Opera-10.61-Linux: 868.2ms

Chromium-6.0.492.0-Linux: 865.6ms

I would have posted links to the results but apparently there were too many non-letter characters per line (even with the links inside href attribs).

Re:Results for Firefox3.6,Chromium,Opera Ubuntu

[rHBa]

Oops, FF 3.6 is on my other partition:

Firefox-3.6.8-Linux: 1815.0ms

Re:Results for Firefox3.6,Chromium,Opera Ubuntu

[robinvanleeuwen]

Chromium 6.0.491.0 (55657) Ubuntu 10.04: 541.8 ms

Re:Results for Firefox3.6,Chromium,Opera Ubuntu

[t0y]

Recent firefox progress in my machine:
- Firefox 3.6: 1063.0ms +/- 4.9%
- Firefox 4.0b4pre (today's build): 622.6ms +/- 12.0%

These are with the same engine, btw. Jaegermonkey is not in nightly builds yet.
It doesn't take much more to make you bound to DOM operations in normal webapps.

PS: sunspider 0.9.1 is also available

CSS table layout

[tepples]

Even pdftex, which produces nicer output than most browsers and runs incredibly slowly can do about ten pages a second of text-and-image layout and a web browser only needs to finish laying out one screen full quickly - anything off the screen just needs to be finished before the user scrolls that far down the page.

Not always. The layout of an element further down the page can have effects higher up the page. Think of a multiple-screen-tall element using CSS display: table with inner elements using display: table-row and display: table-cell. This can be either a <div> element using a grid layout or an actual <table>; the effect is the same.

the times

[ciaran_o_riordan]

HTML ... a 200k+ behemoth.

Careful gramps, your age is showing. The page your currently is 131k - a little short of what you call a behemoth. Maybe you'd call it a Hydra, or at least an ogre's big brother.

Re:What the frak is Konqueror?

[Elektroschock]

You mean KDE 4.5. will not be provided for these platforms? Wasn't there a porting project?

Re:What the frak is Konqueror?

[Elektroschock]

Wow! A single informative sentence.

Indeed that is the issue and we are happy that KDE 4.5 is out.

Progress not so fast

[dlenmn]

A little patience, please... Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.

A WebKit kpart is not new; there's been one for some time -- I made a package of it in October '09 because the one in the kubuntu repositories was out of date, so it must have been around for some time before that. Many things didn't work back then. For example it didn't integrate with KDE's password saving system. It looks like that's related to the fourth bullet on the list xiando posted -- so that _still_ may not be fixed.

Don't get me wrong, I'm glad to see that they're making progress. However, this has been a long time in coming, and I wouldn't be surprised if these problems last past years end. I got tired of waiting and moved to Chrome some time ago.

Re:Progress not so fast

[haruchai]

I've long been disappointed with Konq not moving more quickly to Webkit but I think this is a tipping point for them.
Especially now since KDE 4 has matured.

Re:What the frak is Konqueror?

[cbhacking]

KDE 4.x already available on Windows, and probably on OS X as well (never tried). The first ports of Konqueror were pretty weak, but these days it works nicely enough. I wouldn't call it a must-have program on Windows, but if you like the KDE apps (ark, kate, and amorak are some others that I like) then you can get them from http://windows.kde.org/ (it includes a package manager for updating, which is really nice). It looks like the current version is KDE 4.4.0.

Furthermore

[Anonymous Coward]

Someone set us up the bomb.

Re:What the frak is Konqueror?

[bonch]

Your post is full of falsehoods. KHTML wasn't "ripped off." It is LGPL-licensed code and was forked. Apple was always compliant with the LGPL and was not influenced by "serious legal prodding" to open source WebKit. WebCore and JavaScriptScore were always open source. WebKit is the layer of rendering frameworks wrapping WebCore and JavaScriptCore that initially provided Objective-C APIs and, later on, cross-platform C++ APIs for utilizing WebCore in the platform's native environment (e.g., rendering a webpage in a native window). WebKit was made available in a public CVS in the spirit of cooperating with KHTML developers and the rest of the open source community.

Really?

[yoyhed]

People still use Konqueror? Even if I was running Linux, I'd be using Chrome, or Firefox, or Opera..

Re:Really?

[uvajed_ekil]

People still use Konqueror? Even if I was running Linux, I'd be using Chrome, or Firefox, or Opera..

No, I think you have been misinformed. No one is still using Konqueror because no one ever used it in the first place. A lot of us linux users prefer Gnome to KDE, and even a ton of us who use KDE insist on something more "mainstream," like Firefox, Chrome or Opera, which are all better options, in my opinion. Konqueror's overall penetration of the web browser market is probably negligible, as its influence on the competition.

Java applets have uses

[Ilgaz]

Well, that joke will eventually hit +5 funny but, let me tell what happened today.

Was in market for a end user VPN account, you know they really depend on your IP to their IP speed/path. The largest and known/old VPN provider for such use has made all speed tests in Java. As I was testing something on OS X 10.4.11 Tiger (read as: OLD) and Apple stopped updating Tiger long time ago, along with security updates, I don't dare to enable "applets".

So until the gcc451 test was finished, I was prisoned on that partition.

This is exactly why people want the possibility of having flash/java applet and even shockwave on their browser. Not because they love 3rd party stuff, because a page out there may feature them and that page could matter to you.

I love watching people attack Larry Ellison/Oracle and Java in same context instead of questioning the "cool" guys like Apple and Google.

Re:What the frak is Konqueror?

[commodore64_love]

I actually don't use any Commodore more advanced than Amiga 500 (for classic gaming), and the only browser it can run is the ancient Mosaic 2.0 - precursor to Netscape. So I would never have heard of the Webkit Origyn variant, which probably needs 68020 to work.

I switched to Mac Quadra rather than stick with the Amiga line.
Then I bought a Windows 98 machine, and my soul died a little.

NASCAR

[uvajed_ekil]

Konquerer is sort of like a NASAR Sprint Cup car - fast, but not the best tool for most jobs, and more of a novelty than something I'd want to drive every day. Some people love each of this things, and I think most of these people are silly, uneducated, and love to ignore the real world.

this just in:

[crazybilly]

Webkit is faster than Firefox but Konqueror still crashes 2 out of 5 times when encountering streaming (Flash) video.

Re:this just in:

[evJeremy]

Curious. By my count, using KDE 4.4.5 on Debian Squeeze, it's about 0 out of a few hundred times. Which distro are you using?

Re:What the frak is Konqueror?

[Runaway1956]

I'll bet you haven't tried Midori browser either, then. twotoasts.de In my own informal testing (read, not disciplined in any manner, just diddling around) Midori was the FIRST browser to score 100 on the Acid3 test, and it's also the fastest GUI browser.

It's not my browser of choice, for two reasons - 1, it does break from time to time and 2, it lacks the customizations of Firefox. Also, Midori doesn't seem to be real happy on a system with any other Webkit engine installed.

Still - you should look at Midori, and drive it around a little.

Re:Firefox? What's that?

[uvajed_ekil]

Firefox??? ooooh yeah, I remember now. I thought it went the way of Netscape, didn't know people actually still used it today.

OMG, yer so funny! Or you would be, if Firefox didn't have the biggest share of the browswer market aside from M$ IE, 23%-35%, depending on who you believe. That's quite a bit more than Chrome, Safari, Opera and Konqueror combined. And Firefox has increased its market share every calendar year since it came out, perhaps with the exception of this year. But yeah,no one uses it, lol.

Re:Firefox? What's that?

[uvajed_ekil]

I almost forgot, here's a graph of Internet Explorer's market share since 2005:
\

And Firefox market share since 2005:
/

(Note that the trends are correct, though not to scale.)

Re:What the frak is Konqueror?

[uvajed_ekil]

It is the default browser in KDE, unless your distro changed it to Firefox. If you use Gnome, or OSX or Windows, you probably won't get to see it.

Hmm, I already knew about Konqueror, but thanks for your second sentence - I now finally see one advantage to using Windows!

Re:What the frak is Konqueror?

[oiron]

And the rest of the story is that Webkit went on to become the fastest library on the planet, adopted into pretty much every toolkit and platform currently known to man (scroll down to "webkit ports"), including Chrome and Android.

The whole thing started because the KDE guys didn't want to use Gecko in 1998

Re:What the frak is Konqueror?

[smash]

Exactly. Apple have a pretty good track record when it comes to releasing things. Zeroconf, OpenCL, CLANG, grand central, etc.

Agreed on this quote from you

[Anonymous Coward]

"It's looking towards the future. HTML 5 is designed to replace Flash, but it can't do it if Javascript is slow. Performance is going to be an important differentiator in browsers, for how well they are able to run web apps " - by phantomfive (622387) on Saturday August 14, @04:48PM (#33252594)

PERTINENT QUOTE EXCERPT FROM ARTICLE CONCLUSIONS:

"We are not saying Konqueror is a better browser than Firefox; we are only saying it is faster. If you check out the results we got in our previous tests, Konqueror (WebKit) is however not nearly as fast as Opera, Google Chrome and Chromium."

Nuff said/Says it all for me...

APK

P.S.=> Big "OPERA FANBOY" here, even though I like FireFox too, Opera's a HELL OF A LOT FASTER in most things (not just javascript but general HTML parse & process work too) & that's been a long established fact in this industry which is how Opera's "gets away" with stating the're "the fastest webbrowser on the planet" I suppose. Chrome's been impressive the past 1-2 yrs. now as well, but it's still not Opera (even with GOOGLE monetary muscle & talent behind it) so far, but it's "getting there" slowly but surely to be on par @ LEAST.

However, MY MAIN POINT IN CONCLUSION HERE? Well, I'm on vacation in Europe, and I have a laptop with me (ASUS AMD ATHLON X2 4200 CPU based w/ 4gb RAM onboard). While I was in London, Berlin, & Madrid, I put on PC-BSD 8.1 on it to try it out (it has a default KDE desktop is why, because I prefer KDE to GNOME). BSD based Os' so far imo @ least seem faster on disk/filesystem I-O oriented tasks vs. Linux.

However/by way of comparison: While I was in Warsaw, St. Petersburg, & Prague it's been KUbuntu 10.4x (both OS' "latest/greatest" in other words, & both use KDE by default as their desktop over the window manager).

As far as useability? Well - I found both have FINALLY become good enough for daily use and function imo at last (first time I used LINUX was Slackware 1.02 in 1994 iirc, which stunk (especially for vidcard drivers back then, as I was stuck in char mode/tty terms mode only (good for *NIX commandline shell practice only really)))... I later tried REDHAT 5.0, & FEDORA around 5++ yrs. ago again, it was "still not there" but today?? Like I said above - pretty damned good (not perfect, but not as 'far short' of Windows as it was before, now it's only mostly on the gaming front only).

As far as performance overall?? Linux seems faster than BSD oriented OS' in the GUI processing I/O arena (whereas I felt that BSD was faster on disk oriented work as I noted above). Yes... Pretty much a "draw" so far overall though imo, PC-BSD vs. KUbuntu Linux (both using KDE desktops).

My point though on THIS particular topic (KONQUEROR)? I noted it (Konqueror webbrowser) was a HELL OF A LOT FASTER than what I recalled from the older Linux distros I tried (not counting Gnome on FEDORA recently as well which I gave a shot to prior to this vacation also) and this article only bears that out for me basically...

So, kudos the the KDE & Konqueror dev teams, from me (the "ultimate Windows fanboy of /." pretty much in myself), as well as the designers of the WebKit engine too... apk

LAKE APPLET

[drx]

Snow Applet is also very good.

Break room PC

[tepples]

If you're running a system that you're not an administrator on (i.e., a corporate desktop), chances are the web application you run would be an enterprise app that requires a username/password too.

Break room PCs at work: the employee has permission to visit any safe-for-work web site but not to install software. Children's accounts on family PCs and guest accounts on public library PCs are under similar restrictions.

Re:Break room PC

[bonch]

Your justification for web apps is break room and library PCs?

Re:Break room PC

[tepples]

Your justification for web apps is break room and library PCs?

That's one. Another is that it's easier to start a web app than to go through the installation and uninstallation process for a native app, as Compaqt explained.

Re:Break room PC

[bonch]

Again, that's really your entire justification for avoiding native APIs?

Re:Break room PC

[tepples]

It is substantially more difficult for an end user to begin using an application that uses native APIs than for an end user to begin using an application that uses only HTML DOM APIs. For example, compare the effort it takes to begin using Google Maps to the effort it takes to begin using Google Earth. What more justification do you need?

Re:Break room PC

[bonch]

You don't offer a single example beyond Google Earth of how it's "substantially more difficult" to use a native application instead of a web application. Give me a break.

The opposite is true. Web apps are slower, break the Back button, and are vastly more limited in functionality. There is no HIG for web applications, so they all re-implement things differently, look differently, behave differently, and use different hotkeys.

Re:Break room PC

[tepples]

You don't offer a single example beyond Google Earth of how it's "substantially more difficult" to use a native application instead of a web application.

Flash games vs. downloadable games.

And to a lot of users, using applications that "re-implement things differently, look differently, behave differently, and use different hotkeys" is more fun than staring at "You are not authorized to install programs on this computer" or getting scared by "Are you sure you want to install this program? Programs downloaded from the Internet can be dangerous".

Re:Break room PC

[bonch]

So your entire argument for abandoning native APIs is Flash games?

You cite zero evidence that users find contradictory interfaces "more fun," and your disdain for security prompts is bizarre since web apps that access personal information or require a secure connection do the same thing.

Re:Break room PC

[Anonymous Coward]

So your entire argument for abandoning native APIs is Flash games?

I like how you combined a strawman argument with begging the question. What should we call that? Begging the Strawman?

Re:Break room PC

[tepples]

If I asked you to download and install a Windows program to read my reply to your comment, would you?

Re:Break room PC

[bonch]

Tepples, no need to post anonymously.

The only concrete examples for your argument that you've offered up to this point are Flash games. Flash games aren't a good reason to abandon decades of work in fast, native APIs.

Re:Break room PC

[bonch]

No. What's your point?

Re:Break room PC

[Anonymous Coward]

I like how you modded down an old comment using the Overrated modifier so it won't get meta-modded, and then you posted anonymously while missing the point. Typical Slashbot.

Re:Break room PC

[tepples]

Exactly. If people see that they have to install something in order to use your product, but they don't have to install something in order to use your competitor's product, people will flock to your competitor.

Re:Break room PC

[bonch]

It's your hypothetical conclusion that people will "flock" to something just because there's not an installer. In truth, people will use what is fastest, most stable, and more importantly, most familiar. You claimed that people prefer contradictory interfaces, which proves that your argument is really on shaky foundations. To think that we should drop standard APIs in favor of the anything-goes web just because there isn't an installer--never mind that Macs and .NET support drag-and-drop installs anyway--is pretty ridiculous.

People have to install apps on the iPhone, yet apps have taken off compared to web solutions running in Mobile Safari. Native APIs have the usability advantage that people prefer.

Re:Break room PC

[tepples]

In truth, people will use what is fastest

For an app that you don't think you'll use but once, it's faster not having to install an application and possibly even restart the computer. Otherwise, why would people be playing FarmVille instead of buying and installing a copy of a game like Harvest Moon?

You claimed that people prefer contradictory interfaces

...to interfaces blocked by the security policy. For someone who primarily uses his own laptop, I admit that it isn't much of a problem.

never mind that Macs and .NET support drag-and-drop installs anyway

It's also possible to make a Windows app that can be drag-and-drop installed, provided your administrator doesn't block them. But you still have to download the application, locate it in your file system, and "unblock" it (remove the tag as having been downloaded from the Internet) first. Besides, .NET also supports Silverlight, which doesn't even need an installer.

People have to install apps on the iPhone

There's also a centralized app store, which is somewhat less convenient than web apps in Safari but substantially more convenient than installing apps on Windows. As I understand it, it's easier to pay Apple $99 to set up the infrastructure to list your application among others, take $0.99 payments, and give you 30% than it would be to set up your own infrastructure to do the same for a Windows app.

Re:Break room PC

[Anonymous Coward]

Tepples, no need to post anonymously.

I'm not Tepples, and you don't really think I am either. You're lying about that just as you are lying about what his position is.

And those aren't the only things you insist on constantly lying about, either. Are they?

Re:What the frak is Konqueror?

[dfghjk]

excellent response

Re:What the frak is Konqueror?

[Elektroschock]

So there is no such release of KDE 4.5, even 4.4.0 is not the latest of the KDE 4.4 series. Last time I tried Okular was unable to open PDf files!

Google Chrome Frame

[tepples]

Most people are running accounts with installation capability.

I just thought of another thing: Then why do companies still author web sites to work around the deficiencies in Internet Explorer's Trident engine instead of relying on Google Chrome Frame? See what other people have to say about having to install an application to view something.