Why are web apps prevalent for internal corporate apps?

Question

OK, I realize that people don't like to install stuff on their PCs if they don't have to and that is the primary advantage of web apps over "desktop" that run locally.

But for corporate internal applications where security is not an issue, if an application is such that its user base has the app up 100% of the time, using it exclusively as their primary tool, wouldn't a desktop app be a better choice?

I don't have any experience/know much about WPF web applications, but my impression is that it is essentially an application that is running locally on your Windows PC. I am more familiar with what is probably older technology, WinForms, specifically, deploying a WinForm app via ClickOnce technology.

It seems to me that Click-Once (and presumably WPF Web Apps) have, for practical purposes, solved the dll hell deployment issues of the past, yet it seems to me that the appeal of using Web apps internally was to avoid the dll hell associated with local installations. Yet, with this problem solved, why do companies still avoid/fear apps that involve local installation and gravitate so quickly to web apps?

It seems to me that the advantages of desktop apps are

1) COST - Desktop apps are just conceptually simpler because you have the full resources of the local machine and you have state. As a result, desktop apps GOT TO BE much cheaper to develop for the same functionality. Just look at all the complicated client side/server sided Ajax fancy code one has to go through to do things that would be trivial in a desktop app. I picture people disputing this point but to me it is obvious and beyond debate.

2) Desktop apps are typically richer. Web apps are at best comparable at the expense of more complicated / more expensive to develop code. (a corrolary to 1)

I can list more, but these should be enough...

Obviously desktop apps wouldn't be appropriate for all internal web sites. But take this as an example and tell me if you think a web deployed desktop app is the better choice:

A Help Desk application used 8 hours/day every day by the users and is the only app running on their PCs. Furthermore, application is patched seldom.

My feeling is that people get in a rut and once they know something (eg, web apps) it is the solution for everything. What do you say?

Edit #1: Here's an example of a Click Once desktop app (an integrated front end for Rational Clearquest/Sharepoint/PVCS/Mercury for managing problem tickets) that takes advantage of the computer power of the client to store information locally and let the user slice and dice the data in different ways w/o hitting the server each time while still allowing the user to link real time to the live data to update individual records. It's kind of like a spreadsheet download that maintains links to server data should the user want to perform an update.

Sure you can imitate this functionality on the web but I think that the the dev effort would be much greater and you wouldn't get this type of responsiveness which would be important to a user that spends a lot of time in the app.

Practicable

You're making a lot of assumptions, e.g., that they're "seldom" updated and that there's no cost to having many people running different versions at once. Companies tend to act to reduce risk, and that may even be seen as their primary purpose. Betting that in-house software won't require patching is inviting risk, not reducing it. – Norm

I can't agree with your "desktop apps are cheaper" assertion. You're predicating that based on "complicated fancy Ajax", but you're forgetting about all the other things that raise cost: must install to many machines to be useful; must occupy orders of magnitude more memory to do the same level of work (e.g. a 10 MB desktop app x 500 users is much more memory than a 300 MB server app); and a host of other factors. Furthermore, desktop apps age much more quickly, whereas web apps tend to be leaner and work better over a wider range of systems. – Salad

I don't get the general memory argument you're making. Assuming your premise that the sum of all the memory used for all the desktop instances is greater than the sum of the memory used for the same number of users connected to a web app, my response is: "So what?"-provided that we don't impact the PC's local performance. – Practicable

Good pt about assuming seldom releases. One shouldn't assume this. But as mentioned elsewhere, even frequent (once a day) patches shouldnt be a big deal with high speed intranets where the deployments are done in small dlls increments. – Practicable

"I picture people disputing this point but to me it is obvious and beyond debate." Ha! Thanks for keeping an open mind. – Accomplished

FYI... WPF apps are just another type of desktop app that can be deployed via Click-Once. The exception is if you build an WPF XPAB app, which is always hosted in a browser. – Vashtivashtia

For Laurence Gonsalves: Yeah, I figured that would get some people. I was egging on debate. I've made this pt to many people and am really surprised that people debate this. To me, its obvious. Somebody's blind. It may be me. – Practicable

