We currently have an ongoing discussion about which approach to move into - we want to replace multiple older environments with .NET applications, and two potential architectures are under discussion:

  1. Client-Server ('fat-client'): requires an installation on each client
  2. Web-based ('thin-client'): works in any browser, no install required.

Some arguments are that Client-Server is inherently more stable and faster to develop, as you don't have to worry about 'stateless' and doing your API calls through URLs; on the other hand, web-based can run on mobile devices (and non Windows machines) without too much additional effort (if any).

I don't have enough experience with .NET to confirm or discard either of those claims for sure, so my question here is:

Is a web-based architecture inherently more expensive to develop than a client-server architecture?

The answer should not consider the effects of needed learning and experience gathering - the team comes historically from Client-Server, so of course in the beginning web-based will be harder, needs more training, and will have some issues. Ignore that. Assuming equally experienced and qualified teams, is one of the architecture inherently and always more effort to build?

If you are experienced in both kinds of architectures, you could help me make this decision.

A little more background: the decision for .NET is made; all our data is in Oracle DBs already, and will stay there; however, it would be nice to not be locked into Oracle long term. We plan to re-skin/re-build about thirty existing applications of various sizes, and create about twenty new ones, within the next three years (totaling roughly twenty man-years), into a somewhat integrated solution environment. All users for all apps are in-company, none of this is for the public. I tend to go with web-based (because of the mobile options), but we don't want to find out two years down the road that we went the wrong way.

  • One thing to note is that I find it's still a good practice to use web services to provide data (and universal business logic related to that data) even if you are using a desktop client. A desktop application doesn't necessarily need to be a fat client.
    – RubberDuck
    May 15, 2016 at 19:53
  • I think DB choice is not a factor at all.
    – JeffO
    May 16, 2016 at 7:54
  • That was my point @JeffO.
    – RubberDuck
    May 16, 2016 at 10:37
  • 3
    You don't have to do stateless API calls through URL in web based environment, a lot of Web Applications do quite OK doing all their calls to a single stateful SOAP endpoint. I think you're conflating the complexity of web application with complexity of REST principles. Developing REST APIs is hard, but if you want to reach the goals that REST tries to achieve, which is fast, reliable, horizontally and vertically scalable, long lived, portable API, then you should develop your app using REST principles, whether you're developing desktop or web applications.
    – Lie Ryan
    May 16, 2016 at 10:55
  • Do you mean a fat client that communicates directly with the database, or one that communicates to some kind of middleware, like a web service?
    – paj28
    May 16, 2016 at 14:37

5 Answers 5


Building a web application is absolutely more complicated and harder to build than client-server, for a given set of features. There are a variety of reasons and ideas I'll describe in no particular order.

The highest voted question of all time on this site is What technical details should a programmer of a web application consider before making the site public? In there, there are dozens of bulletpoints, and while a handful are general statements, the vast majority of them are indeed specific to web programming.

Where is the "What technical details should a programmer of a desktop application consider before making the site public?" question? Why doesn't it exist? Because everything that would be in that list is inherent to programming in general, and web programming has to be concerned about all of those in addition to the aspects in the linked question.

Let's compare similar aspects of applications that are both web-based and not. In my opinion, the difference between client/server and desktop applications is insignificant compared to the difference between those and web based.

  • Compare Google docs or Office 365 to desktop MS Office*. MS Office 10 years ago, (probably even 20 years ago Office 95), is miles ahead of both of them in terms of features and capability, with the exception of the simultaneous editing parts.
  • Outlook + Exchange from years ago is superior to any web-based email client today.
  • While the javascript PDF viewer that comes with firefox is spiffy in that it is all javascript, adobe acrobat is still considerably better despite acrobat being horrible!
  • A lot of software is just straight up impractical or impossible to implement in a web-based offering, whereas anything that can be computed can be made into a desktop app. Nothing on the web cannot be implemented in a client/server app (besides stuff that explicitly requires a browser or runs in the context of an existing web site.)

The reason why the differential in capabilities is because web-based applications are so much more difficult and complex to build.

Many people are exited about node.js, who's chief value is that you can build the front end and back end for web apps in the same language. Node.js was first released in 2009. Since when have client/server/desktop apps been able to use the same language for front and back end? Since nearly always. Why are people using it? Because web development is so complicated people are willing to bring in javascripts problems and complexities in order to try to reduce complexity in the server/browser interface.

