I am having some issues with managers, because they believe that (intuitively) creating desktop apps is easier than creating web apps (because you have less constraints). But in my opinion, it is more difficult because of some reasons:

The literature for desktop apps is vastly smaller than for web apps

Coding panels and buttons is harder than using a declarative approach (HTML)

The stateless nature of http forces you to rethink in a request/response fashion

I'm looking for solid reasoning on GUI vs. Desktop apps. I strongly believe desktop is are harder to develop because of my experience with some toolkits, but If if someone care to respond otherwise, please feel free to fundament your reasoning.

Edit: I recovered my original question, since someone edited it and it lost the original content. If someone chooses to edit the question, please post some meaningful comment so I can at least know why some portion was changed.

I love how people think it's OK to post subjective questions as long as they tag it "subjective" and say "I know this is subjective but..." People, please read stackoverflow.com/faq
–
Graeme PerrowApr 25 '09 at 12:23

6

I voted for reopen but then it should be made into a community wiki.
–
Pim JagerApr 25 '09 at 12:24

Yeah apparently they read the subject and not your 2nd sentence (or the rest of the question for that matter). I'd vote to re-open if I could. Though, you could help your case by reframing the question as "what are the benefits and challenges of developing web apps vs desktop apps" rather than seemingly putting the developers of each against eachother. :)
–
Daniel SchafferApr 25 '09 at 12:25

Wow, closing this down seems a bit retentive. Perhaps if he'd asked what your favorite dev-joke was you'd have left it alone!!! Flag it as a wiki and reopen it.
–
SeanApr 25 '09 at 12:26

Wow some of you are a bunch of whiners. Fix the question so it isn't as S&A and vote to reopen and let nature take its course.
–
TheTXIApr 25 '09 at 12:28

14 Answers
14

Most of the time developing web apps is a lot easier and makes one of the big problems - deployment and roll out of new versions, disappear.

You don't have to deal with different operation system versions, installed libraries, registry, COM, etc. You have different browsers to deal with, but it a lot less of a deal.

I can't imagine deploying desktop application to 2-3 Millions of clients every month - something that is working fine with web sites.

As far as development goes with web development you have :

shorter execution paths

less state to manage

you hardly have to deal with parallelism yourself

a lot less or none resources to manage - no OS handles

The only disadvantage is that it usually takes more to setup development machine and debugging of web apps was harder. With the current state of tools the debugging isn't that much of a problem any more.

Given the right desktop development environment you don't have to worry about deployment either. Nor do I have to worry about the registry, COM, or installed libraries. For example, using Tcl/Tk it's possible to create a single file that has all required libraries, icons and code necessary to run. Not only that, but the same code base can trivially target Windows, the Mac and *nix. I agree, however, that deploying a desktop app to 2-3 million clients every month is tough. Though the firefox folks seem to manage pretty nicely.
–
Bryan OakleyApr 28 '09 at 18:01

2

I also want to add to your list of disadvantages that you typically will provide the end user with a less satisfactory experience. There are very, very few web apps that can compete with desktop apps for overall usability.
–
Bryan OakleyApr 28 '09 at 18:03

I'm not sure what is meant by "shorter execution paths." However, how do you have less state to manage? Is it because HTTP is state-less? Ok, go build complex applications without state (web or desktop) and see how far you get. As far as dealing with parallelism .. what do you mean? You don't really get any, unless you mean a web farm or something like that. All those CPU cores and memory on the client's machine are useless to you in a web app. You still have resources to manage, just not the client's (possibly considerable) resources.
–
BobbyShaftoeJun 14 '09 at 8:01

Most of the answers (so far, anyway) seem to focus on how easy or hard the choice will be to implement. The whole goal of an application, desktop or web based alike, is to serve the end user. That must be the starting point of the discussion.

Web apps simply cannot provide as rich and interactive experience as a desktop app in most cases. There are just too many limitations due to available widgets, network latency, the fact your app window must (typically) live within another application and so on.

That being said, many times interfaces don't need a large set of widgets, network latency isn't much of an issue, and running from within a browser window is an advantage. gmail and stack overflow are prime examples of web based apps that don't need a particularly rich interface.

So, when trying to decide which technology to use first consider the user. Do they need a high performance, rich UI? Do they need to be able to effortlessly share their data with others across the net? Is this an app they'll use eight hours a day or on just a casual basis? Will they use it mostly to edit local files or to collaborate with people across a network?