web apps are platform independant and can easily be deployed everywhere, even on mobile devices. due to a lot of web technology toolsets and frameworks, web app developement is in no way more costy. usually, its easier to develop, since the approach is usually signifficantly more highlevel. i personally doubt there's any good reason why desktop development should be faster or cheaper, when it comes to corporate apps. you just need to use good libraries and frameworks, instead of writing it all by hand - as you would do with desktop apps. or do you know anyone writing his apps from scratch? :P – Gemperle

"patches shouldnt be a big deal with high speed intranets where the deployments are done in small dlls increments" -- are you assuming the cost of deploying a patch is the cost of the bandwidth required to distribute it? – Norm

Ken, I guess I am looking at it from a pt of view of how much of an inconvenience it is for the end user to wait for a patch to be installed. In my helpdesk scenario, or another real-life scenario of mine, an app used by collectors, both user groups have their respective app that they run as there primary tool. When patches are rleased, usually once a month, it usually takes about 10-15 extra seconds longer to bring up the app longer than just starting up a local copy of the app w/o download any patches. From a user's pt of view, they don't even notice it. – Practicable

Ken, I would also pt out that if we are looking at a large user base, that the network traffic would decrease with fat clients since web apps have to transmit the page layout each time, not just the data and because fat clients can permit some operations w/o making a trip to the server. – Practicable

back2dos, I think web centric developers need some serious examples showing how easy it is to do things in a desktop environment. Web development is just getting out of its infancy with its hidden text boxes, viewstate and cookies and ugly javascript/server interaction. Web functionality strives to approximate what has been done long ago on the desktop and when it doers accomplish it, its usually an order of magnitude more complicated and ugly. Users expectations have always been lower for web apps then with desktop ones. Finally as tool make it easier, their expectations are rising. – Practicable

Fat client apps often use MORE bandwidth than web apps, not less, or if not more bandwidth volume, then more bandwidth latency, which is a huge problem especially on slower/high latency network links, because far too many developers tend to create really sessions with resources like database servers. – Fornication

I meant to say "...far too many developers tend to create really chatty sessions with resources like database servers." – Fornication

Answer 1

Why are web apps prevalent for internal corporate apps?

Primarily because the centralized deployment model of web application solved the deployment nightmare of old fat client applications (machine specs, available libraries, drivers, etc). I've seen companies where, when they were done with the deployment, the last machine installed was already two version ahead the first one. With a browser on the client side (i.e. a cross-platform execution environment) and centralized deployment, you just wipe out these problems. Welcome to the thin client era.

Now, I'm not convinced that desktop application are typically cheaper (I don't know if the development is cheaper but I'm sure maintenance, support,... are not).

