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."

Comments

Decentralization?

[Anonymous Coward]

I thought decentralization was supposed to be a good thing, the whole motivation behind having personal computers to begin with but, in the age of web apps everywhere, we seem to be returning to the days of the totalitarian, you'll-do-it-our-way-and-like-it data center (mainframe) model.

Re:Decentralization?

[MightyYar]

I thought decentralization was supposed to be a good thing

It has its good and bad points, like most things in life.

the whole motivation behind having personal computers to begin with

The original motivation was geeks playing around. The main reason they originally started showing up in businesses was VisiCalc, which simply wasn't available in any other form except chalk boards.

we seem to be returning to the days of the totalitarian, you'll-do-it-our-way-and-like-it data center (mainframe) model.

Except we aren't. Even a netbook is smarter than a TTY terminal. Plus, with the internet you aren't tied to a single mainframe. You can do your web email with Google, your web search with Yahoo, and your web word processing with Microsoft. The old mainframe way would be if Comcast supplied email, search, and document creation and you did not have a choice to go out and use other providers' services instead.

What you are seeing is a move towards web apps where it makes sense (email, document sharing, social networking, etc.), and people sticking with local applications where it doesn't make sense to go to the web (video or photo editing, most office documents, etc.) - anything where the bandwidth or latency requirements become too much of a bottleneck.

SQL?

[spikedvodka]

in this modern day-and-age, most stuff is just data anyways, and that is all database. Moving to a true client architecture, oh wait, all the data is still stored centrally, and most reports are all done via stored procedures.

Even with true clients, much data processing is still done in the datacenter. maybe some advanced analysis is done on other machines with a data dump, but still... it's all data

True, but people will not listen

[gweihir]

While I think the arguments against web-apps are valid, it is the newest trend and people will not listen. It will require a few very expensive catastrophies, before something happens. And then people will still not undterstand what the problem is, just that there were expensive catastrophies.

By now I believe most technological trends are not rational.

Re:No Shit.

[MightyYar]

The fact that the different browsers render basic sites differently should be warning enough.

Why would switching to a native app help you here? If the user can't be persuaded to install a compatible web browser, what makes you think that they will install a standalone application?

... and so what?

[ThousandStars]

Those all might true, but so what? The advantages outweigh the disadvantages, and web apps are improving all the time. Paul Graham already wrote about the issue in The Other Road Ahead, and Joel Spolsky wrote about them in How Microsoft Lost the API War. He enumerates problems and things that, at the time of the article, you couldn't do with web apps:

Create a fast drawing program
Build a real-time spell checker with wavy red underlines
Warn users that they are going to lose their work if they hit the close box of the browser
Update a small part of the display based on a change that the user makes without a full roundtrip to the server
Create a fast keyboard-driven interface that doesn't require the mouse
Let people continue working when they are not connected to the Internet

These are not all big issues. Some of them will be solved very soon by witty Javascript developers. Two new web applications, Gmail and Oddpost, both email apps, do a really decent job of working around or completely solving some of these issues. And users don't seem to care about the little UI glitches and slowness of web interfaces. Almost all the normal people I know are perfectly happy with web-based email, for some reason, no matter how much I try to convince them that the rich client is, uh, richer.

And these issues shrink all the time. I agree with Joel regarding rich clients--I use Mail.app for e-mail, but virtually no one else I know does. Photoshop and Final Cut Pro aren't moving to the web anytime in the short to medium term, but other apps will, and it's hard to see this guy's ideas mattering. Sure, they might be true, but the web is still more convenient. For me, it's become a central repository for book and other commentary in the form of The Story's Story and write about grant writing at Grant Writing Confidential. Yeah, I write my posts in Textmate, but most people don't--and most people aren't going to buy and install Textmate.

Keyboard shortcuts and CLI

[sbillard]

My biggest complaint about browser/web apps is the inconsistent or non-existent ability to navigate the app with the keyboard.
While fat client apps can have messed up tab stops, they're generally better than their web-based counterparts. A CLI is even better allowing for things to be done in bulk/batch.

I've got over 100 buttons right at my finger tips. I shouldn't need 2 more that roll around (FPS mouselook not withstanding). Let me ALT+whatever and TAB my way around.

YMMV.

Mobility is the factor

[ballwall]

Right now web apps are king because they're always only the nearest computer away, and work on almost everything.

We're getting close to devices that provide the same functionality in a mobile form factor. Once everyone has an iphone like device that has a standard development environment we'll likely see a resurgence of local apps. But that's probably a years away at best.

Right now, you can either develop for the web, which will work everywhere, or write one app in Win32/.Net, one in Objective C for Mac, one in Java with Blackberry specific apis, one in Objective C for iPhone, one in [whatever palm is up to], one in .net for winmobile, etc, etc etc.

The only reason client side apps were ever written was because you could be fairly sure windows was your target, or it simply wasn't feasible to centralize and so you forced a standard environment.

There's no single platform anymore, and probably won't be for a while (and when it comes it'll look a lot like a web browser), so the only viable option is web based.

Does it suck? Yes and no. It's definitely better than debugging an app on 40 different platform/cpu/os version combinations.

Response from L4C list

[AKAImBatman]

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.

What sense does [Thin Client technology] make when any modern laptop packs enough CPU and GPU power to put yesterday's Cray supercomputer to shame?

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.)

Concentrating computing power in the datacenter is fine if you're a Google or a Microsoft, but that approach puts a lot of pressure on smaller players.

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 Web's stateless, mainly forms-based UI approach is reliable, but it's not necessarily the right model for every application.

The communications protocol is stateless. The UI is not. AJAX UIs know their state as well as any desktop application.

Buttons, controls, and widgets vary from app to app.

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.

Why give up the full range of languages, tools, and methodologies that systems programming has to offer? JavaScript has evolved into a respectable general-purpose language, but it can hardly be expected to be all things to all people.

Javascript is only one component to a very lar

Mixed response

[nine-times]

I think there are some valid points and some invalid points. My general response:

• 1. It's client-server all over again: Yeah, it is. We keep running up against this because doing things on the client has some advantages, and doing things on the server has other advantages. The debate will continue, because it's really not an issue of one being absolutely better, but choosing the better solution for your specific application.
• 2. Web UIs are a mess. & 3. Browser technologies are too limiting: These are really the same thing. Web apps suck. This may improve over time as the technology improves and new standards are put into place, but right now, they do kind of suck. If you can't deal with that, you don't want a web app.
• 4. The big vendors call the shots: a real objection. Do I want my ability to access my own documents/information to be at the mercy of another company? That's a question. worth considering.
• 5. Should every employee have a browser?: Meh, whatever. Every employee has a browser, and it's more trouble to remove them than it's worth. If you don't want people browsing the web, put up a firewall that can block/filter traffic. That's a better solution anyway.

Re:No Shit.

[nyvalbanat]

You're not thinking multi-platform. There's more than one OS out there, each with a completely different set of UI api's. Browser discrepancies are a joke compared to that.

Re:No Shit.

[Savage-Rabbit]

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:No Shit.

[AKAImBatman]

The moment you start using that 'ActiveX goodness'...

...you should be shot.