Over the last 5 years or so, web applications have shifted from a stateless, page oriented set-up to a statefull set-up where the concept of page has been completely banished. When it comes to the ways in which a user can interact with them, modern web applications can now rival with desktop applications. In fact, the distinction between them is already blurred. It won’t be long before – from a user’s perspective – either the notion of web application, or desktop application disappears. The fact that an application uses remote resources that it accesses through HTTP will and should be transparent for users.
Interestingly, many people don’t even care what web browser they have to use, as long as it allows them to do what they need to do. Common internet users (people that are not particularly technology savvy) will “run yahoo” where they mean starting up their browser and (automatically) opening the yahoo URL. And consequently, if Yahoo “doesn’t work” because the site is down, or the latest browser or OS update causes their web browser to crash because of incompatibility issues in Yahoo’s javascript, they probably won’t blame Yahoo or the browser, but their computer and will most likely call computer support.
In other words, to users, an application is something that allows them to achieve certain goals, and it is completely transparent to them how the application does it, whether they need internet access or not and whether a web browser is required or not.
From an engineer’s perspective however, there are many ways of creating such applications. As Tim O’reilly stated in What is Web 2.0 , the web should be seen as a platform for building and deploying applications. What does that platform look like? What does it consist of? Engineers (like myself) always try to simplify things by dividing complex notions into layers, so in my mind that platform looks a lot like a lasagna (others might prefer an onion). Each layer addresses a certain problem domain, for which a multitude of technologies can be used.
The choice of these technologies depends on many factors, such as developer preference and familiarity with the technology, cost, community opinion, compliance, compatibility, performance, scalability, et cetera. Another interesting aspect is that application developers will probably also be unaware of the workings of lower layers of the lasagne. Put very simply, building a mashup basically consists of choosing a frontend technology (there is much to choose from: Adobe Flex, JavaFX, GWT, Dojo, JQuery, Sproutcore, you name it), Web APIs (mapping APIs, social network APIs, eCommerce APIs, …), a hosting party and the technology for storing application specific data. The API’s themselves have multiple layers themselves that the developer using these APIs probably doesn’t care about. The developer only cares about certain aspects such as stability, support, compatibility with other APIs, reliability, et cetera.
I know that I am repeating myself, but in the end, the user is unaware of all this and doesn’t even care. If, in spite of the superiority of all technology used, the user experiences difficulties and annoyance with an application, the user won’t want to use it and probably switch to something else.
The other day, while I listened to one of my favourite podcasts: “The CoffeeGeek podcast”, I had a weird enlightment. In the podcast they discussed about the fact that coffee blends hide the origin of coffee beans. One argued that the origin of the beans used in a blend should be mentioned on the package, whereas the other felt that that is completely irrelevant because it is the consumer’s experience that matters. Coffee blends are very carefully created and it is ensured that the taste and quality is constant. Being a slight coffee snob, I buy single bean coffees myself every now and then, and the quality of these coffees definitely differs per year. I don’t mind that, but most people just want their cup of coffee to taste good.
A Web API blends various resources, standards and technologies (which are also blends). The developers don’t and shouldn’t care about an API’s composition. The API should just do what it promises within the expectations of the developer. A web application blends various resources, standards and technologies. The end users don’t and shouldn’t care about their application’s composition. Most people just want their applications to work as they expect.