I however agree that Desktop applications are typically richer. Regardless of what people will claim, this was not arguable before the AJAX advent and this still applies in some specific areas where a browser is just not appropriate, with or without AJAX (ask a trader to use a browser and you'll see). Some people do not want a page flow paradigm, some people do need advanced widgets (e.g. a grid component with advanced filtering, grouping, Excel like features like basic formulas, etc), or low latency, or real time, etc i.e. things that a Rich Internet Application - or RIA - is not really made for and is thus not the right tool to choose!

And I agree too that technologies like Java WebStart or Microsoft ClickOnce do solve the old deployment problem and allow the development of so called Rich Desktop Applications - or RDA - (rich desktop UI on the client, business on the server, standard protocol between them and centralized deployment, so still a thin client) which seems to be an excellent compromise (better user experience but without headache).

So why do people systematically omit the RDA option? Well, I believe that:

1. We (IT professionals) have taught people how to create internet applications so they just (re)do it.
2. It's already complicated enough to explain Internet, thin client, AJAX, RIA, etc and there is not much evangelism on RDA. So most people just don't know what RDA are.
3. We (IT professionals) constantly say something and its contrary: don't use a fat client, it sucks, use a thin client, it rules, don't use javascript, it sucks (pre AJAX era), use javascript, it rules (post AJAX era), don't use a thin client(!), it sucks, use rich desktop application, it rules and so on. Even if there is logic in this, this makes some concepts (like RDA) hard to sell to non techies at the end.
4. People don't forget bad experiences that easily (fat client) even if things have changed since then.
5. People actually don't really need RDA in let's say 95% of the situations.
6. There are more RIA developers than RDA developers.

So it's our (we, IT professionals) fault :)

Offing

Damn good response! I think you have zeroed in much better on what I was trying to say than some of the other responses, which also make valid points. My experience is that when web apps are developed, they almost always are clunkier and require more elapse time traversing screens, one at a time, to perform the same function that a good rick desktop app can do. If you spend a lot of time in the app as in my Help Desk example, you will want an app that let's you get things done fast and efficient. Imagine if Vis Studio were a web app and if it were a good one, the effort involve in writing it.. – Practicable

@Velika Thanks. And I agree with you: as I said, there are many areas where desktop apps will be more usable, fast, appropriate than web apps. This apply often to helpdesk, CRM, financial, call center applications (especially true when speed = money). And, well, even if gmail is incredibily great, not everybody is Google. – Offing

+1. However I don't agree with the part on desktop apps. if you throw enough hardware (which is cheaper than developers or admins) and a decent browser on a computer, than it will be able to do about anything in javascript a corporate desktop app would do ... alternatively, you can use silverlight, flash or air or anything else ... check out aviary phoenix for a mature web image processing app, or sliderocket which even outrules the desktop alternatives when it comes to collaboration ... – Gemperle

@Gemperle This goes beyond my competences and knowledge but I'm still not convinced. 1. JavaScript is a poor language compared to C# or Java 2. Many companies don't have the skills to write the kind of apps you are showing (which are nice btw) 3. I'm not sure but are Flash, Silverlight, Air printer friendly? No, really, I still think that we are trying to use browsers for things they've not been thought for (a browser is not an OS). – Offing

1. use GWT if you like Java more than JS. Compared to JS, Javas "reflection" (which actually is introspection) is a pain, real reflection is not possible and it lacks support for functional programming. JS is a great language, it's just that people don't understand it and use it to produce a lot of crap. C#'s features are definitely cool, but C# is less portable (which of course isn't the language's fault). 2. Many companies don't have the skill to produce any decent software, be it for the web or the desktop. 3. As always: using the right libraries will do the trick. ;) – Gemperle

"a browser is not an OS": very true ... for now. have a look at Chrome OS or ES OS. I agree JS and HTML/DOM are not the best of available technologies. yet the basic concept is robust and clear (and there are many good branches). and it's the most standardized thing out there, when it comes to GUI developement. but from the point of view of a web developer, the OS is the browser, since that's as close as he'll get. this is both a blessing and a curse. but many people choose to live with it, appearently. – Gemperle

"Many companies don't have the skill to produce any decent software..." (emphasis mine). True that. – Fornication

Answer 2

Web applications are prevlent for many reasons:

1. Its easy to secure
2. It creates a standard point of reference that everyone can access:
3. Does not lockout people using different platforms.
4. Easier for people to access from outside the network (it puts the security issues to the routers/vpn etc)
5. Less tech support (standard running platform)
6. Easier to support (if it goes down then you have a critical response team that can fix that, rather than 1000s of machines that randomly go down)
7. Central point of storage of data (easier to backup and access)
8. Can scale better
9. Its easier to build or reuse an enterprise framework than to find/create a distributed component set to work with a changing environment (LDAP, different dbs, different backups, synchronization)
10. Less subjected to attackers (worms, people modifying the client etc)
11. Desktop clients may sometimes have hard coded environments, or require certain tool sets which make new users a pain to setup
12. Its cheaper to deal with a server rather than 1000s of clients. You can setup the systems to be reductant and have a quick failsave. Yes the server equipment costs more by a factor, but it costs less to maintain in the long run.

Horthy

All of these plus all of @Gabriel's. +1 to both – Gerick

+1 for outside the network...remote workers, contractors, telecommuting, etc. Very important. – Aldosterone

referring to your pts by #: 1-Hmmm. Maybe. 2) Same with click once and wpf web apps (3) In a corp env where all the users are on Windows, not an issue (4) We're talking internal apps vs. internal web apps, either way you need vpn. No easier for one over the other. 5) Yeah, more opportunity for individual problems, but much less than there used to be. In 6) Not sure where to begin with limited space but don't buy it 7) The data in on the server in both cases 8) I certainly don't believe this, as we can better utilize the client machines – Practicable

If you were able to pause time your point on 3 is correct. Vendor lockin is a big issue and organizations change. IBM adopted linux bigtime. Governments have a habit of switching vendors. 1. Programmers are not security experts. 2. You'll have versioning issues like before. 4. You can't always guarentee the client, and you have to do special testing for network situations on the client app. 5. when you create something from scratch you create new problems 8. your point would be correct if you were able to take care of idle processing resources. – Horthy

We apps are not easy to secure. – Artiste

If its an internal app then you can lockout access from the outside world without vpn. Its certianlly a lot easier. Also with web apps you have prexisting frameworks that allow you to connect to authentication services. – Horthy

Web apps are, at the very least, no less easy to secure than rich client apps. – Fornication

Answer 3

I agree that Web apps are not faster to develop -- unless you have more than one OS to support, or a database connection, which applies to basically everything I do.

1. 20% of my users aren't running Windows.
2. 100% of my users want to use the intranet apps from home.
3. 100% of my users want to see their personal data no matter where they're connecting from.
4. Nobody likes to be told "please wait while we upgrade you to version 3.0.1"

Document creation programs (including graphics programs) are clearly more appropriate for the desktop, despite what Google Docs would have you think. You wouldn't want a sound or video editor running remotely. But the less personal the work -- the more collaborative (corporate) -- the more webapps make sense.

Parachronism

1) The premise was that all the users are running Windows (2) Not a problem, I run internal ClickOnce and web apps from home. (3) huh? (4) Better pt, but with fast internet connections of today and deploying patches in small chunked up dll fixes, patching can occur hardly noticed by the user. If we did a release every day, this would add 5 seconds to my user's day-the 5 seconds when they are starting their day and getting a coffee while they open the app. – Practicable

