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.

Re:Decentralization?

[Unordained]

I have yet to meet anybody that said their new web-based app whipped the llama's azz compared to the old thin-client or mainframe app

Unsurprising. Even with AJAX techniques to avoid refreshing the page fully, and even using JSON (maybe gzip'ed) instead of XML to reduce the traffic, and even with HTTP keep-alive to reduce the connection times, the technology used in web-apps today is still more "expensive" in terms of performance/latency than the older client/server methods. You build a 2-tier Win32 client with a direct connection to the database, and you've got a pure binary stream, composed of useful data and little else (vs. verbose XML, particularly); you don't have extra layers of webservers, you don't have a connection that starts/stops constantly, etc. You have the ability for the server to notify the client that something has changed, whereas with web-apps, you at best have something like Comet, and more likely have some sort of polling AJAX call. And the client's probably compiled, running natively, using hWnd's and whatnot; with web-apps, you may have the wonder that is javascript performing DOM updates that have to be interpreted and re-rendered by a multipurpose browser.

Of course it's less efficient. But as others have pointed out, that's not always the point. It's about control, it's about standardization, and ... oh, right, it's about control.

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

Re:SQL?

[mabhatter654]

But we can use Crystal Reports or Oracle Forms!!! Then we can install 1 Gig of software to be our "server" (in addition to the DB) and another Gig of software on the client... all to look at the SQL queries sitting on the DB server!

But wait there's more!

In most companies BIG IT supports databases and data centers. little it supports servers with department apps. It's all about the responsibility. An app that hogs a desktop PC and takes 5 minutes to start is the "users" or "it" problem, not management's. The same app in a datacenter serving 50 users poorly is now an "IT" manager problem.. and they'll demand the app fixed or toss the app out. Guess which group vendors like to sell to?

Re:SQL?

[bobetov]

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.

I'm not sure what kind of work you do, but as someone who is developing a lot of web apps right now, I'll say straight up that the data is the easy part. The internals of any system are well understood and the border cases are easy to handle.

What takes time, and what breaks, and what drives me nuts, is the UI - validation, layout, rendering quirks, etc., etc., etc.

I've recently started playing around with Adobe's Webkit-based AIR framework for this reason. It lets me interact with the local file-system, have a data store that's not reliant on a network, and above all, has a consistent UI environment.

"It's just data" is a data-centric way of looking at things, and is true in a sense. But the argument being made here is about the interface between the client and the data - not the data itself.

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?

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.

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.

[jbolden]

Not at all. There are are all sorts of very standard issues which render differently with AJAX based apps. Why do you think even the largest web app vendors like google and yahoo support certain features on say IE and firefox and not on Safari?

Re:No Shit.

[jbolden]

As one of those dweebs the reasons were simple. Cost of deployment. If you have a large potential user base with few actual repeat users (which is a very large group of apps) deployment costs per user can be intense.

For example take 1m potential users and 200 daily (or weekly) users with 50 of them ever repeating within any given year. Do you deploy a million or do 150 deploys per day to essentially random desktops?

Ahhhhhhh pontificating

[cthrall]

Note that many desktop apps hit web services or communicate via HTTP now, mostly because it's 1. easy and 2. SOA became the flavor of the month about a year or so ago.

Also, many enterprise web apps, at least that I've used, have some sort of plugin/JVM requirement. Are they a desktop app? Web app? Some awesomely funky in-between?

Personally, I think these "thick vs. thin" client discussions are a nice waste of time and excuse to get page impressions.

Let's deconstruct, shall we?

What sense does that make when any modern laptop packs enough CPU and GPU power to put yesterday's Cray supercomputer to shame?

Running Outlook and Office will immediately slow that poor laptop to molasses. Add a nice shiny .NET app, or worse, Java, and you've got yourself a tarpit.

Web UIs are a mess

You, my friend, have never used internally developed VB6 apps. I say no more.

Browser technologies are too limiting.

For some applications, I completely agree. But not everybody needs to see dynamic fluid modeling or stock quotes for 3000 securities in a real-time heatmap.

The big vendors call the shots.

Good call, time to turn to Java and .NET, which aren't controlled by big vendors.

Should every employee have a browser?...But if your internal applications are Web-based, you'll need to either host them onsite or maintain careful router or firewall rules to prevent abuse of your Internet services.

Because deploying and maintaining desktop apps across thousands of machines is wicked easy.

Re:No Shit.

[MightyYar]

I don't see why my comment doesn't apply? I know I went off on a bit of a tangent, but...

I think people are forgetting what a PITA it was with installed apps. Obscure bugs, difficulty in making sure everyone had the latest version, locked-down desktops that required IT to install the app, off-site users being SOL, platform dependency, etc. And, the BIG one, everyone in the company thought they were a VB wizard, so you had a bunch of crazy VB and VBA apps floating around without any real central control. At least with web apps you know everyone is running the same version and using the same settings, and there's some accountability for who's in charge of the thing because SOMEONE has to run the server :)