Browsers and the HTTP link adds significant complexity to web applications. Unless I am writing software to fly the space shuttle, I don't have to worry about an error 404 when trying to access some memory address or other resource, but web applications I often do. Losing total access to the disk is often not a significant concern for desktop apps, and gracefully crashing is usually considered appropriate enough. Losing the network on a web app not only happens often, and repeatedly, but is expected to be handled gracefully and resume connection. That's all on top of all the problems that can be happening inside the serverside or front end code.

The connection between the browser and http server does not maintain any significant state. In client/server and desktop apps, it trivially maintains as much state as you want to. Think of the dozens of frameworks and mountains of boilerplate for web frameworks trying to bridge that stateness gap in a sensible way. Thick client apps, you get that all for free.

Think of all the millions of person hours people have spent struggling with obnoxious gotchas in displaying sensible webpages, the days of making things line up in Internet Explorer. While desktop apps have plenty of gotchas as their own, I don't think something as seemingly simple as "making two columns the same size" has sucked so much of humanities work on the desktop as it has on the web. I think making stuff work cross-platform has been considerably easier than cross-browser.

Even if you try to cut down on some of this complexity by restricting what browsers people use, you can similarly tone down complexity of thick-client apps by restricting what OS they are using. The web app will always have more independently operating parts and will therefore result in more complex software.

Lastly .NET has no bearing on any of this, these are broad statements I believe to be true across all languages.

P.S. Obviously there is the "browser plugin" route but that basically combines the worst aspects of both so pretend that doesn't exist when trying to grok the ideas here.

  • interesting counterpoints. Thanks. I think that not all the issues listed would hit us with full force, as we don't cater for the public, and don't try to build anything nearly as fancy as a spreadsheet, but there is probably enough trouble remaining to consider it.
    – Aganju
    May 15, 2016 at 21:23
  • Fully agree with this.
    – Andy
    May 15, 2016 at 22:20
  • 4
    This is the most silly answer ever. The primary reason why desktop application seems simpler is because there's normally only one runtime environment for a desktop application. There's only one .NET runtime implementation, for example (ignoring Mono), and it only runs on a very narrow set of environments. In web, there are multiple implementations of browsers and you have much more environment that you need to consider. If you're only developing for a single browser, the complexity of developing a desktop and web application is more or less comparable.
    – Lie Ryan
    May 16, 2016 at 10:40
  • And if you want to port a desktop application to run on multiple OSes and runtime implementations, then you'll most likely find that a web application is the best way to develop such cross platform application. The differences between .NET, Cocoa, and Android are much larger than the difference between Firefox and Chrome.
    – Lie Ryan
    May 16, 2016 at 10:44
  • 5
    @LieRyan: rather than calling my answer silly you should share your insight with the world instead, especially when in your first comment you are essentially repeating what I said. I never said web applications were "bad" or "inferior", just that developing web applications, which has a slow, unreliable link as a critical component to it, has a significant cost that must be considered. Web applications can be the right way to do something, but its benefits don't come for free. May 16, 2016 at 15:25

No, not necessarily. What you need to understand is that the Web architecture is a Client-Server architecture, it's just that the Client here is provided for you (the browser).

The real question is, does the browser meet your requirements? Can it perform all the operations you want of the Client? If so, it may well be easier to re-use that existing Client. Otherwise, writing your own Client may be the better choice.

  • Understood. I just tried to use the naming conventions (within my limited understanding). A browser will be fine for all operations; nothing is especially fancy. The main advantage would be to remove the need to have installations on 3 versions of iOS, 99? versions of android, 6 versions of Windows, etc., whatever the user happens to have - Chrome or Safari or IE or whoever will worry about that. Of course it limits us to standard Browser functionality, but that would be fine.
    – Aganju
    May 15, 2016 at 14:52
  • I'd be wary of declaring that "fine". I personally hate HTML, CSS and Javascript, and supporting all the different browsers can be very annoying if you need any feature that hasn't been maturing for ten years.
    – DeadMG
    May 15, 2016 at 14:57
  • 1
    @Aganju Writing your own client is also an option, whilst keeping the server web-based. ie, a thick client can still make REST calls to a webserver and display the resulting data in whatever way it likes. You just need to create a server side that doesn't return pre-built HTML pages (or has an option to return just data in those pages).
    – gbjbaanb
    May 16, 2016 at 7:43

