I think it’s a category error to compare the web to Android or Windows or iOS. It’s like comparing Coca-Cola, Pepsi, and liquid. The web is something that permeates the platforms. From one point of view, this appears to make the web less than the operating system that someone happens to be using to access it. But in the same way that a chicken is an egg’s way of reproducing and a scientist is the universe’s way of observing itself, an operating system is the web’s way of providing access to itself.

Wait a minute, though …Cennydd didn’t actually compare Android to the web. He compared Android to the web browser. Like I’ve said before:

We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.

But Cennydd’s comparison does raise an interesting question: what is a web browser exactly? Answering that question probably requires an answer to the question: what is the web?

(At this point you might be thinking, “Ah, this is just semantics!” and you’d be right. Abandon ship here if you feel that way. But to describe something as “just semantics” is like pointing at all the written works in every library and saying “but they’re just words”, or taking in the entire trajectory of human civilisation and saying “but those are just ideas”. So yeah, this is “just” semantics.)

So what is the web? Well the unsexy definition I’ve used in the past is that the web consists of files (e.g. HTML, CSS, JavaScript), accessible at URLs, delivered over HTTP. So FTP is not the web. Email is not the web. Gopher is not the web.

But to be honest, I don’t think that the Hypertext Transfer Protocol is the important part of the web; it’s the URLs that really matter. It’s the addressability of the files that’s the killer app of the web in my opinion.

I also don’t think that it’s the file formats themselves that define the web. Don’t get me wrong: I love HTML …and I have nothing against CSS or JavaScript. But if HTML were to disappear, the tears I would weep would not be so much for the format itself, but for the two decades of culture that have been stored with it.

I was re-reading Weaving The Web and in that book, Tim Berners-Lee describes his surprise when people started using HTML to mark up their content. He expected HTML to be used for indices that would point to the URLs of the actual content, which could be in any file format (PDF, word processessing documents, or whatever). It turned out that HTML had just enough expressiveness and grokability to be used instead of those other formats.

So I certainly don’t consider anything that happens to be written using HTML, CSS, and JavaScript to automatically be a part of the web. I can open up a text editor and make an HTML document but as long as it sits on my computer instead of being addressable by a URL, it’s not part of the web. Likewise, a native app might be powered by CSS and JavaScript under the hood, but without a URL, it’s not part of the web.

Perhaps then, a web browser is something that can access URLs. Certainly in pretty much every example of a web browser throughout the web’s history, the URL has been front and centre: if the web were a platform, the URL bar would be its command line.

But, like the rise of HTML, the visibility of the URL in a web browser is an accident of history. It was added almost as an afterthought as a power-user feature: why would most people care what the URL of the content happens to be? It’s the content itself that matters, and you’d get to that content not by typing URLs, but by following hyperlinks.

There’s an argument to be made that, with the rise of search engines, the visibility of URLs has become less important. See, for example, the way that every advertisement for a website on the Tokyo subway doesn’t show a URL; it shows what to type into a search engine instead (and I’ve started seeing this in some TV adverts here in the UK too).

So a web browser that doesn’t expose the URLs of what it’s rendering is still a web browser.

Now imagine a browser that you install on your device that doesn’t expose URLs, but under the hood it is navigating between URLs using HTTP, and rendering the content (images, JavaScript, CSS, HTML, JSON, whatever). That’s a pretty good description of many native apps. There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).

Reading the responses to @Cennydd’s tweet about designers needing to pay attention to Android. The web is fragmented. That’s our job.

I understood Cennydd’s point to be about native apps, not the web. But if, as I’ve just said, many native apps are in fact web browsers, does that mean that making native apps is a form of web development?

I don’t think so. I think making a native app has much more in common with making a web browser than it does with making a web site/app/thang. Certainly the work that Clearleft has done in this area felt that way: the Channel 4 News app is a browser for Channel 4 News; the Evo iPad app is a browser for Evo.

So if your job involves making browsers like those, then yes, you absolutely should be paying more attention to Android, for all the reasons that Cennydd suggests.

But if, like me, you have zero interest in making browsers—whether it’s a browser for Android, iOS, OS X, Windows, Blackberry, Linux, or NeXT—you should still be paying attention to Android because it’s just one of the many ways that people will be accessing the web.

It’s all too easy for us to fall into the trap of thinking that people will only be using traditional monolithic web browsers to access what we build. The truth is that our work will be accessed on the desktop, on mobile, and on tablets, but also on watches, on televisions, and sure, even fridges, but also on platforms that may not even have screens.

It’s certainly worth remembering that what you make will be viewed in the context of an artisanal browser. Like Jen says:

The “native apps are better” argument ignores the fact one of the most popular things to do in apps is read the web.

But just because we know that our work will be accessed on a whole range of devices and platforms doesn’t mean that we should optimise for those specific devices and platforms. That just won’t scale. The only sane future-friendly approach is to take a device-agnostic, platform-agnostic approach and deliver something that’s robust enough to work in this stunningly-wide range of browsers and user-agents (hint: progressive enhancement is your friend).

I completely agree with Cennydd: I think that ignoring Android is narrow-minded, blinkered and foolish …but I feel the same way about ignoring Windows, Blackberry, Nokia, or the Playstation. I also think it would be foolish to focus on any one of those platforms at the expense of others.

I love the fact that the web can be accessed on so many platforms and devices by so many different kinds of browsers. I only wish there more: more operating systems, more kinds of devices, more browsers. Any platform that allows more people to access the web is good with me. That’s why I, like Cennydd, welcome the rise of Android.