For those who say "web apps are always better", let me ask you this question: think about the tools you use every day. Your text editor, programming IDE, your browser, your email client. Which of those are web apps? Probably none, except for maybe your email client. There's a reason why you wouldn't want a web-based IDE for writing software (or writing a book, or doing serious image manipulation).

It all boils down to the user and what their goals are. Sometimes their needs are best met with a web based UI, sometimes with a desktop UI. Sometimes either will do. Of course you also need to weigh options such as distribution and update, cross platform availability, etc. but it all starts with the user and their goals. If you are focused on satisfying your end user the answer will likely become fairly obvious.

You provided a nice answer, but it didn't respond directly to my question. I'm specifically asking for differences, not a way of deciding if I should implement one or the other. Anyway, thanks for the good answer.
–
Miguel PingApr 28 '09 at 14:07

I reckon web is harder, you have to worry about state, network, and pay more attention to things like loading, security the list goes on. How about the nightmare which is browser compatibilty, AJax, CSS arrghhh.

OTOH Because the desktop has less boundaries maybe design wise it is slightly harder as you have more capabilities - I don't agree with that though.

There are quite a few differences between the two which create challenges or benefits. For web applications:

State - HTTP requests have no state and needs to be managed by passing session variables across all requests or cookies. This is an overhead in web applications and ASP.NET has often comes under fire for huge blobs of session data.

Centralized - Pushing a change to a web application is as easy as updating the bits on the server versus desktop applications where patches have to be rolled out to all users. The centralized nature also makes it easier to do analytics and such. This is a big convenience. I recall GMail at one point fixed a security holes in under 4 hours. In contrast, there are still plenty of vulnerable unpatched windows machines out there.

Architectural - fat server, thin clients make web apps platform agnostic. It also helps in managing balance... for example table sorting, error checking, mathematical computations or graphics (in the case of flash for example) can be done on either client or server depending on allocation of resources. Because of the thin client, it means that it is possible to completely overhaul the server without affecting impacting the client at all. This level of flexibility is really convenient.

Security - Desktop applications run in a trusted environment where they are free to do anything where as web applications run in a sand-boxed environment which make them inherently more secure for the client. However, web applications require some amount of configuration as it pertains to certificates, activex controls and so on.

Versioning - The cost of versioning is much higher for desktop applications. This goes back to the more tedious process of pushing out changes. And then again, jumping major version numbers means increased revenue by way of user upgrades. In web applications, the versioning is mostly for the developers themselves and it's much easier to do small iterative enhancements. That's the reason why desktop applications still adhere to waterfall development cycle because pushing out changes is costly and you must get it the first time. Desktop applications also have the cost of backward compatibility such as supporting Windows 98, XP and Vista or supporting older processors, drivers and so on.

Environment - Web applications run in a predictable environment which again is very convenient. There are cross-browser development issues between IE/FF/Opera etc but it's much easier to test and debug than say running a complex application on a desktop system with varying graphics processors, anti-virus software or builds.

Responsiveness - Web applications have slower responsiveness because of post-backs but AJAX has made this a whole lot easier and more fun.

I am sure there are many other points I am missing but that's my biased answer for web application development.

I think you make some good points but you're basing it on a lot of assumptions. For example, the whole "versioning" argument assumes you don't build in some sort of auto-update feature. Firefox seems to manage updates just fine, for example. Also, desktop apps can be "platform agnostic" if you choose the right toolkit. Just this past week I was working on a desktop app on my mac box at home. I took it to work and demoed it on my linux box. Then someone asked so I plugged my thumb drive into my windows box and it ran there, too.
–
Bryan OakleyApr 25 '09 at 23:16

@Bryan, these have been relatively recent shifts in the paradigm where desktop apps and internet apps are coming closer with technologies like Adobe Flex, Google Gears, RIA in general and desktop apps doing auto-updates. Even so, versioning is trivial with web apps. It happens implicitly each time you change a line of code on production. With desktop apps, those changes have to be rolled out on a monthly release cycle and then too you can't overload your users and some never end up updating.
–
aleembMay 12 '09 at 18:58

