.NET: Are web-based applications inherently harder to build than client-server?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

EDIT:

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.

Answer 4

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.

Answer 5

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.