我确信以前有人问过这个问题，但我找不到。
与使用普通GUI框架相比，为独立应用程序使用基于浏览器的界面有哪些好处/限制？
我正在开发一个Python程序，该程序目前使用wxPython为GUI实现。该应用程序只是用户输入表单和对话框。我正在考虑转移到PyQt，因为它有小部件（用于未来的扩展），然后我意识到我可能只需要使用浏览器来做很多相同的事情。
该应用程序目前不需要访问互联网，不过将来也有可能。如果我基于浏览器，我想使用Karrigell作为web框架。
编辑为了澄清，截至目前，该应用程序将基于浏览器，而不是基于web。所有信息都将本地存储在客户端计算机上；不需要进行服务器呼叫，也不需要访问互联网（但可能稍后会出现）。它只是一个浏览器GUI，而不是wxPython/PyQt GUI。希望这是有道理的。
让我们暂时假设开发/部署/维护工作/成本是相等的，我们从应用程序用户的角度来看：
用户会发现哪个UI更有用
在方面
- 易用性
- 响应能力
- 熟悉的导航/使用模式
- 最像平台上使用的其他工具/应用程序（即本机）
我知道"有用"是主观的。如果我能逃脱惩罚，我个人将永远不会再使用（作为用户，而不是开发人员）网络界面。我讨厌他们。
有些应用程序开发为基于浏览器的应用程序是没有意义的。
从发展角度看
- 目前没有两个可用的浏览器能够完全渲染
- 即使使用Ajax，javascript和动态响应接口对于实现/调试来说也是非常重要的
有很多独立的GUI应用程序非常糟糕，毫无争议。多平台GUI的开发/部署和维护是非常重要的。
开发好的用户界面很难。
事实是，在过去的10年里，我主要开发基于web的应用程序，因为它们开发速度更快，部署更容易，并且提供了足够的实用性，人们在必要时会使用它们
如果有其他选择的话，我不相信大多数用户会使用网络界面。
IMNSHO
基于浏览器的明显优势：
- 无论平台如何，都可以呈现相同的UI
- 您可以轻松升级应用程序，并且所有用户都运行相同版本的应用程序
- 您知道应用程序将运行的环境（服务器硬件/OS），与GUI应用程序将安装的大量操作系统/硬件配置相比，这使得测试和支持更容易
对于基于GUI的：
- 一些应用程序（例如：图像编辑）可以说在本机GUI应用程序中工作得更好
- 不需要网络访问
另请参阅我对这个问题的评论：
跨平台GUI是一个由来已久的问题。Qt、GTK、wxWindows、Java AWT、Java Swing、XUL——它们都面临着同样的问题：生成的GUI在每个平台上看起来都不是原生的。更糟糕的是，每个平台的外观和的感觉都略有不同，因此，即使你能够以某种方式在每个平台上获得一个看起来是本地的工具包，你也必须以某种方式对你的应用程序进行编码，使其在每个平台都感觉是本地的。
归根结底是一个决定：你是想尽量减少开发工作量，在每个平台上都有一个看起来和感觉都不太对劲的GUI，还是想最大限度地提高用户体验？如果选择第二个选项，则需要为每个平台开发一个通用后端和自定义UI[编辑：或使用web应用程序。]
我刚才的另一个想法是：您还需要考虑应用程序操作的数据类型和存储位置，以及用户对此的感受。人们显然可以将他们的facebook个人资料数据存储在网络服务器上，但如果你正在编写像MYOB这样的金融应用程序，并且你想将他们所有的个人财务详细信息存储在你的服务器上，他们可能会有不同的感觉。您可能能够做到这一点，但要实现所需的安全性并确保用户群的数据是安全的，需要付出大量努力。在这种情况下，如果使用本机GUI应用程序，您可能会认为总体工作量较低。
当谈到使用用户输入表单的简单数据输入时，我认为使用基于浏览器的解决方案可能更容易、更快地开发。
除非你的核心功能是界面本身（"如果它是一个核心业务功能——不管怎样，你自己做。"，请参阅Joel在软件上为非发明综合症辩护），否则我觉得浏览器将能够更好地执行表单呈现和处理，而不是从头开始开发GUI。此外，更不用说，与生成HTML表单并在浏览器张贴后进行处理相比，编写GUI代码需要更长的时间。
我过去发现，一位朋友让我写一份申请，输入调查结果。起初，我正在编写一个Java小程序，用所有的单选框显示调查本身，这时我突然想到，最好编写一个简单的HTTP服务器，它可以生成表格并进行处理。
真正的问题在于你是否正在开发：
- 用户界面
- 数据输入应用程序
如果您正在制作一个数据输入应用程序，那么将用户界面留给浏览器，并专注于您的核心功能。
基于浏览器的界面的好处：
- 更易于管理：无需在用户机器上安装，升级只需在服务器端执行，所有用户都可以立即使用。数据备份可以在一台机器上执行，因为数据不会分布在多个客户端上
- 应用程序可以通过浏览器从任何机器访问
- 可以轻松一致地支持多个平台
- 由于可以在服务器上执行密集型操作，客户端的内存和CPU需求可能会大大降低
- 提高了安全性：数据存储在一台服务器上，而不是多台客户端机器上，可以更好地控制访问
- 集中式环境的许多其他好处包括日志记录、从多个源输入的数据可以立即从其他客户端获得等
- 根据我的经验，通常调试更容易，开发基于web的解决方案更快
基于GUI界面的好处：
- 可能更容易设计出反应更灵敏、更流畅的界面
- 可以利用可能无法通过浏览器获得的操作系统特定功能
- 不一定需要网络访问
- 无需担心浏览器兼容性问题
- 若服务器出现故障或不可用，则不会出现单点故障
有很好的证据表明，在大多数情况下，王牌问题是可部署性和可支持性。浏览器应用程序通常开销较低；实现和支持几十个以上的用户最终可能会消耗大量的支持资源。
一两年前，我看到一张桌子上显示了这样的内容：
UI质量-桌面
验证的粒度-桌面
响应能力-桌面
用户接受-桌面
等等-桌面
等等-桌面
安装&支持-浏览器
浏览器获胜。
对于这个任务（基于表单的文本输入），浏览器非常棒。你不需要任何桌面应用程序会给你（速度，灵活性）
作为一个web应用程序有一些缺点，例如.
这是一个网页。有些事情是你无法（轻易）做到的
你不能简单地映射ctrl+j键来做某事。例如：谷歌电子表格试图映射键盘快捷键，并在大多数时间内工作，有时浏览器对快捷键的默认处理会接管。。
您不能发出Growl警报（OS X通知框架）。您无法访问文件系统。脱机时很难允许访问。
Javascript占用大量CPU
试着调整谷歌电子表格文档的大小，或者在Digg（一个javascript非常重的网站）上加载页面——浏览器的CPU使用率将在一段时间内达到100%。。在本机桌面应用程序中执行同样的操作是微不足道的
执行升级时，会强制所有用户执行对于桌面应用程序，他们可以选择不升级。例如，我不喜欢谷歌阅读器的升级，但我被卡住了。使用NetNewsWire（一个桌面应用程序），如果我不喜欢最新版本的更改，我可以很容易地继续使用这个（或者尝试，然后降级）
您的web服务器必须始终可访问，永远
如果服务器消失，您的用户就没有追索权。应用程序已不存在。如果它停机10分钟，他们就不能使用它。
对于您的申请，虽然我不太确定它是什么，但以上任何一项似乎都不会成为问题。
"这是一个网页"：表单和对话框在HTML和javascript中很容易完成（甚至可以使用服务器端脚本，例如<?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>）
"Javascript非常占用CPU"：听起来你的应用程序不需要任何Javascript（当用户点击"提交"时，可能需要一些客户端输入验证，以警告他们任何输入错误？）
"强制升级"：我想这可能是可取的，因为你不希望用户以旧的方式输入数据。
"服务器必须是可访问的"：这可能是个问题，但我认为这不会是个大问题。。假设你想把所有用户的数据存储在一个中央数据库中，这个问题无论如何都是不可避免的——保持网络和数据库服务器的运行并不比仅仅一个数据库（GUI连接到）多多少工作
此外，你还可以获得其他人发布的好处——你只需开发一次，它就可以在每个可以运行正常浏览器的操作系统上运行。
我讨厌基于web的UI的一点是它们在另一个窗口中运行。也就是说，您有一些控件——可能有几十个——与您的应用程序无关。从可用性的角度来看，这可能会令人困惑，尽管我们大多数人都通过"调整"多余的东西来适应。
当我打字时看着浏览器窗口时，窗口可能有12英寸高，但我打字的窗口可能只有3英寸。在总共12英寸的空间中，可能有整整两英寸被浏览器工具栏、选项卡、书签行和状态栏占据，这些都与我正在交互的网络应用程序无关。有很多浪费的空间（例如，编辑窗口没有整个窗口那么宽），空间里装满了我不需要的东西，等等。一些最基本的控件（后退按钮，我看着你）可以完全破坏设计糟糕的web应用程序。
更不用说，如果我键入足够长的响应，我现在会得到两组滚动条。stackoverflow.com通过给我一个可调整大小的文本区域来部分解决这个问题，但我仍然需要与内部滚动条交互来滚动我正在编辑的文本，然后向上或向下滚动整个窗口来访问编辑窗口顶部或底部的应用程序控件。
总而言之，基于web的应用程序无法与桌面应用程序的可用性相比。对我来说，问题就变成了"你是对可用性更感兴趣，还是对让你（作为开发人员）的生活更轻松更感兴趣"。
如果你想要可用性，那就直接使用桌面应用程序。如果你关心部署和支持web应用程序，那么需要考虑，但部署桌面应用程序仍然有很多简单的方法，包括创建可以在运行时通过网络更新的应用程序。
浏览器可以在任何有互联网的地方访问，并将其部署在服务器上。桌面应用程序必须部署到他们的计算机上，即使使用相同的操作系统和版本，每台计算机都有自己的独特性。这可能会给你带来很多麻烦。上网。
任何事物都有优点和缺点，但是：
我还没有在本地主机、内联网或互联网上使用一个基于浏览器的应用程序，它使用起来感觉很好，响应能力强，而且用户界面不受HTML/JS/CSS限制
注意：基于Flash/Java的UI是一个例外（但在某些方面更糟，我不认为这真的是你在这里谈论的）。
我认为基于浏览器的UI概念将继续存在。没有什么比网络本身更容易移植了，只要一个人停留在像样的javascript库的边界内。。。渲染将几乎相同。此外，由于渲染不是你头疼的问题，你可以更多地关注业务逻辑本身的开发。
我完全支持…
富客户端GUI通常会更快、更好地与用户习惯处理的外观和感觉集成——这不仅意味着简单明了，还意味着许多节省时间的功能，如键盘快捷键。
基于web的UI将更具可移植性，因为它不将开发绑定到单个平台，并且如果应用程序在远程运行，则更容易在一致的环境（服务器）上更新和测试所有应用程序（不包括GUI…）。但你应该明白，虽然所有这些都很棒，而且真的很有开创性，但也有一些严重的缺点。您不仅应该在所有目标系统下调试应用程序，还应该在每个目标系统上运行的每个浏览器下调试。。。别忘了，同一浏览器的许多版本可能会共存一段时间，每个浏览器的设置可能会运行不同的流行插件集（和版本），这使得它的行为不同，网络设置可能会由用户自定义。如果应用程序是远程的，它会打开许多有趣的新问题，从不同的ISP开始，这些ISP会将不同的问题放在中间，或者由于您的服务器、用户的机器或在中间的任何地方的网络问题而导致服务停机。在网络服务质量低或价格不合理的国家，并非所有用户都可以选择远程应用程序；对您来说也是如此：只有在您所在国家的带宽合理且价格合理的情况下，您才能开始提供此类服务。如果应用程序必须在用户的系统上做一些不平凡的事情，那么无论如何，您可能注定要创建大量依赖于平台的代码。
归根结底，今天这两种解决方案中的任何一种都有优点和缺点。有些应用程序确实需要在富客户端模型下开发，有些应用程序也确实需要在基于web的范式下开发。这两种选择都有是很好的，关键是要清楚地知道什么最适合我们的开发/部署/支持战略，而且，我可以补充一点，追求其中之一是愚蠢的，就好像这是遵循当前时尚的决定性银弹一样。
我的解决方案是这个
- 网站应用程序显然是在浏览器上运行的
- 不需要访问客户端计算机的网络应用程序通过浏览器运行
- 任何需要同时由多个客户端访问的应用程序都通过浏览器访问
- 每个客户端使用的应用程序（不明显需要网络）都使用gui，其中可能包括在使用时需要大量安全性的软件（不过，基于浏览器的软件也可以解决同样的安全性问题）
这是通过艰苦的道路学到的东西。其中一个主要原因是，客户发现基于浏览器的应用程序比基于gui的应用程序更容易安装和管理，例如，使用JavaWebStart意味着客户端需要最少的JRE和他们喜欢的东西，而基于浏览器的只需要一个链接。
在所有的决定真的是你的！。作为一名使用JavaFX和Swing的Java开发人员，我可以解决这个问题。