There is a common misconception that web applications are the way of the future, and the “way to go”. Most companies are convinced that moving their systems to web technologies like DotNet and Java Server Pages will ensure that they are not left with “old technology”. I, however, envision a future in which all applications are not web applications at all. Perhaps the science fiction writers missed the boat completely, but I don’t see any browser type applications in Star Trek or Star Wars. In all seriousness, the only advantages that web applications have over desktop applications are ease of installation and platform independence. In certain circumstances, these advantages can be diminished by the nature of the installation, and the availability of software tools that can generate desktop applications for multiple platforms.
The platform independence of Web Apps is greatly overrated. Even within the same platform, web apps behave differently on different browsers. So, instead of testing the application on the one platform, now you have to test it on multiple browsers on the one platform. Then you have to test it on multiple browsers on other platforms. If a cross-platform tool is used to develop your desktop application, it needs only be tested once for each platform. This development tool should be able to generate binaries for different platforms with little or no change to the source code.
Web applications are more susceptible to security threats than desktop applications. You can mitigate this by using Secured Socket Layer, but there’s not much you can do with the ability of the users looking at the source code of the HTML through the browser menus. In addition, if you decide to hide the URL address bar from the users because you don’t want them typing something in there and thereby shooting themselves in the foot, the danger is even greater. If you can’t see the URL of the website you are on, it is easier for malicious code to masquerade as your application. Pop-up windows can also pose threats to web applications, as malicious code can masquerade as part of your program. Desktop applications can use SSL for HTTP connections, and other means to encrypt data going across the wire. In addition, it is extremely difficult to hack into the desktop application’s executable file.
Developing web applications is much more difficult than developing desktop applications. Generally, web applications are stateless, which means that every time a web page is posted to the client, it’s lost all memory of what was done before. Therefore, it is up to the web server application to maintain state or keep the state in the HTML code, in which case the HTML sent back to the client can be huge. Managing this state of affairs (so to speak), gets complicated. In addition, since data can only be displayed via HTML, web applications have to “emit” HTML, and it is difficult to display the data correctly this way. There have been HTML code generators written to address this complexity, but it is nevertheless an issue. Desktop applications, on the other hand, can be developed with RAD (rapid application development) tools such as Delphi and DotNet Winforms, in which the application has state, and does not rely on a server (in two-tiered systems) to manage state. Using RAD, forms and windows can be easily created, even if MVC (module-view-controller) is used as a software pattern.
The performance of desktop applications is generally much better than web apps. This is because each web page has to be rendered by the browser, and it takes a longer time if more state is remembered between each push and get of the pages (when the HTML gets huge). Also, in addition to the data that is being sent to and from the server, display elements are going across the wire, and so the amount of data going through the network is quadrupled. Desktop applications, on the other hand, only sent data across the wire, since the display elements are already loaded in memory on the client machine.
In conclusion, I believe any complex computer system should be developed mainly as desktop applications, with auxiliary web applications for support where it makes sense. It does not make sense to develop the whole system solely as web applications. If a centralized solution is desired, this does not preclude desktop applications. Desktop applications can access data and web services centrally via multiple tiers.