After a great week at the W4A 2011 and WWW 2011 conferences, I've been thinking a lot about the true meaning of a Web browser and a Web app, particularly triggered by a great W4A keynote speech by Bebo White and an insightful dinner chat with him, Simon, and Markel afterwards.
We, as a Web community, often perceive Web browsers as really concrete applications: Internet Explorer, Mozilla Firefox, Apple Safari or Google Chrome, and Web apps as the wet dream of thin-client lovers. But, in reality, things are much more blurry than that.
The initial propostal for the World Wide Web elicites the following definition of a Web browser:
is a native application program running on the client machine:
- it performs the display of a hypertext node using the client hardware & software environment. For example, a Macintosh browser will use the Macintosh interface look-and-feel.
- it performs the traversal of links. For example, when using a Macintosh to browse on CERNVM FIND it will be the Macintosh browser which remembers which links were traversed, how to go back etc., whereas the CERNVM server just responds by handing the browser nodes, and has no idea of which nodes the user has visited.
- it performs the negotiation of formats in dialog with the server. For example, a browser for a VT100 type display will always negotiate ASCII text only, whereas a Macintosh browser might be constructed to accept PostScript or SGML.
Basically, a Web browser is a client application that knows about links (represented by URIs) and communicates with Web servers. Indeed, the formal specification for the Architecture of the World Wide Web does support this assertion.
Actually, Web browsers are nothing more than fancy specialisations of the concept of user agent (which should identify themselves in adequate HTTP headers). A user agent is, indeed, one of the main axioms of the Web's architecture:
Browsers and Email programs are user agents. This isn't just a formal long term for them, it is an important issue. They are programs which act on behalf of, and represent, the user.
However, I couldn't find a formal definition for the term Web app. My experience, and from all the reading and discussions I've seen in the past, a Web app can be loosely defined by the following three major characteristics:
- It is accessed via the Web (i.e., through HTTP);
- It interacts with Web resources;
- It is built on top of existing Web technologies (e.g., HTML, CSS, Javascript).
Any given combination of these characteristics results in a different flavour for a Web app, such as:
- A simple HTML Web app (combining 1. and 3.);
- A complex HTML Web app that interacts with several Web resources (combing all characteristics);
- A Flash-based Web app (combining 1. and 2.).
Now, onto modern Web-centric development. Several of the contemporary services and applications deployed on the Web provide API binding points, upon which accessing applications and added-value services can be built.
Case in point: the Twitter ecosystem.
At a fundamental level, the Twitter Web site behaves as a Web app: it is accessed via the Web (through a Web browser), it interacts with Web resources (via the Twitter API), and it is built on top of existing Web technologies. [ed. note: the discussion between the blurry lines between Web pages and Web apps is off-topic in this post]. The same reasoning can be applied onto other third-party Web apps such as HootSuite and TweetDeck (I leave as an exercise to the reader the reasoning over the TweetDeck Chrome app).
Now, here's the catch that Bebo made (and which got me thinking): how close are we to think about native apps as a hybrid between user agents and Web apps? Here are some possible reasons on this, using the Twitter iPhone app as the lab rat:
- It is, definitely, accessed via the Web: the actual app is available through a URI (okay, installed might be a more adequate term, but then we get onto the discussion about whether or not Chrome apps are Web apps or not);
- It interacts with Web resources: not much case on this, since it operates on top of the Twitter API (via HTTP);
While as a native iPhone app it is implemented in Objective-C, it could definitely be implemented with Web technologies such as PhoneGap.
- It performs the display of a hypertext node using the client hardware & software environment: a tweet, a user profile, a tweet stream, all are uniquely available as hypertext nodes (i.e., represented by URIs);
- It performs the travessal of links: this happens in different situations, such as embedded links, retweets, @usernames. All of them follow the link travessal metaphor;
- It performs the negotiation of formats in dialog with the server: the Twitter API does interpret the Accept HTTP header, where data is transmitted e.g. in JSON, instead of the more traditional HTML version.
So, it seems that this app indeed suits all requirements to be classified both as a Web browser and Web app. Should we, then, start thinking more broadly about the consequences of this conceptual shift?
- What is the meaning of inter-app linking? How can it be achieved at the fundamental level of the Web?
- Should APIs stop existing and being nothing else than different content representations (i.e., 100% REST services) ?
- What common treats of classical Web browsers should be ported to apps?
Food for thought.