In my experience it doesn't have to be more expensive to write a web application. We recently did some research to decide what approach to use for our own future projects.

From developing a lot of windows applications we decided to move to web applications instead. In my opinion there are a few big advantages for using a web application.

  • Often more easy to release. Since the browser is the client you can ensure that everybody is using the latest version. No need for GPOs or distribution.

  • Available for mobile devices. This may have changed somewhat with Win 10 and universal apps. But still.

  • Not dependent on OS. Even if different browser may act different you should have no bigger problems when upgrading your OS. We're moving from x86 win7 to x64 Win10 which requires us to fix the windows applications. The web applications work out of the box.

And today there's a lot of great libraries to make web development faster. However, by taking release management and overhead into the calculation you may reconsider the total cost for an web application. How often do you roll out a new OS? Every 5 years? How long should you support your application? 10 years?

But there is one downside. And that is the unexperienced users. We notice that a lot of the users find it harder to use a web application than a windows application. But personally I think that is because of unexperienced GUI-designers.


I made some (possibly invalid) assumtions. First, my answer is based on the fact that it's an internal application to your organization. Not an application that should be used by public users.

Second, I assumed that you where interested in the total cost, not the developing cost. That is, the total cost for the softwares lifetime. Including updates and maintanence.


No - web development is very competitive with native app development.

Overall architecture:

  • Most modern fat client applications communicate with middleware, rather than directly to the database. With .Net the middleware is typically a SOAP web service.

  • Many modern web applications are single page applications. In this architecture, a JavaScript client that runs in the browser communicated with middleware. This is typically a REST web service.

So the architecture is basically the same. And while REST and SOAP are different, they fundamentally do the same thing. The server side is going to be very similar in either architecture. In fact, you could easily have both a fat client and web client run off the same back end - I've seen several real world applications that do this.

So the choice really comes down to the front end. Web apps have some strong benefits:

  • Work on a range of platforms: Windows, Linux, MaC OS, Android, iOS, etc.
  • Distributing the latest version of the web client is easy - keepng native clients up-to-date can be difficult.
  • Web page runs within a sandbox, so you're not asking your users to fully trust you.

The main disadvantage is that web sites don't have full access to the client system. Although these days, web sites can do advanced 3D graphics, access local files, use the camera, GPS co-ordinates, and more. If you're doing something really heavy, like a 3D animation studio, you'd want to be native. But most applications will work just fine as web apps.

There's also the question of the quality of the tools for building web and native applications. Many people are complaining about the great choice and complexity of JavaScript frameworks. However, I think front-end web tools are in a pretty good state. Native development (QT, wxWindows, etc.) is mature and stable, but web development is agile and innovative. With frameworks like AngularJS and Bootstrap, you can put together powerful and good looking apps very quickly.


You have to take into account also:

Security, you need in any case protect your application against any threat and in this regard Web-based apps have the disadvantage because they are exposed to the Internet which is and will never be a secure place. It is important to specify the security features required for the system and if you are going to use a cloud provider(which could offer more security than your own company).

Performance heavy gain on traffic will certainly slow down your experience in your Web-based app. Literarily you are not only sending the data but also the user interface and this can slower the app.

So if your requirements for security and performance are high it is very likely that a Web-based app will be harder to implement.

Note: you can use ClickOnce on .NET to deal with the problem of updating your desktop-base app on every user.

  • 1
    Thank you for mentioning ClickOnce! For many problems, it can be part of the right solution. I get tired of hearing about how client-server 'requires an installation on each client', as if a technician must visit every desktop, and this is used as a selling point to convince an organization to abandon client-server and move to exclusively web-based solutions. May 16, 2016 at 17:44
  • You are welcome. It is not good to take decisions based solely on general guidelines, you always have to look what a specific technology can offer you.
    – Ed_
    May 16, 2016 at 17:49
  • I'd actually count security as a point in favour of web apps. (1) Because it's so important, there are extensive literature and resources available for securing web apps. Many frameworks have out of the box solutions available to make the most common vulnerabilities more difficult (XSS, CSRF). (2) With a client-server architecture, the server might be tempted to trust client-provided data, in particular serialised objects. With a textual REST API, we have to explicitly parse and validate all transmitted data in a validation layer. In any case, the server only needs to be on the intranet.
    – amon
    Aug 26, 2016 at 5:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.