5

作为程序员和最终用户，您认为哪个更好，为什么？

4

5 回答 5

11

小程序通常很慢​​，很糟糕，在浏览器中不合适，无法打印，让其他一切都感觉很慢......我只是讨厌当我去某个地方并且小程序开始加载时。小程序是一个很大的失败，幸运的是正在慢慢消亡。

Web Start 非常适合制作为桌面应用程序并解决部署问题（集中部署）的应用程序。下载应用程序以在浏览器外部的 JVM 中执行。它们可以链接到桌面，离线启动...最后但同样重要的是，您可以选择是否使用 Web Start 应用程序。

小程序：0 - 网络开始：1

编辑：我使第一句话不那么通用。有成功实现小程序，毫无疑问。我只是对全球有负面看法，因为我看到的错误小程序或用法比好的小程序多。

于 2009-03-14T06:31:33.553 回答
3

根据我的经验，客户不希望他们的程序在浏览器中运行。但是，从 Java6 更新 10 开始，小程序可以在浏览器之外的单独进程中运行。这个吸引人的特性可能会填补小程序和 JWS 之间的空白。

于 2009-03-16T04:10:58.050 回答
1

Applets 的问题是 JVM 版本。虽然理论上 JVM 在实践中是向后兼容的，但实际上它不是，我记得我一直不得不在系统 JVM 上运行两个不同的小程序（两者都由同一供应商生产——如果不是同一程序员）。

从理论上讲，Java Web Start 解决了这个问题，因为它允许用户指定要使用的 JVM，但我仍然有这个问题。如果你有一个代理服务器——虽然大多数公司环境都有——我在那里也遇到了各种各样的问题。

作为程序员和用户，我个人的选择是可下载的SETUP.EXE，其中包含 JAR 和用于应用程序的 JVM 版本。我们发现，当您以这种方式控制整个环境时，应用程序更加可靠。您失去了通过 Web Start 获得的简单升级，但我认为这是值得付出的代价。

于 2009-03-14T06:42:12.080 回答
1

我认为两者都有自己的位置。多年来，我们部署了多个重要的小程序并取得了巨大的成功，唯一的兼容性问题是事件模型在 Java 1 到 Java 2 之间的转换引起的。它们是交付给我们客户的一种非常有效的方式，并且是部署起来比 WebStart 简单得多。

另一方面，WebStart 在部署/更新注意事项和应用程序功能之间提供了很好的折衷。

我还编写了一个动态下载启动器类，它可以在启动应用程序之前从 HTTP 地址更新自身和应用程序 - 这对于将应用程序交付到桌面并保持更新非常有效。

我个人更喜欢 JVM 作为先决条件，而不是随应用程序一起安装 - 我发现我的应用程序在各种平台（Windows、OSX、Linux 和 OS/400）上从 Java 2 到 Java 6 都没有兼容性问题。

于 2009-03-14T21:14:33.613 回答
0

作为用户，我更喜欢小程序。普通用户拥有 Windows XP。显然他们并不关心速度，尽管超过 30 秒的加载时间可能很烦人。

作为一名程序员，我更喜欢 Java Web Start。它更快，在我看来更好。我认为，如果您决定使用哪个，这主要是个人选择的问题。

于 2011-02-23T22:26:00.653 回答