Slashdot Mirror

Stainless (multi-process browser) + WebKit Nightly frameworks (SquirrelFish Extreme) = a decent preview of Chrome on OS X

1. Copy: Stores selected text in client-side database or cookie
2. Paste: Pastes into text field in browser
3. Paste to Mail: Opens a URL to mailto:replace@this.com?body=$clipboardContents

Obviously this wouldn't work for copying from Mail to Safari, but I was kind of confused as to when that would come in handy anyway. The trade-off for security would be worth it, and if you really wanted to, you could still do a trip to a server for Mail-to-Safari copying.

I haven't delved into the bookmarklets yet, so maybe it's not possible for some reason, but does anyone know why they would choose to have it make a trip to the server when it seems like it could be pretty easily avoided?

Download WebKit nightly. Download Stainless. Set Stainless prefs to load WebKit nightly frameworks. Bingo: super fast, multi-processed browser you can use now.

You can download Webkit nightlies for Mac OS X and Windows here, and you do not have to be a developer to do so. They will come with the latest version availiable of the Safari shell, which is right now 3.2.1.

The problem is that I have yet to see an implementation through a browser that can challenge a native GUI implementation and yes this includes Sales Force, Google Mail, Google Docs and all the rest of them.

that's why i ported pyjamas to the desktop:

    http://pyjs.org/

pyjamas-desktop basically rips out all of the javascript, and replaces every single javascript-based function with exact same corresponding functionality that manipulates the DOM model of the underlying technology.

and i chose http://webkit.org/ as the DOM-manipulating technology.

i _could_ have chosen XUL / Gecko, but it took so damn long to find Hulahop - http://wiki.laptop.org/go/HulaHop - that i had to go for webkit.

i could have chosen PyKDE / KHTMLPart but it has very subtle bugs that require the entire KDE library to be compiled with c++ RTTI switched on. if it's switched off, the whole thing falls over.

by porting pyjamas to the desktop, it's possible to make the same application run as EITHER a desktop application (and i don't mean "running as javascript under Adobe AIR") OR a web application.

same source code. unmodified.

it's very cool.

Neither is WebKit, which Chrome uses to render pages.

http://trac.webkit.org/log/branches/Safari-3-2-branch shows it's a fork of the Saf 3.1 branch with selected patches.

WebKit ToT is nowhere near as stable as the Saf3.2 branch. It crashes a bit more, and there are a lot of regressions (of websites breaking). Currently, there are 225 P1 (priority 1, i.e., top priority) bugs. It's nowhere near shippable.

Not only that, but the animation has to render smoothly as well. The browser can be capable of passing, but fail because the hardware is old and slow. Anyway, you aren't going to get a 100 with 3.2, but that's why there's webkit nightlies. It's basically the latest version of Safari if you don't want to wait for Apple's official release.

I thought it was a perfect score. Not a almost perfect score.

What I really want is some screenshots of what the anti-phishing behavior looks like. For all this talk about Safari 3.2 no one has bothered to try out the new features.

Safari is based on Webkit, which can achieve an almost perfect acid3 score. Anyone using windows or macosx can easilly try it.

"It is surprising how different the versions of webkit are."

This is untrue, and mostly a product of misunderstanding but partly a product of FUD as well. More on this below...

"the current release of Chrome is almost 4 times faster than the current release of Safari"

This really has almost nothing to do with Webkit, and does not demonstrate a difference in the rendering engines at all. Ultimately what we're looking at here is a comparison of JavaScriptCore (Safari's current* ECMAScript interpreter)â"released 19 June 2008, with only minor changes from the major version from more than a year earlierâ"and V8 (Google's ECMAScript-bytecode translator engine)â"released 5 September 2008 against a codebase that was nearly brand new; while it's true that JSC is a [legacy] part of Webkit, V8 is not a part of Webkit at all. Comparing the two isn't really meaningful.

Moreover, Chrome is not released, it's a very, very early, unpolished beta.

A more apt comparison would be...

"It would be interesting to see if the Safari nightly builds have closed this gap." ... the nightly builds, which use a similar engine (SFX is somewhat different in its approach, but ultimately in the same class as V8). And in fact, performance is roughly the same. It's not like this information isn't widely available, either.

I can't speak to the particular benchmark in question or whether it even has merit as a general browser benchmark (note, Google's benchmark has little merit here, as it strictly tests JS language speed, rather than DOM performance [which is extremely important for nearly all browser performance experiences]), and I don't have an environment which would be suited to finding out for myself, but I encourage you if you're that curious to try a nightly build on the test yourself.

