Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

WebKit Gives Konqueror a Speed Boost (Past Firefox)

timothy posted more than 4 years ago | from the fightin'-words-in-a-kit dept.

Firefox 199

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."

cancel ×

199 comments

Sorry! There are no comments related to the filter you selected.

Ash to Ash (-1, Offtopic)

netdur (816698) | more than 4 years ago | (#33252462)

meh

I Guess ... (5, Funny)

WrongSizeGlass (838941) | more than 4 years ago | (#33252470)

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 ... (5, Funny)

sznupi (719324) | more than 4 years ago | (#33252524)

"...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 ... (0)

Anonymous Coward | more than 4 years ago | (#33252644)

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 ... (0)

Anonymous Coward | more than 4 years ago | (#33252870)

WOW! What a great opportunity for a pizza analogy!

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

Re:I Guess ... (1, Funny)

Anonymous Coward | more than 4 years ago | (#33253432)

Also, oh God free software kills old ladies!

At least it finally stopped killing kittens and puppies.

WOW! (0)

Anonymous Coward | more than 4 years ago | (#33252476)

Faster than Firefox? HOLY SHIT!

Re:WOW! (0)

Anonymous Coward | more than 4 years ago | (#33253158)

Faster than Firefox? HOLY SHIT!

Hard to imagine, eh?

Fucking DUST 2 DUST man ! (0)

Anonymous Coward | more than 4 years ago | (#33252478)

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 (0)

Anonymous Coward | more than 4 years ago | (#33252482)

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 (2, Funny)

X0563511 (793323) | more than 4 years ago | (#33252782)

You need to getting laid.

What about Firefox Beta 3? (1, Informative)

Anonymous Coward | more than 4 years ago | (#33252488)

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

Re:What about Firefox Beta 3? (0)

Anonymous Coward | more than 4 years ago | (#33253102)

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 (0, Funny)

Anonymous Coward | more than 4 years ago | (#33252530)

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

How important are JavaScript times? (5, Interesting)

mickwd (196449) | more than 4 years ago | (#33252540)

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? (5, Insightful)

arose (644256) | more than 4 years ago | (#33252554)

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? (5, Funny)

tepples (727027) | more than 4 years ago | (#33252796)

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? (1)

turgid (580780) | more than 4 years ago | (#33252872)

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

Re:How important are JavaScript times? (3, Funny)

dingen (958134) | more than 4 years ago | (#33253280)

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? (-1, Troll)

CodeBuster (516420) | more than 4 years ago | (#33253224)

and applications should be written in native code, not JavaScript

Here's a nickle kid, get yourself a real programing language, something that supports strong types and is compiled, then come back and remind us why we should be NOT be writing our applications in JavaScript. The scripting languages have their uses, but they also have their limits; only an ignorant dev chooses the wrong tool for the wrong job.

Re:How important are JavaScript times? (2, Interesting)

jeremyp (130771) | more than 4 years ago | (#33253252)

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? (5, Insightful)

tepples (727027) | more than 4 years ago | (#33253424)

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? (1)

bonch (38532) | more than 4 years ago | (#33253904)

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? (1)

Gerard Ketuma (1876478) | more than 4 years ago | (#33252890)

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

Re:How important are JavaScript times? (1)

kamikaez (1202329) | more than 4 years ago | (#33253864)

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? (5, Insightful)

phantomfive (622387) | more than 4 years ago | (#33252594)

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? (1)

Frosty Piss (770223) | more than 4 years ago | (#33253716)

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? (5, Informative)

bjourne (1034822) | more than 4 years ago | (#33252702)

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? (4, Funny)

Anonymous Cowpat (788193) | more than 4 years ago | (#33252830)

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? (0)

Anonymous Coward | more than 4 years ago | (#33253726)

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

Furthermore (0)

Anonymous Coward | more than 4 years ago | (#33253996)

Someone set us up the bomb.

Re:How important are JavaScript times? (1, Troll)

fast turtle (1118037) | more than 4 years ago | (#33253458)

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? (2, Interesting)

X0563511 (793323) | more than 4 years ago | (#33252790)

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.

the times (1)

ciaran_o_riordan (662132) | more than 4 years ago | (#33253508)

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:How important are JavaScript times? (1)

TheRaven64 (641858) | more than 4 years ago | (#33252814)

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.

CSS table layout (2, Insightful)

tepples (727027) | more than 4 years ago | (#33253092)

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.

Re: How important are JavaScript times? zero? (2, Insightful)

xiando (770382) | more than 4 years ago | (#33252824)

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:How important are JavaScript times? (0)

Anonymous Coward | more than 4 years ago | (#33252960)

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? (-1, Troll)

Lars T. (470328) | more than 4 years ago | (#33253388)

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

Gee, why don't you try loading Slashdot on KHTML-Konqueror and tell us about it?

What the frak is Konqueror? (-1, Redundant)

commodore64_love (1445365) | more than 4 years ago | (#33252556)

I've never eve heard of it, and I've tried a lot of different browsers including text-only and "low memory" browsers.

"Konqueror came with the version 2 of KDE, released on October 23, 2000.[5] It replaces its predecessor, KFM (KDE file manager).[6] 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:What the frak is Konqueror? (4, Informative)

jonbryce (703250) | more than 4 years ago | (#33252626)

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? (1)

Elektroschock (659467) | more than 4 years ago | (#33253512)

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

Re:What the frak is Konqueror? (2, Informative)

cbhacking (979169) | more than 4 years ago | (#33253894)

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/ [kde.org] (it includes a package manager for updating, which is really nice). It looks like the current version is KDE 4.4.0.

Re:What the frak is Konqueror? (2, Insightful)

Anonymous Coward | more than 4 years ago | (#33252628)

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

Re:What the frak is Konqueror? (1, Informative)

icebike (68054) | more than 4 years ago | (#33252728)

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.

Re:What the frak is Konqueror? (4, Informative)

TheRaven64 (641858) | more than 4 years ago | (#33252844)

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.

Re:What the frak is Konqueror? (1)

bonch (38532) | more than 4 years ago | (#33254002)

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.

Re:What the frak is Konqueror? (-1, Troll)

Anonymous Coward | more than 4 years ago | (#33252636)

Konqueror is what puts the "k" into goatse [goatse.fr] .

Re:What the frak is Konqueror? (4, Funny)

sznupi (719324) | more than 4 years ago | (#33252670)

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

Re:What the frak is Konqueror? (1, Informative)

theaveng (1243528) | more than 4 years ago | (#33252916)

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."

Re:What the frak is Konqueror? (1)

sznupi (719324) | more than 4 years ago | (#33252944)

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?

Re:What the frak is Konqueror? (1, Informative)

Anonymous Coward | more than 4 years ago | (#33252826)

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? (1)

Elektroschock (659467) | more than 4 years ago | (#33253526)

Wow! A single informative sentence.

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

Not a useful comparison (yet) (0)

Anonymous Coward | more than 4 years ago | (#33252596)

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/ [arewefastyet.com] for charts of JaegerMonkey's progress and for a breakdown of each of the individual tests see http://arewefastyet.com/individual.php [arewefastyet.com] . The regress chart [arewefastyet.com] is interesting to see the performance gains to be had when TraceMonkey and JaegerMonkey are used in combination.

Re:Not a useful comparison (yet) (3, Insightful)

amicusNYCL (1538833) | more than 4 years ago | (#33252710)

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) (1, Informative)

Anonymous Coward | more than 4 years ago | (#33252762)

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 [arewefastyet.com] .

Re:Not a useful comparison (yet) (1)

amicusNYCL (1538833) | more than 4 years ago | (#33253226)

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) (0)

Anonymous Coward | more than 4 years ago | (#33253362)

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) (1)

amicusNYCL (1538833) | more than 4 years ago | (#33254042)

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) (0)

Anonymous Coward | more than 4 years ago | (#33252854)

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) (0)

Anonymous Coward | more than 4 years ago | (#33252858)

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 [youtube.com] instructive.

Re:Not a useful comparison (yet) (1)

amicusNYCL (1538833) | more than 4 years ago | (#33253272)

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) (0)

Anonymous Coward | more than 4 years ago | (#33253604)

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) (0)

Abcd1234 (188840) | more than 4 years ago | (#33252882)

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) (1)

amicusNYCL (1538833) | more than 4 years ago | (#33253210)

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) (2, Insightful)

Abcd1234 (188840) | more than 4 years ago | (#33253264)

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) (1)

amicusNYCL (1538833) | more than 4 years ago | (#33253336)

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) (1)

cbhacking (979169) | more than 4 years ago | (#33253974)

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) (1)

amicusNYCL (1538833) | more than 4 years ago | (#33254058)

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) (2, Informative)

Elektroschock (659467) | more than 4 years ago | (#33253546)

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) (1)

cbhacking (979169) | more than 4 years ago | (#33253938)

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 [microsoft.com]

google chrome (0)

Anonymous Coward | more than 4 years ago | (#33252608)

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

Re:google chrome (1)

larry bagina (561269) | more than 4 years ago | (#33252664)

v8 only runs on ARM and x86.

Re:google chrome (2, Insightful)

tepples (727027) | more than 4 years ago | (#33252788)

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 (2, Funny)

kripkenstein (913150) | more than 4 years ago | (#33253010)

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 (1)

david.given (6740) | more than 4 years ago | (#33253536)

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 (1)

larry bagina (561269) | more than 4 years ago | (#33253906)

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.

So the real question is (4, Interesting)

dlenmn (145080) | more than 4 years ago | (#33252652)

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 (0)

Anonymous Coward | more than 4 years ago | (#33252716)

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

Re:So the real question is (4, Informative)

icebike (68054) | more than 4 years ago | (#33252756)

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 [pcworld.com] on you.

Re:So the real question is (2, Insightful)

dlenmn (145080) | more than 4 years ago | (#33253418)

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" [arstechnica.com] .

As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison [pcworld.com] 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 (0)

Anonymous Coward | more than 4 years ago | (#33253488)

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?

So yesterday. (2, Funny)

Anonymous Coward | more than 4 years ago | (#33252696)

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

Re:So yesterday. (3, Funny)

supersloshy (1273442) | more than 4 years ago | (#33252776)

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. (1, Informative)

Anonymous Coward | more than 4 years ago | (#33252988)

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.

So you get fast JavaScript, but NO JAVA (3, Informative)

xiando (770382) | more than 4 years ago | (#33252786)

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 [kde.org]

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 (0)

Anonymous Coward | more than 4 years ago | (#33252908)

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 (0)

Anonymous Coward | more than 4 years ago | (#33253326)

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 (1)

Enderandrew (866215) | more than 4 years ago | (#33253020)

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/ [sourceforge.net]

Re:So you get fast JavaScript, but NO JAVA (4, Funny)

CRCulver (715279) | more than 4 years ago | (#33253212)

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 (2, Informative)

haruchai (17472) | more than 4 years ago | (#33253410)

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 [webkit.org]
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.

Progress not so fast (1)

dlenmn (145080) | more than 4 years ago | (#33253842)

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 [launchpad.net] 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.

Comparing performance against Beta Software? (0)

Anonymous Coward | more than 4 years ago | (#33252876)

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? (0)

Anonymous Coward | more than 4 years ago | (#33253810)

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 [youtube.com] on OS X? Additionally, why is Chrome 6 slower than three other browsers [youtube.com] on Windows?

Why Fx 4 beta 2? (0)

Anonymous Coward | more than 4 years ago | (#33252926)

If beta 3 has been out for about a week?

From the release notes [mozilla.com] :
> 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? (0)

Anonymous Coward | more than 4 years ago | (#33253480)

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.

Results for Firefox3.6,Chromium,Opera Ubuntu (2, Interesting)

rHBa (976986) | more than 4 years ago | (#33252968)

Sunspider Test [webkit.org]

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 (1)

rHBa (976986) | more than 4 years ago | (#33253078)

Oops, FF 3.6 is on my other partition:

Firefox-3.6.8-Linux: 1815.0ms

Re:Results for Firefox3.6,Chromium,Opera Ubuntu (1)

robinvanleeuwen (1009809) | more than 4 years ago | (#33253780)

Chromium 6.0.491.0 (55657) Ubuntu 10.04: 541.8 ms

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?