When should you build a web application vs. a thic

2019-03-19 16:39发布

问题:

I would like to hear other people's advice on when one should build a web application versus building a thick client.

Over the last few years, I have participated in several discussions about whether an application should be built (or an old application upgraded) with a web browser interface. Usually these were internal systems used within an organization, not mass-market shrink-wrap products, and they were not actually on the public Internet. I do not want to limit the discussion to these types of applications solely though.

There are obvious cases where an application should be one or the other (e.g. no web based video editing software). On the other hand, Javascript libraries are making more rich experiences in the browser less difficult to implement everyday.

Have Javascript libraries and advanced server side technologies made things such as right-click context menus, drag and drop, etc. doable on the client side without a large effort? At what point does the extra complexity of writing for the web override the benefits such as ease of deployment and cross-platform compatibility, particularly if you are not trying to create the next Stack Overflow, but instead just building an internal application?

Does the fact that an internal application has a limited and captive audience more or less override any concerns over improved usability that a thick client can provide?

回答1:

I go Web app when I don't want to:

- be supporting a thousand environments each with their own quirks. Specifically, viruses, trojans, software interfering, and making it work the same everywhere.

- worry about applying upgrades and taking lots of calls

- dealing with clients who lose their data

I pick a thick client when the computation is intensive per transaction, or there is significant data transfer per transaction.

I like fixing everyone's problems with one upgrade. It might not be for everyone, but it's where the quality of my life and those I work for goes up. Making a web app work on a few different browsers may be easier than a ton of different operating systems in different conditions.

With the advent of Flex/Air you can provide an entire application experience in the browser. The browser is becoming the universal interface, whether it's installed locally or in the cloud.

Web apps have their cons too. I just am more motivated to build web apps as the pro's seem to outweigh the cons for the projects I am choosing.



回答2:

I believe we are still at the point where unless there is a reason for it to be a Web app it should be a local application (thick). It is obvious when it should be a web app. A pet peeve of mine is the thought that it should be a web app unless it's obvious it should be local. I don't believe we are at the point where enterprises are willing to have their employees dependent on web applications outside of their control. When it comes to apps internal to a company I believe movement of data, security, and deployment/upgrades are the key factors in deciding.

A couple of key reasons for an app to be on the web.

  1. The application and data need to follow you around no matter what computer you are on.
  2. The data needs to be centralized and the amount of data that needs to be transferred to the client is reasonable.

A few reasons to use thick apps:

  1. Utilities that work on local resources.
  2. Apps that do lots of one time processing of data.
  3. Apps where data needs to be accessed when disconnected from the network.


回答3:

Things I remember from the bad old days of deploying internal applications that weren't web-based: There was always a minimum of one computer that was set up so differntly that the upgrade wouldn't work. Sometimes more and the problem was different for each machine that wouldn't work. There was always a user who refused to install the upgrade until forced to by management (usually several weeks or months later). This ended up causing problems in the data at times becasue new businesss rules were not enforced.