Say that part about HTML standards, again?

In incarnations past, I have had debates, public and otherwise, with friends and colleagues
who have asserted that HTML5 (by which we really mean HTML5/JavaScript/CSS3) will
essentially become the platform of choice for all applications going forward—that
essentially, this time, standards will win out, and companies that try to
subvert the open nature of the web by creating their own implementations with their
own extensions and proprietary features that aren’t part of the standards, lose.

Then, I read the Wired news post about Google’s
departure from WebKit [1], and I’m a little surprised that the Internet (and by “the
Internet”, I mean “the very people who get up in arms about standards and subverting
them and blah blah blah”) hasn’t taken more issues with some of the things cited therein:

Google’s decision is in tune with its overall efforts to improve the infrastructure
of the internet. When it comes to browser software and other web technologies that
directly effect the how quickly and effectively your machine grabs and displays webpages,
the company likes to use open source technologies. That way, it can feed their adoption
outside the company — and ultimately improve the delivery of its many online services
(including all important advertisements). But if it believes the rest of the web is
moving too slowly, it has no problem starting up its own project.

Just to be clear, Google is happy to use open-source technologies, so it can feed
adoption of those technologies, but if it’s something that Google thinks is being
adopted too slowly—like, say, Google’s extensions to the various standards that aren’t
being picked up by its competitors—then Google feels the need to kick off its own
thing. Interesting.

… [T]he trouble with WebKit is that is used different “multi-process architecture”
than its Chrome browser, which basically means it didn’t handle concurrent tasks in
the same way. When Chrome was first released in 2008 WebKit didn’t have a multi-process
architecture, so Google had to build its own. WebKit2, released in 2010, adds multi-process
features, but is quite different from what Google had already built. Apple and Google
don’t see eye to eye on the project, and it became too difficult and too time-consuming
for the company juggle the two architectures. “Supporting multiple architectures over
the years has led to increasing complexity for both [projects],” the post says. “This
has slowed down the collective pace of innovation.”

So… Google tried to use some open-source software, but discovered that the project
didn’t work the way they built the rest of their application to work. (I’m certain
that’s the first time that has happened, ever.) When the custodians of the project
did add the feature Google wanted, the feature was implemented in a manner that still
wasn’t in lockstep with the way Google wanted things to work in their application.
This meant that “innovation” is “slowed down”.

(As an aside, I find it fascinating that whenever a company adopts open-source, it’s
to “foster interoperability and open standards”, but when they abandon open-source,
it’s to “foster innovation and faster evolution”. And I’m sure it’s entirely accidental
that most of the time, adopting “open standards” is usually when the company is way
behind on the technology curve for a given thing, and adopting “faster innovation”
is usually when that same company thinks they’ve caught up the distance or surged
ahead of their competitors in that space.)

Of course, a new implementation has its risks of bugs and incompatibilities, but Google
has a plan for that:

“Throughout this transition, we’ll collaborate closely with other browser vendors
to move the web forward and preserve the compatibility that made it a successful ecosystem,”
the announcement reads.

Ah, there. See? By collaborating closely with their competitors, they will preserve
compatibility. Because when Microsoft did that, everybody was totally OK with that….
uh, and… yeah… it worked pretty well, too, and….

Look, it seems pretty reasonable to assume that even if the tags and the DOM and the
APIs are all 100% unchanged from Chrome v.Past to v.Next, there’s still going to be
places where they optimize differently than WebKit does, which means now that developers
will need to learn (and implement) optimizations in their Web-based applications differently.
And frankly, the assumption that Chrome’s Blink and WebKit will somehow be bug-for-bug
compatible/identical with each other is a pretty steep bar to accept blindly, considering
the history.

Once again, we see the cycle coming around: in the beginning, when a technology is
fleshing out, companies yearn for standards in order to create adoption. After a certain
tipping point of adoption, however, the major players start to seek ways to avoid
becoming a commodity, and start introducing “extensions” and “innovations” that for
some odd reason their competitors in the standards meetings don’t seem all that inclined
to adopt. That’s when they start forking and shying away from staying true to the
standard, and eventually, the standard becomes either a least-common-denominator…
or a joke.

Anybody want to bet on which outcome emerges for HTML5?

(Before you reach for the “Comment” link to flame me all to Hell, yes, even an HTML
5 standard that is 80% consistent across all the browsers is still pretty damn useful—just
as a SQL standard that is 80% consistent across all the databases is useful. But this
is a far cry from the utopia of interconnectedness and interoperability that was promised
to us by the HTMLophiles, and it simply demonstrates that the Circle of TechnoLife
continues, unabated, as it has ever since PC manufacturers—and the rest of us watching
them--discovered what happens to them when they become a commodity.)

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details [2].