Putting the magic in the machine since 1980.

Friday, August 14, 2009

All Applications will be Web Applications

I often mention this in my classes and other talks: it is clear that the majority of new applications will be web applications (not all of them, of course, that is just standard headline hyperbole).

Jeff Atwood gives some more reasons as to why this is happening. Basically, people like web applications because they don't have to install them or worry about what happens when they get a new computer, business like web applications because they don't have to worry about installing their custom software on every PC. We can see old desktop applications, Quicken, being replaced by web versions Mint which are better in many ways.

But the real draw of web applications lies in the interconnectedness they allow (see the photo above for an example). These applications are also services and provide REST API's for other applications to plug into them. In this way each application is also a programming library (remember DLL's and .so files?) and a database with up to date information. Thus, even the so-called desktop applications of the future will also be web applications in that they will suck down data from the web, like Google Earth. I am still trying to figure out what the proliferation of all these REST APIs and microformats will mean for multiagent systems, but I can't help but feel that this is good news for the field.

So, what does this mean for a new student? First of all, it is still programming. While you might be using a slightly higher-level language, you will still be writing for-loops, recursive functions, and lots of if-then statements. No one has invented a language that can eliminate those. Thus, nothing much changes. One still needs to have solid programming experience and knowledge of algorithms.

On the other hand, the architecture for web applications is different from the standard desktop. In a standard desktop application you write event handlers that run whenever the user clicks on a button. In web applications this becomes more complicated. You can write your JavaScript to handle events from the user, just like in a desktop application, but you also have to deal with the client-server communication (AJAX magic). This raises all sorts of very interesting questions about what activities should be handled in the server versus the client. For many of the current set of applications the decision seems easy (gmail) but it is not as clear for others: should mint.com generate their pie charts server-side or client-side? The decision depends on the user experience you are after as well as the capabilities of the client and server devices and the network that joins them (wired, wireless, reliable, spotty).

It is very exciting to realize that allowing others to use your software is as easy as emailing them the URL, and that they can use your software on their PC, netbook, smartphone, set-top box, kindle, etc. etc.