With that said, there are existing browser benchmarks (eg Dromaeo 2) that tell a story much more interesting story.

John Resig on JS engine performance
This shows JSC (not SF or SFX) beating V8 on a bunch of DOM tests

But I want to reiterate, this is hardly a good example of differences in Webkit releases. These are differences in browser releases and over a very wide stretch of time (in the current JS engine war, especially).

* By "current", I mean "released"; it is current in that sense, but actually two generations old in the Webkit project. The Webkit team has since produced SquirrelFish and SquirrelFish Extreme, the latter being much closer to (and often faster than) Chrome's performance on every task except (if I recall correctly) recursion.

"It is surprising how different the versions of webkit are."

This is untrue, and mostly a product of misunderstanding but partly a product of FUD as well. More on this below...

"the current release of Chrome is almost 4 times faster than the current release of Safari"

This really has almost nothing to do with Webkit, and does not demonstrate a difference in the rendering engines at all. Ultimately what we're looking at here is a comparison of JavaScriptCore (Safari's current* ECMAScript interpreter)â"released 19 June 2008, with only minor changes from the major version from more than a year earlierâ"and V8 (Google's ECMAScript-bytecode translator engine)â"released 5 September 2008 against a codebase that was nearly brand new; while it's true that JSC is a [legacy] part of Webkit, V8 is not a part of Webkit at all. Comparing the two isn't really meaningful.

Moreover, Chrome is not released, it's a very, very early, unpolished beta.

A more apt comparison would be...

"It would be interesting to see if the Safari nightly builds have closed this gap." ... the nightly builds, which use a similar engine (SFX is somewhat different in its approach, but ultimately in the same class as V8). And in fact, performance is roughly the same. It's not like this information isn't widely available, either.

I can't speak to the particular benchmark in question or whether it even has merit as a general browser benchmark (note, Google's benchmark has little merit here, as it strictly tests JS language speed, rather than DOM performance [which is extremely important for nearly all browser performance experiences]), and I don't have an environment which would be suited to finding out for myself, but I encourage you if you're that curious to try a nightly build on the test yourself.

With that said, there are existing browser benchmarks (eg Dromaeo 2) that tell a story much more interesting story.

John Resig on JS engine performance
This shows JSC (not SF or SFX) beating V8 on a bunch of DOM tests

But I want to reiterate, this is hardly a good example of differences in Webkit releases. These are differences in browser releases and over a very wide stretch of time (in the current JS engine war, especially).

* By "current", I mean "released"; it is current in that sense, but actually two generations old in the Webkit project. The Webkit team has since produced SquirrelFish and SquirrelFish Extreme, the latter being much closer to (and often faster than) Chrome's performance on every task except (if I recall correctly) recursion.

Wow, that's surprising but you are right. The webkit team has a list of all apps that use webkit and, indeed, iTunes is not one of them.

I'd be willing to bet that they use *some* form of html/xml renderer, but the decision to not use Webkit is curious. I wonder if they are afraid falling in the same trap that IE did, where exploits discovered in the renderer could be leveraged in other applications that use it (most notably Outlook).

Just to chime in with the other people here, I have two systems on my desk at work. One is a two year old Dell laptop with an Intel Core Due processor with 2GB of RAM. It runs XP. The other is a four year old Dell desktop with a Pentium 4 and 1GB of RAM. It runs Ubuntu 8.10.