I think that each has their own massive complications that make them unique challenges and you will get a different answer based upon who you ask. Web programmers may think that desktop applications are harder than web projects simply due to unfamiliarity with the medium.

Desktop people may find that web apps are much harder to code for because they have to take into account a lot more design issues with CSS and communication using AJAX protocols.

The .Net Fx blurs the line a bit with respect to the winapi.
–
Ryan EmerleApr 25 '09 at 12:37

Most GUI programmer you would do, wouldn't require learning the WINAPI. It seems that building professional looking applications is less complicated in a client application if you are not already a wizard at CSS/Photoshop/etc. As well, you don't have to care about browser versions and as far as OS version, you can account for that more easily than standard wars in browser standard compliance.
–
BobbyShaftoeJun 14 '09 at 8:05

I get to work on both in my day job and can honestly say the only valid reason to develop a desktop app is because the user is not going to be connected at all times.

Distributing/maintaining a desktop app has problems that are always dependent on the user while a web app can be debugged without any involvement from the user. This should never be minimized as it can take an inordinate amount of time to debug a defect that one user in Idaho has that no other user has.

Development on the two takes a different mentality. Web is stateless by nature and desktop is statefull. When switching between the two I often get frustrated because I get use to one then try the same pattern/technique in the other and it fails.

Ultimately it depends on the problem you are trying to solve. If you can't stand up a web server then your options are limited. If you want users to use it in the wiles of West Virginia then you have few choices.

More information in the question would help as this question is almost too broad to cover.

Wow, I am surprised at the answers so far. I've done both, desktop in the past and almost all web now. I find web development much easier to develop, much easier to support and much much easier to rollout and deploy.

I would never choose to develop something on the desktop if there was any possibility of doing it on the web instead.

Desktop apps are the way to go. The current web technology (HTML, Javascript, HTTP, ...) was never designed with applications in mind. It was designed for documents. And you feel that with every line of code you write.

With desktop applications you do not have to deal with issues such as application state in the same way you do on the web. HTTP is a stateless protocol, so it's the developer's job to identify how to maintain the current state of the application for the user's session. A desktop can can use TCP/IP and maintain a connection to a server.

With the web, it is very easy to create a compelling user interface, as you can add animations with Javascript, Flash, etc. It is more work for the developer when the application is data centric, and application state is an issue.

And also - what you're calling web apps? Silverlight or Flash apps both can be done such way that you can use it from desktop or from browser. Ajax applications today not very different from desktop applications, but it's much harder to develop something not too simple with DHTML (even if you're taking frameworks like jQuery or even GWT).

Assuming HTML or DHTML as a web applications:

I've spent many years in web/ajax and desktop development and my experience is equal - I've done bunch of complex web application and desktop ones. Having good toolkit and tools for C# and enough experience I can create better desktop application than web one within same or shorter timeframe. But some type of applications CAN'T be done as desktop because it's a requirement to do them as a web apps.

Reasons why desktop development is simplier:

Language type safety, code hints

Performance of code x10-1000 + performance profilers

No need to check everything in all browsers

Informative exceptions with stack-trace, edit and continue

Ability to use multi-threading (if you know how to use it)

Overall predictability and stability of code

RAD tools

For the very long time several advantages of web apps were:

GUI Framework - HTML+CSS

It's easier for users to start using it

Content of applications can be found by search engines

Now we all have strong GUI Frameworks like XAML for WPF/Silverlight apps. Second point can be covered by Silverlight/Flash applications (which I'm treating as desktop ones). Third one can be done for RIA, but requires some effort (same applies to ajax apps).

If you're targeting something simple and don't know modern desktop/ria development tools and techniques that might be another good reason for developing web application. But as I've said - I hope it would be something simple.

Both kind of apps have advantages and disadvantages. for instance, web apps might need to take different browsers into consideration and getting a usable UI is harder in web than in windows forms. However, web apps do have some advantages too. the first one that pops to mind is deployment and no need to worry about different platforms (just different browsers - yes, it's harder to develop for different platforms than for different browsers).

re: "yes, it's harder to develop for different platforms". That isn't an absolute. If you pick the right language it's possible to write on one platform and it just runs on the others with little or no modification (and I'm not thinking just of java). Quite often it takes just as much (or as little) tweaking as it does to make a web app work in multiple browsers.
–
Bryan OakleyApr 26 '09 at 23:02