This is is exactly right.

Almost everything in the "Field Guide" is supported across browsers --- which is good and proper, but it's not pointing the way to Chrome-only applications like the Infoworld article suggests.

Apparently in the Infoworld article, Chrome's "technical advantages" are NaCl and Dart (not mentioned in the "Field Guide"). NaCl is bad for the Web in multiple ways. It ties Web apps to specific processor architectures. (PNaCl is going nowhere because LLVM bitcode is not actually architecture-independent.) Worse, it creates a huge new set of Web APIs ("Pepper") for NaCl applications that mostly duplicate the functionality of the standards-based APIs we already have. This is a lot of unnecessary bloat, complexity and attack surface, plus a lot of extra standards work that would have to be done if NaCl were to be come a real cross-browser standard (which it won't, because no other browser vendor has shown interest in implementing it). The performance advantages of NaCl are overrated; C-to-JS compilers like Emscripten are rapidly improving, the JS language and implementations are rapidly improving, and for a lot of modern apps you want to be offloading to the GPU anyway.

Dart is unnecessary and will simply be overtaken by improvements to Javascript.

You can't. Microsoft simply doesn't offer a 64-bit linker that can produce 32-bit code.

Machine intelligence is not required for a moon base, because robots can be teleoperated from Earth at that distance.

There are definitely a bunch of technological obstacles, mainly on the robotics side, but the work required to overcome them doesn't have to be incredibly expensive (unlike building stupidly large rockets to launch lots of mass from Earth), and it would have significant spin-off benefits on Earth.

Send robots to explore. Send robots to build a base with power supply, mining and manufacturing to build more robots. Build a bigger base with air, water and plants to eat. Then, and only then, send human colonists on a one-way trip.

csunplugged.org has many great activities to help teach computer science concepts to kids (without the distraction of using computers). I've done a couple at my kids' school and it went very well.

IndexedDB is not "Mozilla's own". It was co-developed in the open with Google and Microsoft.

Have you tried it? It's fast.

One interesting fact that wasn't called out in the blog post is that since Gecko's is GPU-accelerated on Windows 7, on that platform pdf.js is GPU-accelerated, unlike every other PDF viewer I know of.

Browser developers are doing tons of work to make graphics and JS incredibly fast. pdf.js leverages that.

That is generally true but sometimes you could do it either way and get better performance with canvas.

This article is confused in so many ways, it's hard to know where to begin.

One big thing that it misses is that a lot of "HTML5" is actually writing a detailed spec for existing features that were never properly specified (e.g., HTML parsing). And a lot of the work of implementing HTML5 in a browser is to get those details right so they're the same across browsers. That helps Web authors who aren't even using any of the new features.

The list of HTML5 features has many errors. "contenteditable" is nothing to do with Web Forms and is not new in HTML5; it's been implemented in all browsers for a long time, and HTML5 just provides a (partial) spec for it. Falling back to SVG when canvas isn't available would be a mistake since every browser that supports SVG also supports canvas.

I don't know how Microsoft's "native" sloganeering got mixed up in there, because it's completely irrelevant, but let's point out that it's completely bogus. It's not even clear what they mean by "native"; the best guess is that it means "abstraction layers are bad so a browser that only runs on Windows 7 must be the best", which is complete nonsense.

John Foliot is wrong about the need for frozen spec snapshots. We often find errors in supposedly "stable" parts of the spec; if those parts are frozen in some official snapshot, that just means the snapshot is going to be more wrong than the the up-to-date version.

Web developers should always look at the latest versions of the specs for the features they use. They should decide what features to use by looking at the browser usage of their user community and making their own cost/benefit calculations.