Re:Bring back a document-only based web!

[LDoggg_]

So says the guy that just posted to a slashdot thread. If slashdot.org was just a static document with links, you wouldn't have been able to send your message back to the slashdot database for other's to read.

Re:No Shit.

[QRDeNameland]

While that may sound good in theory, I have yet to see in practice where any web-fronted application had shown any lower deployment/administration/maintenance costs than a comparable desktop app. What may be saved in deployment (and many good enterprise desktop apps manage deployment nearly as transparently as a web app) seems to get eaten up by slow response and flakiness for users, network issues, web server issues, browser issues, and security issues. Admittedly, in many cases this is a matter of badly designed web apps, but in the world of commercial enterprise software, the quality of browser-based apps seems to be worse than the already pretty dismal quality of enterprise desktop apps.

Browser apps certainly have their place and can be the superior choice in the situations for which they are well-suited, but after the last decade of having way too many utterly painful browser apps forced upon me, I think the reasoning that led so many to the Kool-Aid tub needs to be reassessed.

Centralized Control of Standalone Apps

[EgoWumpus]

I think you're going to see an explosion of standalone applications tethered to a web-based datasource or back-end. iPhone and Android basically do this already - taking their cue from email programs since the dawn of the internet. Programs like Steam allow you to install local, fat clients through a thin client interface. Each of those pieces has a reason for being fat or thin, and you want to take advantage of that.

I think, in the end, the point is that you want to be confident your interface is usable where-ever, and that your backend can be swapped up without version issues, and that either way the program can do everything it needs to. The web is very good at the first two, it's just that the domain of problems it can manage has not yet expanded to the third. Is that anything but a matter of time?

Re:Response from L4C list

[serviscope_minor]

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

When software installation is so easy, and one's package manager downloads stuff using http, there is no real advantage in this case. Instead of searching on google, and going to a website, you search in pacman or yum or apt or synaptic and click on a "page" to load. As a bonus feature, it's much faster next time.

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

Do you not find it alarming that in this day and age, a program to sord 100,000 records is deemed impressive? On my machine (an eee 900):

time awk 'BEGIN{for(;;)print rand()}' | head -100000 | sort > /dev/null

Takes 0.7 seconds. By removing the stringification, and obvious inefficiencies,it would run much faster. In C++ is is easy to sort hundreds of millions of records in a very short amount of time using nothing more than std::sort and a suitable comparison function. The fact that in this area it is deemed impressive (and I have little doubt that it is) is a testament to a large step backwards.

Your other points stand, though.

Re:No Shit.

[hudsucker]

In my experience what happens is the opposite problem:

1. Corporate IT department decrees that all machines will only run WIndows, and will only use Internet Explorer, because that way there is only one client version to target.

2. Corporate IT develops (or buys from a vendor) a web based application. It becomes widely deployed.

Needless to say, said web application only works with IE. Why should it work with anything else? See item #1.

3. A new version of IE comes out. The widely deployed app won't operate with it, because it was designed to be dependent on ActiveX, and it is incompatible with IE version what-ever-we-have +1.

4. So, corporate IT decrees that no one using this application can upgrade IE until the app has been fixed and tested.

Which is why we are still using IE 6.

Now the interesting question is, what happens when we need to use two web apps, each of which has different (and mutually exclusive) browser version requirements?

The ironic thing is that if in step #1 they had said we can use any browser, on any O/S, then we wouldn't be in this mess, because the web apps wouldn't be browser version specific.