The Case Against Web Apps 431
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."
Response from L4C list (Score:5, Informative)
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 [wiicade.com], Image Editors [pixastic.com], 3D Engines [xs4all.nl], Fractal Explorers [2tap.com], 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
heh (Score:3, Informative)
AJAX is not the be-all of internet applications. There is also Adobe Flex and Microsoft Silverlight.
I find most sorts of apps work fine with standard AJAX controls, but Flex isn't hard to learn if you need more sophisticated UI in your internet app.
Not the most balanced article... (Score:3, Informative)
As McAllister sees it, Web apps encourage a thin-client approach to development that concentrates far too much workload in the datacenter.
For sure, there are some applications that make sense to run locally; or to use special local software in combination with a server, rather than a web-browser-based interface. 'World of Warcraft' won't be implemented in AJAX any time soon.
On the other hand if you want to sell 'software as a service' it's going to be easier if you're supplying ongoing services other than fixing bugs of your own creation. Furthermore, in stagnant markets (*cough*MSOffice*cough*) it could enable new features compelling enough for people to upgrade. What's more, a dependency on your data centre makes piracy practically impossible.
Not everything suits being on the web, or in the web browser. But the benefits to software companies are hard to ignore.
Browser... OS... What's the Difference? (Score:2, Informative)
The fact that the different browsers render basic sites differently should be warning enough. Add to that different versions etc; You will never have a standardised audience to utilise these. It will always be lowest common denominator.
By the same logic, one shouldn't program at all. After all, different operating systems handle the same source code differently. Add into that different versions, etc; you'll never have a standard audience and therefore all programs everywhere will always be the lowest common denominator.
Srsly, browser rendering is a well specified standard. To claim it's a barrier to good software is silly.
Re:No Shit. (Score:5, Informative)
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'.
Re:Java applets for serious web apps (Score:3, Informative)
Re:No Shit. (Score:1, Informative)
IE, as of 7 still had problems with translucent div's overlaying select boxes with the select boxes bleeding through.
This is marked in their database as "by design" or what-not and their recommendation is to iframe it or make it non-translucent.
Joy. Things should work and not have unintended side-effects.
AJAX cross browser libs (Score:5, Informative)
Re:... and so what? (Score:3, Informative)
Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term
That's not even entirely clear. There are multiple attempts [lifeclever.com] already to provide something like Photoshop in a web application, including one from Adobe [photoshop.com]. Now I don't expect most graphic pros to abandon their client version of the application, but it's also not as though there aren't web based graphic editors.
Re:No Shit. (Score:5, Informative)
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.
Re:Java applets for serious web apps (Score:3, Informative)
In that case, I would recommend that you look to Java Web Start instead. It's as easy to deploy as an applet, but the user gets a real, stand-alone application instead.
Re:No Shit. (Score:3, Informative)
2) Web apps are harder to deploy. That is simply false.
Note that I never said that web apps were harder to deploy, only that in my experience the argument that web apps were significantly less costly to deploy, administer, or maintain has not been the case. Again, *in theory* they should be, but after a decade of involvement with the rollout and maintenance of dozens of enterprise apps (both desktop and browser) to thousands of users, I've never seen the payoff. YMMV, but I know I'm not alone in this assessment.
Re:No Shit. (Score:3, Informative)
exe vs. php (Score:2, Informative)
While browsers were readily sitting on all these computers.
Switching to server-client brought some sanity back into my life.
Certainly the network should be policed to make it secure. No helmet, no body armor, no steel door makes a security. It's just a part of it.
Server overload? 4 cores, 12 GM RAM, 2 TB hard disk are overloaded? Check your code and especially queries. Say, if in PHP you are to get an integer do only casting $a=(int)$_POST['a']; no further sanitizing is needed. Casting is non-function operation and requires little computing. Limit queries. Writing good queries and sticking to efficiency and security philosophy on a server may make an application work.
One more thing, vote for politicians who use Internet and pledge to protect it.
Re:SQL? (Score:3, Informative)
So unless there's an extremely good reason to install a desktop app (e.g. you really need complex local interaction, or are dealing with huge data such as video) why bother installing desktop software?
I've given one reason where installing a native app is worth it - the validation of complex user input - and that's certainly not the only positive.
I'm currently contracting as a UI developer working on an internal business application. The application isn't trivial and *could* be written as a web app but that doesn't mean it should be - and don't think they didn't consider it. The interaction that would have to be handled would be a nightmare for the user and it would probably get ignored and the million or so spent developing it would be wasted.
So I guess the moral of the story is that it's a case by case basis on whether to go to a traditional app or not. I think Flash/Flex and Silverlight are good middle ground since you can still run it in a browser but have rich client capabilities. The installation for those is very easy and some pretty impressive things can be done with them. Java certainly dropped the ball on this with regards to applets and webstart. Once you are past the more complex (compared with flash/silverlight) JRE installer, applets work and perform fine, but webstart isn't transparent enough, there are too many dialogs and download windows that pop up when starting up the app. That confuses a user and as a developer I find it ugly and annoying.
Installing and managing desktop applications is extremely expensive compared to browser-based app's.
I wouldn't say installing any traditional app is extremely expensive. It's no more cost prohibitive then making sure everyone has the same browser version. A little extra time installing could save a lot of productivity that a properly written native application can give you.
The rule everyone should follow is that, in the end, it's all about the user. If they are better served with a web app then that's what they should get, and the same goes for a traditional app. The author seemed to be saying that with the current buzz around web apps, like Twitter, Facebook, the ton of Google offerings, etc., some things are being developed there that really have no place on a web page.
Re:No Shit. (Score:3, Informative)
Actually, that is not quite true. Every time the user runs the JWS program locally, the JNLP client connects to the server to see if there's a upgrade available. It's even so good that it simply does the check per JAR file, so the program is upgraded very quickly, as only the files that have actually changed are re-downloaded.