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