Web Applications - The Wave Of The Future

Web applications are finally beginning to see the light of the day. I am putting all my money on this. I am sure this is the future of the web, application design, networked software architectures, maybe even desktops and operating systems itself.

Web based applications will make inroads into (almost) every kind of application we use today. In this post, I try to list out some of the benefits of using web based apps.

Read the complete post...

First, a quick introduction to web based apps, for those who just tuned in. Examples of web based applications are GMail, Bloglines, and OddPost. GMail is a full featured mail client that does everything that a desktop mail client does, only ups it a few notches. So does OddPost. Bloglines is a web based feed reader that is directly competing with desktop feed readers, and winning. These web apps are basically applications that run on a server, whose UI is exposed in the form of web pages. By the very nature of its architecture, the program logic lies in a central place (the server), and the UI is available to the client in a piece of software that has been around since the birth of HTTP itself (the browser). The use of JavaScript and the DOM is probably the single most important factor that has made these apps possible.

The use of JavaScript is very different from the way it was used in 1999. Back then, JavaScript was just a cool way to make mouseovers and cool (now irritating) dynamic elements on the page like mouse pointer trails and flashy text that change colors. JavaScript was used because it could be, not because it should be. At one point, I thought JavaScript was dead, indeed like many other developers must have thought. The use of JavaScript became an example of bad web design, and the language was pushed into the dark annals of the world of notorious web pages.

Now, though, JavaScript has matured. It is used just what it was designed for - creating dynamic changes on the client side without introducing a server refresh lag. A dynamic front end in a browser window has always been a problem for application design and is probably the only reason why web based applications have not yet seen the light of the day. Today’s use of JavaScript circumvents that problem.

Now that we can make web applications, here's why we should, and will, do it.

The application lies at only one place

The application logic lies on the server, unlike desktop applications, where the application logic lies on the user’s computer. Since there is only one working copy of the application, it’s much easier to distribute. In fact, distributing applications in the traditional way doesn’t make sense here at all, since the user doesn’t really get a copy of the app at all. All the user gets is the UI, which is really all he needs. Application distribution is a non-existent problem, which means it is as easy as it can get.

The user doesn’t need any software

All the user does is fire his browser and type in a URL. These days, browsers are a standard piece of software that usually gets bundled with the OS itself, so finding a browser on the client is not a problem at all, and really, that’s all the user needs.

The user isn’t the administrator

Typically, when a user has the need for an application, he has to prepare himself to be the administrator of the application. He will have to do the setup, running, maintenance and troubleshooting, and handle all the problems that come with it. But in the case of web apps, since the app is really not with the user at all, the user won’t have to worry about these problems. And really the user shouldn’t. That makes for a happy user. That translates into a good application. This, of course, is impossible with desktop applications.

The administrator is the application’s programmer

Yes, the load on the programmers is more. But if you compare that to the costs of making deployable applications and then managing a service team to help users install, maintain and troubleshoot the application, it’s easy to see which is cheaper, not to mention more efficient. A small team of programmers working at one central location to maintain, manage and troubleshoot applications makes more economic sense to app manufacturers.

The application makes no assumptions about the user

Ok, that is a small lie. The user is assumed to have a capable browser to handle the application. But really, is that such a big deal? Because of the very nature of HTTP, the application is platform independent. This means that the user can use any operating system he wishes to use, and that doesn’t make a difference. This is a huge change from the traditional “Designed for <operating system name here>” applications. The user doesn’t have 512 MB RAM? No problem. The user doesn’t have processing power? No problem. The user has an outdated motherboard? No problem.

Multiple versions is a thing of the past

When a new version of the application is out, every single user gets to use it instantly. Literally. How cool is that! Again, this is possible since the application is centralized, and there’s really only one running copy of the application. All version changes are instantaneous and the user doesn’t need to know how to upgrade. This also means that the app developers don’t have to worry about supporting legacy versions and backward compatibility is not an issue.

It’s lightweight

The user doesn’t really download the whole application before using it. (Take that, Java fans!). He doesn’t even download the whole UI. He only downloads the part of the UI that is required for his use immediately over the URI that he’s on. This makes the application very lightweight and hence responsive and fast. Even very complex applications can load in seconds, maybe less, even over a bad connection, thanks to this.

It’s portable

There’s nothing installed at the users end, so the user can use the app from any location. Any location means literally any location across the globe. You can use the application in your office, and then at home, and then from your vacation in Hawaii, and every time it works just as well, without any problems of portability.

It’s simple and trustworthy

No messy extra protocols or port numbers. If your firewalls lets you see web pages (and which firewall blocks that!) you can access the application. So the user doesn’t have to know a thing, or worry about it. He just fires up his browsers, and enters a URL. Simple. Even better, since the application works in the protected environment of the browser, the application can be trusted and can never mess with the user’s system. No more can an application “slow down your system”, or “crash every once in a while”. Those complaints are a thing of the past.

The app architecture is transparent to the client

So, the programmers think that it would be a good idea to have separate data servers? Maybe split up demanding processes and push them to different computers to handle the job? Maybe they need a whole bank of a hundred thousand computers working together to do the job? This kind of architecture can be designed for optimum load balancing between servers. However this is entirely impossible with desktop applications. With centralized applications, it’s not difficult to construct and maintain such systems. In any case, whatever be the server architecture, the user doesn’t need to know or care.

Sure, web applications can never do some things that desktop applications can do – far from it. You will never be able to do a defrag through a browser. You can never run 3D modeling software through a browser. Browser based apps cannot replace system programs at all. Not for a long time to come, at least. However, for application programs, the desktop’s days are numbered.

Welcome to the show. Today’s act: The beginning of the end of the desktop.

---

Update: This post is now available in Russian. (Thanks, Alexander Kachanov)