Re: "But the less personal the work -- the more collaborative (corporate) -- the more webapps make sense." Me: I don't see why web apps are better at collaborating than desktop apps. – Practicable

(3) Even though I don't like Google Docs, it's a way of having access to my in-progress work from anywhere, so I do use it. Even though I like Thunderbird, I can't install it on every machine I sit down in front of and end up using a bunch of Webmail interfaces. I would much prefer a web-based equivalent to Thunderbird. – Parachronism

Here's an actual example: let's say I'm designing a CD package. I'm trying to collaborate with the client (who's in Philadelphia) and the person writing the liner notes (who's on the road). Right now I have to create PDFs and ship them to the others via email for their feedback. It would be MUCH better if I could have them open some version of "InDesign Web" and see my changes immediately. (They may already have such a thing, of course -- I'm a little behind the curve.) – Parachronism

For me, most web apps don't even have "releases". When somebody reports a bug, I just fix it. If I have a feature ready and tested, I just put it out there. – Parachronism

@ChadD Absolutely. (3) has absolutely nothing to do with web versus native development. Any app can access remote data. Consider: a web browser is a desktop app. Every time a user requests your URL, it downloads the latest version of your javascript libraries and compiles/interprets them. This is, essentially, a patching solution. There is no reason why such a nice, unobtrusive solution must be exclusive to web browsers. The web was designed to download documents over HTTP, period -- we were never meant to be doing all this AJAX nonsense, and I really hope we see less of it in the future. – Tolbutamide

Answer 4

• Faster development time
• Ease of deployment (you'll probably deploy a few times)
• Some corporate IT groups do not allow users to install applications

****Edit****

• Easier to guarantee app-to-database network performance
• Database is more secure
• Easier to explain how to launch the application
• No need to store or install extra libraries (usually)
• Easier to maintain (by both developers and IT)

Confederation

Web apps AIN'T faster to develop. I expected people to say that they are no slower-and this I do not buy in the leasty-but they for sure hell ain't FASTER to develop for experts of both approaches. – Practicable

I agree with Velika: You have a lot of platforms that you have to target, and web development lacks stateful transactions. – Horthy

@Steven: There's value in it being stateless – Confederation

Because it is stateless you have to hack it to keep persistance, which each of those have related problems associated (cookies, viewstate, get requests, session tracking) – Horthy

You can have state in web apps -- that's what the session is for. But I agree with Gabriel, web apps are considerably less complex if you can keep them as stateless as possible. – Jojo

Re: "@Steven: There's value in it being stateless". Sure, if you are Amazon.com, you can't possibly keep track of state on the server. But if the client can do it for you, you have all sorts of advantages. – Practicable

Most internal corporate apps are NOT Amazon.com. – Jojo

@Velika - I would argue that an agilely developed web app can be developed much faster and with greater accuracy than a traditionally built app. I don't have any metrics to back it up, this has just been my experience. – Gerick

@Kaleb: Session is not included in the HTTP header, thus you have to hack it to be apart of it. – Horthy

I don't think that using a cookie or a HTTP request parameter to id users is that much of a "hack". – Jojo

You have to repose that request parameter each time, you have to manually keep track of the state. – Horthy

About "Easier to guarantee app-to-database network performance": Major point there! Web apps do database connection pooling. I'd much rather have 100 pooled database connections than 20,000 individual ones coming from each desktop. – Frowst

@Steven: the session parameter is taken care of for you by any major web app server. If you have to manually do it (as in write the code to do it), then you're doing it wrong. – Jojo

To: ux9i: Even if the Conn.Open" command is executed in the client, I don't think this means that you are not using connection pooling. Even still, db IOs can be done from a web service called by the client. – Practicable

@ChadD, it does mean you aren't using connection pooling if you are opening connections directly from the fat client. I'm a huge fan of a clean web services interface to data, and in that case you could certainly take advantage of connection pooling. – Fornication

Answer 5

1. Web apps are much easier to update. The internal development team can update the site without the users even noticing.
2. Web apps normally use less bandwidth than fat clients. If you've got multiple offices, or a sales force on the road, bandwidth is important. Try using (worst case I can think of) MS Access to connect to a remote database over a 1mb line - it doesn't work.

Lordan

Answer 6

In my experience, it's been primarily for ease of distribution. I worked on the packaging, distribution logistics, and individual system debugging of a sizable Win32 app that needed to be delivered to thousands of people in multiple locations. The word headache doesn't do the experience justice.

After that, I created a webapp for the same company. It was also used by thousands of people. Once we finished developing and testing the app, the entire distribution process consisted of 1) deploying to prod and 2) sending the URL to everyone. So much easier to give everyone access to the web app, and a minute fraction of support issues.

