> this is really the kind of content that should be coming 
  > out of Google itself.

What does this blog post do which the official docs don't?

E.g., https://developers.google.com/chrome-developer-tools/docs/sc...

It's true- I've spent a lot of time developing HTML5-based apps (i.e. in a webview) and am already surprised at how much worse the Android web engine is than the iOS one. Google should be all over this (and with the release of Chrome of Android, perhaps they finally are) but it baffles me that it took this long. Meanwhile, it took Mozilla to create Boot To Gecko, a true web OS.

The Chrome beta on ICS is great, but it's only accessible to <4% of all android devices. ICS has been out for months, and the providers are completely dragging their feet on it.

Chrome Beta needs to be backported to at least 2.3

AFAIK it also doesn't make any difference to apps that use webviews. I mean, it's just as well- if you changed the underlying engine without notifying devs insanity would ensue. But it would be good to be able to set a flag that says "use the decent engine".

You're correct. But no reason google couldn't add a ChromeWebView lib as part of the install of the new browser for PhoneGap to wrap.

Or google could integrate chrome web-apps/NaCL into android, as first class apps.

"ICS has been out for months, and the providers are completely dragging their feet on it."

Can anyone explain why this is such a problem? Does Android not have a proper hardware abstraction layer or driver model that would allow OS updates immediately, as long as these layers remained compatible and a build existed for your processor family?

Windows has supported disparate hardware configurations for many, many years. Yet, generally, you can run out and buy the new version and install it. Why can't Android do this (albeit with a version for each processor)?

Many providers have customized the OS for the look and feel along with adding their custom apps and settings including locking out tethering. One of the big advantages of 3.0 was it was suppose to provide an easier way to separate out the look and feel out of the OS so the providers didn't need to create a custom OS. This make pushing out updates very difficult.

For example, I worked on an app to be included with the device by the OEM. The OEM had roll a custom OS and kernel to handle their hardware and replace/update the mail and calender app because they are very tied to Google by default. We needed hooks into the the mail and calendar app in ways that are not supported by Google so the OEM also had to add those hooks for us. At this point, we were deep into unsupported territory by Google, but supported by the OEM. These things change unexpectedly with minor OS updates from Google which make them brittle to maintain. An update to a newer OS would be a hell of a lot of work.

All that said, if we could have based off of 3.0 instead of 2.3, many of these issues would not exist because of some abstraction layers added just for this purpose. I expect 4.0 to make that even nicer.

Thanks. At least there's some indication that it's getting better.

Too bad the providers have to degrade the experience with their crap, instead of just providing additional apps if they feel it's necessary.

For one thing, last I looked, Chrome Beta requires the GL_OES_egl_image extension for off-thread texture upload, and had support for the ICS-only SurfaceTexture (although judging by the WebKit source that's ifdef'd out). GL_OES_egl_image support is very spotty on pre-ICS devices.

  Android, instead of making the web a first-class citizen,
  has in fact set the mobile web back by years.

I don't know how you can come to this conclusion. Android has made an excellent mobile web browser available to over a quarter of a billion people.

And how is the web not first-class? Google even started Web Intents to interoperate web apps with native apps.

You seem to expect different things than the GP (and me).

A browser without decent SNI support, with broken XPATH support and really various shortcomings was outdated when it came out - and neglected afterwards.

Here ya go, in video too (Google I/O) http://youtu.be/N8SS-rUEZPg

Also has a part on remote debugging which the article doesn't.

> a first-class citizen, has in fact set the mobile web back by years

Steve Jobs started it. Everyone will follow it to the bitter end.

There's some revisionist history. When the iPhone was released, mobile apps were supposed to be HTML5 webapps. Developers cried for local apps. Apple responded to demand.

The truth is likely somewhere in between. Apple probably anticipated the demand for native apps. But they weren't ready, business-wise if not technically, to build the SDK and App Store in 2007, so they held off on it for a year.

Sometimes it's useful to pretend that what you were going to do all along was merely a concession to outside demand.

Steve Jobs said in the intro of the phone that the apps were "just the internet" or some such. Personally, when I heard that I just ignored the iPhone.

The steve jobs bio documents how he was deadset against native apps, even after the iphone was released. Even apple has to listen to its customers / developers every now and then. The myth that apple's moves are all part of a big plan is just that.