基于浏览器的应用程序还是独立的gui应用程序?

让我们假设开发/部署/维护工作/成本相等,然后从应用程序用户的角度来看:

用户会发现哪个ui更有用?

依据

• 易用性
• 响应性
• 熟悉的导航/使用模式
• 最像平台上使用的其他工具/应用程序(即,本机)

我明白“有用”是主观的。我个人不会再使用(作为一个用户,而不是开发人员)一个网络界面,如果我可以逃脱它。我 憎恨 他们。

有些应用程序开发为基于浏览器的应用程序是没有意义的。

从发展的角度看

• 今天没有两个可用的浏览器呈现 确切地 相同的。
• 即使使用ajax、javascript和动态响应接口,实现/调试也不容易。

有很多,很多独立的gui应用程序都很糟糕,没有争论。多平台gui的开发/部署和维护是非常重要的。

开发好的用户界面是很困难的。

事实上,在过去的10年里,我一直以开发大多数基于web的应用程序为生,因为它们的开发速度更快,部署更容易,并且提供了足够的实用程序,人们可以在必要时使用它们。

我不相信如果有其他选择,大多数用户都会使用web界面。

IMNSHO

基于浏览器的明显优势:

• 无论平台如何,都可以呈现相同的UI。
• 您可以轻松地升级应用程序,所有用户都有相同版本的应用程序运行。
• 您知道您的应用程序将在其中运行的环境(服务器硬件/操作系统),与安装gui应用程序的多种操作系统/硬件配置相比,这种环境更易于测试和支持。

对于基于图形用户界面:

• 有些应用程序(例如图像编辑)在本机gui应用程序中可以更好地工作
• 不需要网络访问

也可以看我的评论 this question :

跨平台gui是一个由来已久的问题。QT、GTK、WXWindows、Java AWT、Java Swing、XUL——它们都遇到了同样的问题:结果GUI在每一个平台上都不是原生的。更糟糕的是,每个平台的外观都略有不同, 感觉 因此,即使你能以某种方式获得一个在每个平台上都是本机的工具包,你也必须以某种方式编写你的应用程序,才能在每个平台上都有本机的感觉。

归根结底是一个决定:您是希望将开发工作减到最少,并在每个平台上都有一个看起来和感觉都不太正确的gui,还是希望最大限度地提高用户体验?如果选择第二个选项,则需要为每个平台开发一个公共后端和一个自定义ui。 [编辑:或使用Web应用程序。]

我刚才的另一个想法是:你还需要考虑你的应用程序处理的数据类型、数据的存储位置以及用户对此的感受。显然,人们可以将他们的facebook个人资料存储在web服务器上,但如果你正在编写myob这样的财务应用程序,并且你想将他们的所有个人财务信息存储在你的服务器上,他们可能会有不同的感受。您也许可以让它正常工作,但是实现所需的安全性和确保用户库的数据是安全的需要付出很大的努力。在这种情况下,如果您使用本机gui应用程序,您可能会认为总体工作量较低。

当谈到使用用户输入表单的简单数据输入时,我认为使用基于浏览器的解决方案可能会更容易和更快地开发。