Jojo

I think you nailed the primary perceived appeal of web apps: ease of deployment. But Click Once deployment of Winform apps have worked pretty darn good for me and I wonder if WPF Web apps are even better in solving deployment issues. The otehr main advantage of web apps as I see it is getting patches. However, with fast internet connections of today and deploying patches in small chunked up dll fixes, patching can occur hardly noticed by the user. – Practicable

ClickOnce is fine. Ish. But we are increasingly living in a BYOD and multi-platform world, and that trend is going to continue to accelerate. It won't slow down. An app that works across platforms has serious advantages beyond just the deployment angle. And the rich-client stuff will continue to get easier. – Fornication

Answer 7

Most 'corporate' types apps wouldn't really benefit a lot from being local. They aren't typically going to need accelerated video, etc. They're mostly data viewing and data entry. Really the points of easy of deployment, central management, etc are doing to out weight any benefits of a local desktop app.

Unchain

I realize you can also accomplish the needed functionality in a web app, but my main point is that I believe it is more difficult to do so and therefore more expensive to dev web apps and that the desktop alternatives that used to be exclusive to web apps can now also be centrally managed and that deployment for these apps is easy. In other words, web apps no longer retain this advantage over desktop apps. Clearly while this is happening, web apps have gotten better at being more like desktop apps (richer), yet at increased complexity AND COST. – Practicable

I wouldn't agree that developing a web app is harder than a desktop app - really it comes down to what you know how to do. – Unchain

