X Is Killing the Web

Posted September 21, 2011 @ 1:19 pm

First, a few words from Joe Hewitt:

“We should dissolve the W3C and run the web like an open source project. No more specs, just commits. Does Linux need a standards body?” [via]

“How could anyone seriously defend the W3C in an era where proprietary platforms (see iOS and Android) are destroying the web?” [via]

“Yes, I would love there to be only one browser. The “web kernel”. Fork it if you want. We don’t need specs. Specs are killing the web.” [via]

Where To Begin

I don’t mean to pick on Joe Hewitt. I love Firebug and couldn’t do my job without it. But being legitimately angry about something necessarily means ditching the broad, sweeping generalizations and getting down to brass tacks.

In the same line of thought of my last post here, I think there are some fundamental misunderstandings about the Internet and the Web that are being propagated by statements like this. Let’s have a look.

A Few Definitions

The Internet is a network of machines that carries data. It’s sending information from one of Tumblr’s servers to the computer in front of you (doesn’t matter if that’s a laptop, phone, or tablet—they’re all computers).

The Web, in its purest sense, is the interconnected set of hypertext documents that we view in our browsers. This Tumblr blog is part of the Web.

A browser is a piece of software that can access data on the Internet using the hypertext transfer protocol (HTTP). You’re viewing this Tumblr blog in your browser.

These things define the popular idea of the Web as it existed many years ago. The last decade has been incredibly transformative. Our nomenclature hasn’t kept up. Yes, the Internet is still the Internet, and a browser is still a browser, but what we refer to as the Web now is fundamentally different from a collection of linked documents.

Our Current Definition of the Web Is Broken

Note: This is not some pro-Web-3.0 screed.

We’re pushing a lot more than hypertext over the pipes and wires of the Internet now. Tim O’Reilly was on the right track when he coined “Web 2.0” and said it encompassed the advent of user-contributed content. But Tim Berners-Lee was right, too, when he refuted the term, saying the phrase was simply bringing to the fore some of the ideas he had for the original Web—that it would be read and write.

I think what O’Reilly was getting at, though, was the rise of Web applications and API-driven services that exist outside the traditional definition of the Web. They don’t fit in the description of the Web as a medium for hypertext documents.

Take Instagram, for example. Here’s a photo sharing service that, at its inception, used the Internet to push data to an application on a phone.¹ The receiving application was not a browser, nor was the app displaying the data as hypertext. The only relationship the data had to hypertext was that it was transmitted via the HTTP protocol.

The W3C’s specs never came into question when someone viewed their photo stream in Instagram. Nor did any browser. Webkit rendering wasn’t an issue, either. In the end, the Web (even as we know it today) was never involved.

Instagram in its original form was a data store, an API, and a native app for iOS. It transmitted data via the Internet, but it wasn’t a Web app (I take it as read that a Web app is necessarily interacted with via a website in a browser, not via a native front-end to an API).

To be clear: Instagram never broke, destroyed, or killed the Web because it wasn’t part of the Web.

And yet, Instagram was still considered by most to be part of the Web.

Native vs. Web

Joe Hewitt is working on a project called Scrollability that aims to bring iOS-style inertial scrolling to Web applications. It’s an admirable project, but I think it underscores the real argument at the heart of Joe’s tweets: Web applications are not first-class citizens on iOS and Android.

As I’ve said before, they never will be; there’s too much money to be made by Apple and Google (and now Microsoft). Call it unfair, but I think it’s also unfair to claim that Webkit or the W3C is to blame for the lack of feature parity between native applications and Web applications. And it’s somewhat ludicrous to say that iOS and Android are destroying the Web because the developers of those platforms are reluctant to add new features to their respective forks of Webkit without a spec.

To imply that Webkit has stagnated because of a slow spec process is to forget about Internet Explorer. Maybe it’s not entirely germane (or possibly too much of a we’re-so-lucky argument), but seriously, we’re lucky today to have browser vendors in control of a large part of the market who are supporting standards (even if it’s happening slowly) rather than eschewing them because of their monopoly.

Honestly, I’m not a big fan of the W3C, either. As with any bureaucracy, it’s a tortoise, and waiting for new specs is painful. But having a spec prevents companies from pulling a Microsoft and implementing things willy nilly. That needs to be avoided.

The fact that Google and Apple are already implementing somewhat proprietary versions of Webkit frustrates me. The idea that they’d jump entirely outside the bounds of specifications for the sake of faster feature parity with native apps makes the Web developer in me want to throw up my hands and quit. I’d rather wait for the spec.

The Web Is Not the Future

In a reply to another Twitter user, Joe said, “I want the future to be the web. I am trying very hard to push it faster. It’s a slog.”

The thing is, the Web is fine. What Joe’s worried about is the future of Web applications and how they’re supported on emerging and existing platforms. That’s a distinction that needs to be made. The Web isn’t going anywhere.

But the brass tacks that we’re getting down to here is the “slog”—the speed at which progress is being made toward providing feature parity at the OS level between Web applications and native applications. The complaint has little to do with the Web and everything to do with wanting Web applications to run more like traditional desktop or native applications.

When you realize that these two things need not overlap, though—that they can both exist separately to perform optimally in a given context—the argument becomes one of preference, one front-end medium versus another. And to that, I say, if your Web app is trying very hard to be a native app, make it a native app. Square peg, square hole. Just be sure to give it a solid API. If, in the future, browsers give you what you need, you can always migrate to a Web-based front-end on the strength of your API.

The Web, Web applications, and native applications that transmit data via APIs are three very different things. To conflate them under the banner of “the Web” is a mistake, and there are clear circumstances in which each should exist separately from the others. To imply that one would destroy the other is either hyperbole or wishful thinking.

Not all native applications should be Web applications and vice versa.

Not all Web pages should be generated by an API, and not all APIs should generate Web pages.

Not all data on the Internet is part of the Web.

8 months ago  ∞  1 note  ∞  short link