Guess which one is much, much faster?

The Ubuntu 8.10 desktop, of course.

Part of it is due to all the corporate crap-ware that gets installed on the machine. There's the virus scanner, the software firewall, and the automatic patch system. (And Adobe's automatic patch system, and Apple's automatic patch system, and Google's automatic patch system, and Sun's automatic patch system...)

But a greater part is that Ubuntu is just plain faster. It uses less RAM, it hits the disk less, and it just runs faster.

My general routine at the start of a day is to start the XP laptop booting, boot up the Ubuntu desktop, and then play around with the Ubuntu desktop while I wait for Windows to finally get to the point where it can slowly get Outlook up and going.

Out of curiosity, I ran the SunSpider JavaScript benchmark under Firefox 3.0.3 on both systems. The Ubuntu system finished with a total of 4.4 seconds to run all tests. The XP machine finished in 11.4 seconds. The 95% confidence intervals for the XP machine seem to suggest that performance changed wildly on some test runs - presumably caused by random background activity.

It has one

If I'm not mistaken, Safari uses WebKit as its rendering engine just like Chrome does. This might account for any similarity in quirky behavior.

Link to nightly Webkit: http://nightly.webkit.org/

When people say "WebKit" in browser benchmarks (eg ACID3), they are typically referring to the WebKit nightly builds. Those amount to the latest released version of the Safari application (currently 3.1.2), but run using the nightly build of the WebKit libraries instead of the version that comes with the Safari app. As for Javascript tests such as SunSpider, those are typically run by invoking the Javascript interpreter directly from the command line, without using a full browser. So he's really comparing apples to apples and oranges to oranges.

SunSpider is a Java benchmark? (Hint: Java != Javascript.) CA (the acronym referring to certificate authorities as a generic term) is a link to a quote for (the unrelated) CA, Inc.?

Ah well... hopefully Firefox 3.1 is as fast as they say.

This is a strange way of putting it. Why not simply say, "IE: 107 seconds, Firefox: 3.9 seconds"??? I guess they thought more digits is sexier.

The sunspider benchmark outputs its results in ms not seconds so I expect they just copy/pasted.

Back when the U.S. and E.U. governments were suing Microsoft, and Microsoft was trying to defend why it was "impossible" to produce Windows 98 without Internet Exploder.

So the other guy said. I don't understand why they'd claim that in the anti-trust suit - it would show competitive advantage and weaken their position. Citation needed.

Apple embraces the open source community with the most locked down systems and electronics made by any vendor not working on a defense contract. That must be a tight embrace.

Really?

