Slashdot Mirror
The Case Against Web Apps
snydeq writes "Fatal Exception's Neil McAllister offers five reasons why companies should re-consider concentrating their development efforts on browser-based apps. As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter. And while UI and tool limitations are well known, the Web as 'hostile territory' for independent developers is a possibility not yet fully understood. Sure, Web development is fast, versatile, and relatively inexpensive, but long term, the browser's weaknesses might just outweigh its strengths as an app delivery platform."
This story was previously posted to the L4C list. Here's the response I sent there:
An interesting, albeit unoriginal, take on the problem of WebApps. Unfortunately, I do not find his arguments very compelling.
Quite a bit, actually. First and foremost is the convenience of application access. There is no software to install and you can use your applications anywhere you have access to a web browser. In addition, the rise of web applications has spurred the rise of web services. Web services share out tremendous amounts of public information allowing developers to "mashup" (I hate that term) data sources to produce superior applications. Compare that to the desktop where just getting the programs on your system to cooperate is a challenge! (To say nothing of networking.)
FWIW, the author is propagating a misconception about web applications. His belief appears to be that web apps MUST push computing power to the server. Nothing could be further from the truth. Web apps are "rich" clients rather than thin clients. Rich clients are more than capable of accepting a significant processing load. Whether that be Video Games, Image Editors, 3D Engines, Fractal Explorers, or other compute-intensive applications, the client is more than ready to pull its weight.
I personally have written an application for my current employer that requires the client to dynamically sort a 100,000 record data set in nothing but client-side Javascript. Significant computer science had to go into creating an optimized, multi-threaded algorithm that would perform well on the lowest common denominator. (IE6) The next generation of browsers that are appearing (Chrome, Firefox 3.1, Opera 10, Safari 4) will have so much compute power that a problem like my 100,000 row sorter will become easy and commonplace. Furthermore, the standards are even adding true background threads to support long-running compute operations. (The standard is based on the Google Gears implementation, which is already available.)
The communications protocol is stateless. The UI is not. AJAX UIs know their state as well as any desktop application.
Anyone who lived through the development of GUI systems know that this is not a new issue. In fact, it used to be quite common for apps to eschew Windows controls in favor of something custom. Borland, for example, LOVED their custom controls. The rise of GNOME, KDE, Java, and .NET/Avalon/WFC have created just as many problems for the desktop.
That being said, flexibility appears to occasionally improve applications. Using GMail as an example, the design would be gimped rather than helped by a "standard" Windows XP look. The clean lines of the GMail interface manage to communicate a great deal of information without creating the sort of 3D visual noise seen in applications like Outlook.
Javascript is only one component to a very lar
Javascript + Nintendo DSi = DSiCade
Nonsense. Unless you're using bleeding edge UI widgets, a browser UI is quite easy to replicate accross browsers with the use of targeted CSS or simply thoughtful design. Even with a JS framework for your UI elements, browser diferences are simply not a huge consideration. Unless you want that ActiveX goodness...
Web-apps have their place but so do stand-alone clients a good developer will know select what is right for a given project. The moment you start using that 'ActiveX goodness' you have essentially created a WebApp that only runs in IE on Windows. Which begs the question why not just write a stand alone GUI client in .NET? That would open up a whole world of UI features ad behaviour web-apps can only emulate either clumsily, with difficulty or not at all. Then there is the security issue ActiveX brings with it. The only thing an ActiveX enabled web-app has going for it is redeploy-once-update-everywhere. The whole point of a web-app is platform independence and that went out the window with the 'ActiveX goodnees'.
Only to idiots, are orders laws.
-- Henning von Tresckow
That's why there are numerous ajax libs that give you a standard of cross browser support without having to worry about oddities. YUI is my favorite although there are others. All of their main controls work the same across all top browsers - very nice stuff.
That's why you have Java Web Start. It's as easy to deploy as a web application (it is just a couple of files on a web server), and you get the full goodness of a locally running application. And, since it's Java, it doesn't even take much effort to make sure it even runs on other clients than Windows desktops.