除非你的核心功能是接口本身(“ 如果它是一个核心业务功能——不管怎样,你自己做吧。 “见 In Defense of Not-Invented-Here Syndrome 从 Joel on Software ,我觉得浏览器能够更好地执行表单呈现和处理,而不是从头开始开发一个gui。另外,更不用说编写一个gui要花更长的时间,而不是生成html表单并在浏览器发布后进行处理。

我过去发现,一个朋友让我写一份申请,输入一项调查的结果。一开始,我编写了一个java applet来显示带有所有单选框的调查本身,这时我突然想到,最好编写一个简单的http服务器来生成表单并对其进行处理。

真正的问题在于你是否正在发展:

1. 用户界面
2. 数据输入应用程序

如果您正在制作一个数据输入应用程序,那么将用户界面留给浏览器,并专注于您的核心功能。

基于浏览器的界面的优点:

• 更易于管理:用户机器上不需要安装,升级只需要在服务器端执行,所有用户都可以立即使用。数据备份可以在单个机器上执行,因为数据不会分散在多个客户端上。
• 应用程序可以通过浏览器访问任何机器。
• 可以轻松地支持多个平台一致。
• 在服务器上执行密集的操作时,客户端的内存和CPU需求可能会少得多。
• 增强的安全性:数据存储在单个服务器上,而不是多台客户机上,可以更好地控制访问。
• 集中式环境包括日志记录、从多个源输入的数据的许多其他好处可以立即从其他客户端获得,等等。
• 根据我的经验,调试通常更容易,开发基于web的解决方案也更快。

基于图形用户界面的好处:

• 可能更容易设计出更灵敏、更流畅的界面。
• 可以利用特定于OS的功能,这些功能可能无法通过浏览器获得。
• 不一定需要网络访问。
• 不需要担心浏览器兼容性问题。
• 如果服务器关闭或变得不可用,则不会出现单点故障。

有相当好的证据表明,在大多数情况下,王牌问题是可部署性和可保障性。一般来说,浏览器应用程序开销较低;实现和支持超过几十个用户可能会消耗大量的支持资源。

一两年前我看到一张桌子,上面写着:

用户界面质量-桌面
验证粒度-桌面
响应-桌面
用户接受-桌面
等-桌面
等-桌面
安装和支持-浏览器
浏览器赢了。

对于此任务(基于表单的文本输入),浏览器非常好。你不需要任何桌面应用程序能给你的东西(速度,灵活性)

作为一个web应用程序有一些退步,比如..

这是一个网页。有些事你就是做不到

您不能轻松地映射ctrl+j键来执行某些操作。例如:google电子表格试图映射键盘快捷键并工作 最 有时,浏览器默认的快捷方式处理方式会取代。

不能发出咆哮警报(OSX通知框架)。您无法访问文件系统。脱机时很难允许访问。

javascript非常占用cpu。

尝试调整google电子表格文档的大小,或者在digg(一个非常重javascript的站点)上加载一个页面-浏览器的cpu使用率将在一段时间内保持100%。在本机桌面应用程序中执行同样的操作很简单

当您执行升级时, 力 所有用户都有。 对于桌面应用程序,他们可以选择不升级。例如,我不喜欢其中一个谷歌阅读器升级,但我被卡住了。使用NeNeWiWWORD(桌面应用程序),如果我不喜欢最新版本的更改,我可以很容易地继续使用这个版本(或尝试和降级)。

你的网络服务器 必须 随时都可以接近,永远

如果服务器消失,您的用户就没有追索权。申请书不见了。如果停了10分钟,他们就不能用了。

对于你的申请,虽然我不太确定它是什么,但上面这些似乎都不是问题。

“这是一个网页” :表单和对话框在HTML和JavaScript中很容易实现(甚至可以使用服务器端脚本,例如 <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?> )

“javascript非常占用cpu” :听起来您的应用程序不需要任何javascript(当用户单击“提交”时,可能需要一些客户端输入验证,以警告他们任何输入错误?)

“强制升级” :我认为这可能是可取的,因为您不希望用户以旧方式输入数据。

“服务器必须可访问” :可能是个问题,但我不认为会是个大问题。假设您想将所有用户的数据存储在一个中央数据库中,这个问题无论如何都是不可避免的-保持web和数据库服务器的运行并不仅仅是一个数据库的工作(对于gui来说)

另外,你也得到了其他人发布的好处——你开发了一次,并且它运行在每一个可以运行理智浏览器的操作系统上。

我讨厌基于web的ui的一个原因是它们运行在另一个窗口中。也就是说,你有一些控件——可能有几十个——与你的应用程序无关。从可用性的角度来看,这可能会让人困惑,尽管我们大多数人已经通过“排除”额外的东西来适应。

当我看我的浏览器窗口时,我输入这个,窗口可能是12英寸高,但我输入的窗口可能只有3英寸。在这12英寸中,大概有整整两英寸被浏览器工具栏、标签、一排排书签和状态栏占据了,这些都与我正在交互的web应用无关。有很多浪费的空间(编辑窗口不像整个窗口那样宽,例如),填充了我不需要的东西,等等。一些最基本的控件(后退按钮,我在看着你)可以完全破坏设计很差的Web应用程序。

更不用说,如果我输入一个足够长的响应,我现在会得到两组滚动条。stackoverflow.com通过给我一个可调整大小的文本区域部分解决了这个问题,但我仍然需要与内部滚动条交互来滚动正在编辑的文本,然后上下滚动整个窗口以访问编辑窗口顶部或底部的应用程序控件。

总而言之,基于Web的应用程序无法与桌面应用程序的可用性相比较。对我来说,问题就变成了“你是对可用性更感兴趣,还是让你(作为开发人员)的生活更轻松”。

如果你想要可用性,可以直接使用桌面应用程序。如果你关心部署和支持一个Web应用程序是值得考虑的,但仍然有许多简单的方法来部署桌面应用程序,包括创建可以在运行时通过网络更新自己的应用程序。

浏览器可以随时随地访问Internet,并将其部署到服务器上。桌面应用程序必须部署到他们的计算机上,每台计算机都有自己的独特性,即使操作系统和版本相同。这会给你带来很多麻烦。 上网吧。

每件事都有优点和缺点,但是:

我还没有在localhost、intranet或internet上使用一个基于浏览器的应用程序,该应用程序使用起来感觉很好,响应速度很快,who的用户界面并没有受到html/js/css的严格限制。

注意:基于Flash和Java的UI是一个例外(但在某些方面更糟糕,我认为这不是你在这里所说的)。

我认为基于浏览器的用户界面概念将继续存在。没有什么比web本身更具可移植性了,而且只要你停留在体面的javascript库的边界之内……呈现就几乎是一样的。另外,由于渲染不是您的头疼,您可以更多地关注开发业务逻辑本身。

我完全赞成…

富客户端gui通常会更快、更好地与用户习惯处理的外观和感觉集成——这不仅意味着铃声和口哨声,还意味着许多节省时间的功能,如键盘快捷键。

基于web的ui将更易于移植,因为它不将开发绑定到单个平台,而且如果应用程序在远程运行,则更容易在一致的环境(服务器)上更新和测试所有的ui(不包括gui…)。 但你应该明白,虽然所有这些都是伟大的,真正具有开创性的,但它也带来了一些严重的缺点。 不仅要在所有目标系统下调试应用程序,还要在每个目标系统上运行的每个浏览器下调试应用程序…别忘了同一个浏览器的许多版本可能会共存一段时间,而且每个浏览器的设置可能会运行不同的流行插件集(和版本),这使得它的行为有所不同,而且网络设置可能会由用户自定义。 如果应用程序是远程的,它会打开许多有趣的新问题,从不同的ISP开始,中间会出现不同的问题,或者由于服务器、用户的机器或中间的任何地方的网络问题而导致服务中断。 在网络服务质量低或价格不合理的国家,远程应用不是所有用户的选择;对于您来说,同样适用的是:只有在本国带宽合理且价格合理的情况下,才能开始提供这样的服务。 如果应用程序必须在用户的系统上做一些不平凡的事情,那么您很可能注定要创建大量依赖于平台的代码。

归根结底,现在这两种解决方案都有优点和缺点。 有些应用程序确实需要在富客户机模型下开发,有些应用程序确实需要在基于web的模式下开发。 两种选择都有好处,关键是清楚地知道什么方式最适合我们的开发/部署/支持战略,而且,我可能会补充说,追求一种或另一种方式是愚蠢的,好像这是当前时尚的决定性银弹。

我的解决办法是

1. 网站应用程序显然会在浏览器上运行
2. 不需要访问客户端计算机的网络应用程序通过浏览器运行
3. 任何一次需要多个客户端访问的应用程序都可以通过浏览器访问
4. 每个客户端使用的应用程序没有明显的需要使用GUI的网络,这可能包括需要大量安全性的软件(对于基于浏览器的安全性可以得到解决)。

这是通过艰苦的道路学到的东西。其中一个主要原因是,客户发现安装和管理基于浏览器的应用程序比基于gui的要容易得多,例如使用javawebstart意味着客户将需要最少的jre和他们喜欢的东西,而基于浏览器的只需要一个链接。

所有的决定都是你的!作为Java开发人员使用JavaFX和Swing可以解决这个问题。