我想听听其他人关于何时应该构建 Web 应用程序而不是构建胖客户端的建议。
在过去的几年里，我参与了几次关于是否应该使用 Web 浏览器界面构建应用程序（或升级旧应用程序）的讨论。通常这些是组织内部使用的系统，而不是大众市场的收缩包装产品，而且它们实际上不在公共互联网上。不过，我不想将讨论仅限于这些类型的应用程序。
有一个应用程序应该是一个或另一个的明显情况（例如，没有基于 Web 的视频编辑软件）。另一方面，Javascript 库正在让浏览器中更丰富的体验变得更容易实现。
Javascript 库和高级服务器端技术是否让诸如右键单击上下文菜单、拖放等操作可以在客户端轻松实现？在什么时候为 Web 编写额外的复杂性会覆盖诸如易于部署和跨平台兼容性之类的好处，特别是如果您不尝试创建下一个 Stack Overflow，而只是构建一个内部应用程序？
内部应用程序拥有有限且被俘虏的受众这一事实是否或多或少地覆盖了对胖客户端可以提供的改进可用性的任何担忧？
当我不想这样做时，我会使用 Web 应用程序：
- 支持一千种环境，每个环境都有自己的怪癖。 具体来说，病毒、木马、软件干扰，并使其在任何地方都一样工作。
- 担心应用升级和接听大量电话
- 处理丢失数据的客户
当每个事务的计算密集，或者每个事务有大量数据传输时，我会选择一个胖客户端。
我喜欢通过一次升级解决每个人的问题。它可能不适合所有人，但它是我的生活质量和我为之工作的人提高的地方。让一个 Web 应用程序在几个不同的浏览器上运行可能比在不同条件下使用大量不同的操作系统更容易。
随着 Flex/Air 的出现，您可以在浏览器中提供完整的应用程序体验。浏览器正在成为通用界面，无论是安装在本地还是在云端。
Web 应用程序也有其缺点。我只是更有动力构建网络应用程序，因为专业人士似乎超过了我选择的项目的缺点。
我相信我们仍然处于这样的地步，除非有理由让它成为一个 Web 应用程序，否则它应该是一个本地应用程序（厚）。很明显它应该是一个网络应用程序。我的一个烦恼是认为它应该是一个网络应用程序，除非它很明显应该是本地的。我不相信我们处于企业愿意让他们的员工依赖于他们无法控制的 Web 应用程序的地步。对于公司内部的应用程序，我认为数据移动、安全性和部署/升级是决定的关键因素。
应用程序出现在网络上的几个关键原因。
使用厚应用程序的几个原因：
我记得在过去部署不基于 Web 的内部应用程序的糟糕日子中的事情：总是至少有一台计算机设置得如此不同以至于升级无法正常工作。有时更多，并且每台无法工作的机器的问题都不同。总是有一个用户拒绝安装升级，直到被管理层强制（通常是几周或几个月后）。这有时会导致数据出现问题，因为没有执行新的业务规则。