Answer 8

• Because the web is a universal platform, and client OSs are not.
• Because developing and maintaining server side code is easier than developing and maintaining server side AND client side code.
• Because the web is stable and standards-based, while client OSs are proprietary and evolving.
• Because the web will outlast your current IT policy and corporate structure. (When you merge with company B, and 5,000 employees show up with their Chromebooks, your Windows smart apps aren't gonna look so smart).
• Because 99% percent of corporate applications are CRUD apps. If you need client-side data manipulation then dump to Excel.
• Because good luck finding Windows client developers. The money, action, and talent is all in web and mobile.

Smithers

Answer 9

It also allows easier scalability and reliability to the application. By putting it on a backed up server (possibly in a cluster), you allow a single source for deployments (@Gabriel) and you have less to worry about in the way of system maintenance. You don't have to worry that Mary's PC down the hall is too slow to run the app. It also reduces the access/security requirements to data sources. With the new MVC, n-tier, etc website development, data access is allocated to a singular layer rather than bothering with every tom/dick/harry having read access to it.

Gerick

A desktop app would scale better because you are making better use of the client machines, which for web apps, tend to lean toward almost dumb terminals (exaggeration.) If Mary's PC is too slow to run the app, it must be because the app is providing a richer experience than the clunky web app. And you can still centralized Data Accesslayer on the server in a desktop app. – Practicable

I would disagree. If the application changes rapidly, each of these changes would require an enterprise wide deployment and each system that makes use of the application would have to be considered. With a web app, browser considerations and network capacity are typically the only drawbacks. – Gerick

Answer 10

Lets consider your response 1) COST - Desktop apps are just conceptually simpler because you have the full resources of the local machine and you have state. As a result, desktop apps GOT TO BE much cheaper to develop for the same functionality. Just look at all the complicated client side/server sided Ajax fancy code one has to go through to do things that would be trivial in a desktop app. I picture people disputing this point but to me it is obvious and beyond debate.

Your not accounting for Implementaion cost and maintenance. Desktop apps need to be maintained on each machine it is installed on. In most cases this requires configuration on each system. The dollars add up quickly.

With web applications the application is a browser. Each machine is easily configured with a browser which is maintained at a lower cost.

2) Desktop apps are typically richer. Web apps are at best comparable at the expense of more complicated / more expensive to develop code. (a corrolary to 1)

I cant agree that desktop apps are typically richer. With newer technologies web apps can contain a rich user interface and features, with minimal development costs.

Thyself

1) I grant you that there is more potential for deployment issues but I am arguing that this has decreased significantly and is not fully recognized. Bad memories die hard. 2) Web apps can be close in richness to desktop apps but again, at the cost of complexity and cost to acheive the same functionality. The main point is that I think the deployment support costs of new technology web deployed desktop are exaggerated and the cost savings in recu ced dev time for desktop apps is undervalued or more likely, not even recognized. – Practicable

Answer 11

Platform/browser independence is very incorrect for an answer to the question.

What many answers didn't mention is that alot of organizations will create and use web applications that target a certain version of a certain browser. Easier to develop something that works and looks properly only in 1 web browser. Example: IE5, IE7, etc...

I see this everywhere, so to say that web applications can run on any platform/browser in an intranet environment is false in very many cases as internal facing web apps typically are used only within the company and therefore the companies internal policy is typically standardized on a certain platform and browser.

Because of this reason developers will write and test their web applications against a certain browser/platform only.

I think this comment negates any above comments explaining why web applications are used in corporate intranets.

Panic

Oddly enough, for all practical purposes, just about the ONLY "web" apps there are that won't work with multiple platforms are the ones created by Microsoft-only developers, more or less the same crowd who were or are involved in creating the rich client apps. The tools are available to do a much, much better job with web apps. Cross platform-capable web apps are the future trend in development, and the current tools of choice for that trend are HTML5/CSS/JavaScript, and there are some nice frameworks for working with all three. Those tools will only improve going forward. – Fornication

And by the way, in my humble opinion, some of the nicest current tools for web development come from Microsoft. But competition is stiff, and thank heaven for that. – Fornication