Linked List: March 17, 2011

Satellite Photos of Japan Before and After Tsunami 

Heartbreaking.

Rafe Colburn on the Nitro Thing in iOS 4.3 

A clarification I neglected to make in my piece on it earlier today:

  • Web apps running from home screen but not in full-screen mode (which launch inside Safari) run Nitro fine.

  • Web apps running from home screen in full-screen mode launch inside Web.app, which is a system app and in theory should be able to run Nitro but it’s not because it lacks the entitlement.

So, yes, it’s only those web apps which invoke the special markup syntax to run in full-screen mode that are affected by this. Home screen web apps that open inside Mobile Safari do get Nitro (and all other Mobile Safari performance optimizations). As for why Apple couldn’t/didn’t allow full-screen web apps to get Nitro in iOS 4.3, I don’t know.

If I Could Have Linked to This Tweet a Few Hours Ago, It Would Have Saved Me a Lot of Typing 

Mark Pilgrim:

Wait, so the big conspiracy is that Apple made their browser faster? We should all have these problems.

WebKit2 and the Split-Process Model 

Still in development:

WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.

After publishing my piece today on why the Nitro JavaScript engine isn’t available system-wide in iOS 4.3, several readers reminded me of the in-progress WebKit2 project. Surely, this will eventually come to iOS, and when it does, it solves a lot of problems for Apple. I think iOS 4.3 granting Mobile Safari an exception to the rule against marking pages in memory executable is a stopgap.

Study Comparing Android to iPhone Web Browsing Speed Flawed 

Jim Dalrymple:

One of the biggest surprises the Blaze team found was that “despite significant JavaScript performance gains in the latest Apple iOS 4.3 release and Google Android 2.3 releases, these improvement made no measurable improvement on the actual page load times of the sites tested.”

There is a good reason for this. According to Blaze’s own documentation the “measurement itself was done using the custom apps which use the platform’s embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone.”

Right. The problem with Blaze’s entire study is that they didn’t test what they claimed to be testing. They used custom apps for iOS and Android, but claim the results show that Android’s browser is faster than iOS’s Mobile Safari. Instead, their results show that Android’s WebView control is faster than iOS’s UIWebView control. Mobile Safari is not just a thin wrapper around the system’s UIWebView control — it has its own caching system, its renderer uses asynchronous multithreading (UIWebView does not), and, as of iOS 4.3, Mobile Safari uses its own much faster JavaScript engine (“Nitro”).

That’s not to say it isn’t interesting that Android’s WebView for apps is faster than iOS’s UIWebView for apps, but it just isn’t true that these results are indicative of anything regarding Mobile Safari’s performance. It’s easy to see that Mobile Safari is faster than UIWebView — just run something like the SunSpider benchmark twice, once in Mobile Safari and once in any app from the App Store with a web content view. On my iPhone 4, Mobile Safari runs SunSpider almost three times as fast as an app using UIWebView.

These Blaze guys are either incompetent or dishonest attention seekers, given that they claim this, in an update to their report:

Some wonder whether the new Nitro JavaScript engine was used in our measurements. We’re still investigating this issue, as the report was completed before it was made known. So far we’ve seen indications in both directions, so we can’t say for sure it’s being applied.

That said, the results from measuring Android show that JavaScript only accounts for a small percentage of the total load time, about 15% on average. This implies that even if Nitro is not in use, it likely can only slightly narrow the gap. We’ll follow up with any additional info.

Because the thing is, Nitro isn’t the only difference between Mobile Safari’s rendering and UIWebView’s rendering. Mobile Safari has better caching and asynchronous multithreading, too.

Improved Flickr Slideshows for the iPad 

Nice. Too bad they still use Arial instead of Helvetica.

Five Years Ago Today: Ze Frank’s The Show Debuted 

I still miss it. Full list of episodes, here on The Show’s iTunes podcast page.

GQ: The Worst Sports Fans in America 

GQ:

The truth is this: All told, Philadelphia stadiums house the most monstrous collection of humanity outside of the federal penal system. “Some of these people would boo the crack in the Liberty Bell,” baseball legend Pete Rose once said.

Or as we call that list here in Philly, “The Best Sports Fans in America”.

Panic: Let’s Help Japan 

Cabel Sasser:

Panic will donate 100% of today’s proceeds directly to the Japanese relief effort.

It doesn’t matter if you buy direct from us or via the Mac App Store, we’ll take care of it. We’ll total up sales from 10:00 AM PST Mar 17th to 10:00 AM PST Mar 18th. And we plan to donate to a mix of the Japanese Red Cross Society and Portland’s own Mercy Corps.