The primary tool of any programmer is the humble text editor. Almost every program begins life as source code which is for all intents and purposes, plain text. However, programmers spend a lot of time editing plain text and have thus developed very sophisticated editors to assist them in manipulating it efficiently. Today, editors like vi and emacs are very popular as are very large and complex editors called, IDEs. But what started as humble and straight forward, I’m afraid, has become disappointing and convoluted.
The recent trend in main stream software development has been the reinvention of every known piece of software as a web application. It doesn’t seem to matter how sophisticated, ubiquitous, or useful any piece of software is. If its possible to turn it into a web application it’s instantly better in every way — users don’t have to install anything, the software is available from any computer with a browser and an Internet connection, and if Bob isn’t you’re uncle; he is now.
The reality is that the panacea of computing promised by web applications is a lie. Nothing is perfect and there is a nervous resistance to admitting the faults inherited by web-based applications. The Internet is nothing if not a great soap-box full of self-congratulatory hipsters and adoring fanatics. I am going to break through the hype and discuss the truth.
First of all, there are good web applications in existence. Web-based email clients are a great example. They allow access to your email to be ubiquitous for those situations where you don’t have access to your personal computer. A secondary benefit is for users who do not know how to install and configure their personal mail clients — they don’t have to configure anything more than a user name and password. This is useful because email itself is becoming a de facto communication medium that has to compete with easy to use technologies such as the telephone. It has to be plug-in and go otherwise it will lose out to the communications technologies that already are. And for the most part, many web-based email clients are able to adhere to standards which allow a wide range of browsers of varying capability and utility to use them. Other situations where web applications are useful: sharing documents, identity presence, search and indexing, and cataloging. Anything where the primary function is the retrival, submission, or communication of information.
Then there are bad web applications. These are typically reinventions of existing desktop software that pose no compelling benefit over their desktop counterparts. It’s almost as if they were developed simply because it was possible. Things like spread sheets, word processors, graphics manipulation, illustration, and now even text editing. They promise zero-installation and the ability to access them from any computer. And because they are web-based applications, they assume that they will inherit the collaborative properties of the Internet (or at least inherit the hype).
The zero-installation claim is usually true. If the web application in question is publicly hosted and available to anyone, then the user really won’t have to install anything but a web browser. However, for those web applications that expect to be installed then the zero-installation claim is a very big fat false. Web applications by nature of their design are generally complicated to install and configure for the end user. The big gotcha is that applications you trust someone to host might disappear when the person or company hosting them pulls the plug. Thus we must be wary when we hear this claim.
The promise of access to the application from any computer with a web browser is a lie. The original design goals of the Internet in terms of accessibility were far more promiscuous than what these web applications assume. Typically the complexity of interfaces required by some of the more “sophisticated” web applications require a capable browser. This harkens back to the days when web pages were designed for specific browsers. This walled-garden approach requires developers to pick which browsers their application can support and leaves everyone else on the Internet in the dust. Either you drink the kool-aid or you stay out of the pool.
The assumption that simply because they are web applications they will automatically inherit collaborative properties is a false one. Applications do not require collaboration. When I am sitting infront of my emacs editor I am not desiring someone to be reading over my shoulder or editing my text with me. It’s my data that requires collaboration and there are already plenty of ways for me to share it with others: email, SFTP, removable media, wikis, version control systems, ticket systems, etc. I suspect you’ve never seen a situation where two carpenters needed to share the same hammer at the same time. The same goes for these sorts of tools as well. We collaborate on data, not tools.
So finally we come around to the much-hyped spawn of web-based IDEs. These are tools that make all the claims that I have mentioned and tore apart. Bespin, Heroku, and other types of projects are neat but only so far as how technically challenginging it must be to develop them. Pragmatically, I believe they are absolutely useless and a waste of time. Not every problem that has a solution need be solved. There are already far superior text editors and IDEs available for every computer in existence.