The safari javascript engine is called SquirrelFish (And there's also SquirrelFish Extreme, which compiles javascript into machine code, with predictable speed increases.) and it is open-source as it's part of webkit.

http://webkit.org/

``Also a real pity, i wonder if the so called improved javascript VM will actually ever make it in the real world... cause we REALLY REALLY need optimized javascript;''

Well, it seems several people are already working on that. From Mozilla, there is Tamarin. From Apple, there is SquirrelFish.

And here's a comparison of the performance of various JavaScript engines, including Tamarin, SquirrelFish, and Chrome's V8.

Why exactly is Chrome crap? It loads in 1/4th of the time it takes for Firefox to load, you can do things while pages load (like switch to other tabs) without lagging, not to mention that Webkit gets a 100/100 on Acid 3 (Chrome is at 79/100, which I assume is a combination of them not using the most recent build, and using a different javascript engine). For comparison, Gecko's at 85/100.

On another note.. Webkit takes performance seriously.

Not that I think all browsers should use Webkit, but it's certainly not crap.

localStorage was added at 9 February 2008 09:13:12 GMT into HTML 5. Safari 3.1, whose WebKit is used by Chrome, was branched from WebKit ToT in January. Surprisingly, something only added to the spec in February isn't in a January version of an implementation.

[Citation needed]
Webkit has a HTML5 compliant local storage api since Friday, October 19th, 2007. So, if they branched Webkit in January 2008 as you state, the implementation was already there. But anyway, can you backup your statement with some links?

The webkit implementation in Chrome right now is over a year out of date...

No conspiracy theory here. Wait for Google to update the current webkit version.

Wabkit has the local storage api in place since Friday, October 19th, that's a pretty long time for a HTML rendering engine, and without backporting stuff to their local implementation.
No conspiracy theory here: companies pushing their own stuff over standard implementations is pretty normal stuff.

I see no reason not to assume stupidity instead of malice.

I do actually. The HTML 5 compatible client side storage API was lready there. To remove it, they HAD to know it is there. So they stripped it out and replaced it whit google gears. No stupidity there. Any other excuses?

WebKit itself is doing 100/100 on Acid3. One would assume that Chrome would be performing similarly as it is based on WebKit, especially when this 100/100 result was achieved in March of 2008. Is Chrome based on an older fork of WebKit? Or is something else going on here?

* Faster JavaScript: How much do you want to bet that V8 will quickly become part of WebKit.

SquirrelFish might object.

Safari 3.1 doesn't pass acid3 either, unless you're running a nightly build. It's bleeding edge right now, but available.

Did they use large chunks of other open-source browsers? If so, which ones?

Yes, they chose the WebKit rendering engine, which is the same one you find in browsers like Konqueror, Safari, and Google's own Android platform.

Webkit was also the first to pass Acid3 and the first to support all CSS3 selectors. Webkit support for CSS is simply way out in front of other browsers though... It supports gradient, stroke, transform, box shadow, border radius. They've also got an HTML 5 client side database built into the browser. You can check it out in Apple's latest version of safari.

Indeed - support for @font-face is already here in Safari and is being considered for Firefox.

font-face (not this MS EOT font stuff) is a real boon for web typography - I just wish the W3C had asked some designers/typographers their opinions earlier in the standards process, as currently type on the web is really poor. As for EOT - they tried that years ago, and it didn't take off because of.... DRM. I don't see what they think will be different this time round.

Here's hoping other browser manufacturers simply ignore Microsoft.

Perhaps it is time the browser can 'render' video natively as well, with standard codecs.

Take a look at the HTM5 video tag, which is already supported in Safari and coming to Firefox.

What 'standards' to support, and are supportable, is the catch.

Right. The state of various codecs is pretty sad right now.

That is: Apple is likely to just support whatever QuickTime does, but QuickTime will only include formats that Apple has licensed. They haven't had their lawyers look over the open formats (Theora, Vorbis, Dirac) to make sure that there's no risk of some submarine patent -- of some company just waiting for one of these formats to get popular, so they can start trolling.

On the other hand, Firefox really can't afford to license anything, so they'll probably only support open formats. Hopefully, they'll make it easy to plug things in, and on Medibuntu, I hope to see proper x264 support.

But the net result is, with the video tag as is, you're still going to be forcing people to install some sort of plugin, unless Apple does something really surprising.

The versions of web developer-like plugins for Safari, just suck; it's as simple as that. Otherwise I'd be on Safari. But it's far more proprietary-behaving than Firefox.

1.) Turn on the developer menu under advanced preferences. This gives you DOM and CSS inspection, network activity monitor, user agent selection, JavaScript console and other basic web dev tools.

2.) Download Drosera. The download instructions for Safari 3.1/3.0 have you download a version of WebKit, but you don't need to install it. Just install the version of Drosera that comes in the DMG. You'll also need to enter the command to enable WebKit script debugging (provided in the link), restart Safari and you're ready to go.

I think FireBug still beats the Web Inspector/Drosera combo in a few areas (e.g. I'm not sure if you can dynamically alter CSS like you can in FireBug) but these tools get you most of what you're accustomed to in FireBug.

If you're not seeing 100/100 on Acid3 with a WebKit nightly build on Mac OS X or Windows you should file a bug report.

The difference is the speed. The idea is that toolkits like jquery can use querySelectorAll under to hood to speed up their query implementations.

Just to put this in perspective, here are the numbers for three toolkits and the native implementations in a build more or less equivalent to the alpha on http://webkit.org/perf/slickspeed/ :

prototype 1.6.0.2: 16310
jQuery 1.2.3: 36201
ext 2.0: 23310
querySelectorAll: 716

All times in milliseconds. The more complex the query, the bigger the lead querySelectorAll has, generally speaking. For example, for the "div div div" selector, it's about 36 times faster than the fastest of the toolkits, and about 200 times faster than the slowest one.

Too bad we don't have access to the source code :( If this was an open source project, we'd be able to add in features like that.

You can find out how to get the firefox source code here and the web kit/safari source code here.

Apple does very little of the core work for Safari. They just take the open-source WebKit engine and slap their own UI over it

You are incredibly misinformed. A quick glance at recent WebKit changes readily shows how blatantly false your claim is.

Are you sure that apple just slap their own GUI on WebKit?
http://trac.webkit.org/

Safari is not trailing Firefox as it is being developed in all ways, especially JavaScript performance. I actually prefer to use Firefox 3 on the Mac (much better array of plug-ins, and better security), but the latest WebKit nightlies, on http://www.webkit.org/ since the implementation of Squirelfish (see blog there) are quite a bit faster in JavaScript performance than Firefox. If anything, Firefox is going to have some catching up to do in that department.

Although I'm not sure why this is relevant, it might be worth noting that the Nokia N60 uses WebKit (the same engine as Safari) by default, as will all the Android phones. It's also at the core of many other applications. What's more, there have been several reports that Safari has the highest mobile market share in terms of actual use, rather than mere installed base.

Non free? I believe you mean they have a proprietary source code, as opposed to open source like firefox.

Safari is Open Source. Head over to WebKit.org and you can get the source via Subversion or browse it via Trac. It's licensed under a mix of LGPL and BSD licenses.

His point about a clean code base is that it lowers the bar for new developers to join the project. By comparison, OOo internals are supposed to be a nightmare maze of twisty little passages and difficult to learn.

This was the reason why Apple originally chose KDE's KHTML source code over Mozilla's Gecko. Clean, lean, code that was easy to understand, debug and extend. The fruits of that we see today in Safari and Webkit.

I hope to see the html 5 video support added for Fx3.1

You're almost certainly going to get it, with Ogg Theora support at the very least (a DirectShow backend for Windows, QuickTime backend for Mac OS X, and GStreamer backend for Linux are also in the works). But the real question that no one seems to be asking is, where is HTML 5 audio support? It's just as much a part of the specification, and Ogg Vorbis is well-known enough that corporate entities aren't so worried about patents. I've seen some work on it recently, but I'm not sure it's mature enough to make the deadline. HTML 5 audio and video support in Firefox 3.1 would be a dream though. Safari already has at least some support for both, and Opera has partial support for audio with video surely not far off. Internet Explorer is obviously going to take a long time to catch up, but I guess we can't have everything...

Reflections can be done with Canvas. Safari has built-in reflection support via custom css properties.

...what it would be like if Apple came up with a benchmark for web browsers? They'd do some kind of splashy announcement. Geeks would question its relevance in the real world. Soon they'd do some new tests and proclaim that the competition now performs better on those same tests anyway. Eventually, the rabid Apple phanbois will claim that the next release will bury the competition.

Apple. So predictable.

...what it would be like if Apple came up with a benchmark for web browsers? They'd do some kind of splashy announcement. Geeks would question its relevance in the real world. Soon they'd do some new tests and proclaim that the competition now performs better on those same tests anyway. Eventually, the rabid Apple phanbois will claim that the next release will bury the competition.

Apple. So predictable.

• Firefox 2.0.0.14
  Total execution time: 32,393.8ms +/-6.4% - Full Result
• Firefox 3.0
  Total execution time: 5,442.2ms +/-2.4% - Full Result
• Internet Explorer 7
  Total execution time: 57,794.6ms +/-8.1% -