7

从以下框架列表中，您将使用哪个框架来开发富 Web 应用程序，为什么选择它而不是其他框架？

Sproutcore GWT ExtJS GXT SmartGWT Dojo / Dijit Flex Capuccino Grails

4

9 回答 9

6

我个人厌倦了浏览器的不一致。如果其他人已经解决了这个问题，我宁愿不再做。这就是为什么我对卡布奇诺和 qooxdoo 等前端越来越感兴趣的原因。它们是零 HTML 零 CSS 解决方案。

于 2010-03-18T05:02:00.793 回答
5

这些是基于我使用您提到的框架的个人经验。所以是的，它有点偏颇。因此，正如其他人一遍又一遍地所说，根据人们在此提出的建议，定义您的要求以及您认为哪一个符合您的要求。

  • GWT太冗长了，尽管我发现许多 Java 开发人员都喜欢 GWT，因为您可以对它进行单元测试，而且这一切都在 Java 中。但我个人不喜欢它，因为它远非简单。有时我觉得我可以用 Javascript 稍微调整一下，但是用 GWT 我不得不用几行 Java 代码来做。
  • GXT现在离 GWT 太远了，你会发现做事很困难，因为 GXT 有自己的做事方式，这与 GWT 太不同了。当出现复杂的需求时，最后你会回去做普通的 GWT。哦，他们的技术支持也不是那么好，因为我在向他们问几个问题时有几次不好的经历。
  • Ext-JS适用于简单的东西，而且外观和感觉真的很漂亮。但是当事情变得更复杂时，你会努力克服困难。尽管我处理过 GXT 技术支持，但我没有处理过 ExtJS 技术支持，因为他们有不同的人，即使它在一家公司，所以我不能说太多。
  • Flex很好，真的很好。但同样适用于简单的东西。一旦事情变得更复杂，您将编写大量的动作脚本，这不太令人愉快。如果您必须用 Javascript 编写代码，有很多开箱即用的东西可能会很困难，比如多媒体支持。哦，如果你正在为一个公共网站写作，你必须考虑到没有太多的用户在他们的浏览器上安装了 flash 插件。
  • Grails，我不确定您将如何使用 Grails 实现 RIA 应用程序，因为 Grails 只是另一个 MVC 框架，您需要在其之上添加自己的 RIA 框架，例如您提到的那些。
于 2010-03-18T05:05:04.123 回答
5

这完全是一个见仁见智的问题。您不会从任何人那里得到任何明确的答案，因为任何回答的人都会有他们个人喜欢的一个或另一个。

尝试每一个足够长的时间来决定哪一个最适合您（或您的团队）的目的。

话虽如此，我更喜欢GWT。其他人总是不同意我的观点。

我喜欢 GWT 的原因：

  • 您可以共享（一些）客户端和服务器端代码（只要您的服务器是用 Java 编写的）
  • GWT 使许多高级性能特性变得非常容易（例如，延迟 JS 加载、图像精灵、CSS 混淆）
  • 专注于单页应用，第三方支持 Places（使用gwt-presenter库）
  • 将 GWT 添加到现有网页就像创建完整的单页 GWT 应用程序一样容易
  • UiBinder允许您使用类似 HTML 的声明性语法编写 UI；如果您不想编写类似 Swing 的 UI，您不会陷入困境
  • 浏览器不兼容问题（大部分）由 GWT 处理——您只需编写 Java 代码，GWT 将其编译为适用于每个浏览器

可能使 GWT 不适合您的事情：

  • 如果你的服务器已经用 Java 以外的东西编写，你仍然可以用 GWT 编写 UI，但是你会失去一些不错的功能
  • 使用 GWT 的编译时间是一笔不小的成本——开发模式可以大大减轻这一点，但有时它仍然是一个问题
  • 正如其他人所提到的，与 jQuery 或 ExtJS 等简单的 JavaScript 库相比，GWT 可以被认为是“冗长的”
于 2010-03-18T04:19:53.003 回答
3

Ext GWT 在我的项目中运行良好。高级支持一直很好。

然而，该项目是供内部使用的，它允许将部署限制在一个操作系统上的一个浏览器上，并且没有努力改变 Ext GWT 的默认外观或行为。

完全在 Java 中开发是一个关键优势，因为它有助于在添加功能时保持项目的可管理性。

于 2010-03-18T15:17:21.400 回答
2

我会推荐道场。

除了它提供的庞大基础设施之外，Dojo 1.6 还是第一个（也是唯一一个）流行的 JavaScript 库，它可以成功地与 Closure Compiler 的高级模式一起使用，它附带了所有的大小、性能和混淆优势——除了谷歌自己的闭包库，就是这样。

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

换句话说，使用 Dojo 的程序可以 100% 被混淆——甚至是库本身。

编译后的代码具有与纯文本代码完全相同的行为，只是它更小（平均比压缩器小 25%）、运行速度更快（尤其是在移动设备上），并且几乎不可能进行逆向工程，即使经过美化器，因为整个代码库（包括库）都被混淆了。

仅“缩小”的代码（例如 YUI 压缩器、Uglify）在通过美化器后可以很容易地进行逆向工程。

于 2011-03-10T10:32:21.840 回答
2

我目前正在开发一个 grail/flex 混合应用程序，它比我预期的要好得多。我看过 GWT，但当时并没有很多关于它的书，而且它似乎强调了我不喜欢的类似 Swing 的编程技术的利用。我同意关于尝试所有这些的评论。运行他们都有的 hello 应用程序，并衡量修改的难易程度。此外，工具（IDE、Maven、CI...等）支持也可以成为立即生产的一个重要因素。

于 2010-03-18T04:50:58.010 回答
2

不幸的是，答案将是固执己见，GWT 的最纯粹形式并不是吸引眼球。话虽这么说，ExtJs GXT 是超级棒的多莉。我在不断发展的框架中面临的主要问题之一是它们并非绝对没有缺陷，如果我没记错的话，GWT 2.0 出厂时缺少一些新布局的 CSS 样式。自过去 5 天以来，我一直在尝试解决 ExtJs/GXT 中的一个问题 :(，框架混淆了很多东西。我将使用任何绝对健壮并提供适当错误消息的框架。虽然我没有与其他人合作过.

于 2010-03-18T04:54:54.277 回答
2

我们在这里使用 Grails+ExtJS。由于我们尝试制作一个惯用的 ExtJS 应用程序，Grails 并没有得到充分利用，尽管在服务器端使用 Grails 代替 JSP 仍然是有意义的。

为什么选择 ExtJS：因为它是一个非常丰富的工具包，用于类似 GUI 的 Web 应用程序。我们的工作是替换旧的 Motif GUI，所以这正是我们所需要的。

为什么选择 Grails：因为它可以轻松快速地完成工作。对于与 ExtJS 部分的通信，我们需要大量的 JSON，而在 Grails 中是这样的：

import foo.bar.FooBar
class FooBarController {
    def viewFooBars = {
        def list = FooBar.getList(session.userId, params.foo, params.bar)

        def result = [resultset: list] as JSON

        response.setHeader('Content-disposition', 'filename="json"')
        response.contentType = "text/json";
        render result
    }
}

这甚至比必要的多两三行......

于 2010-03-18T13:06:41.460 回答
1

ExtJs is great for creating complex web applications. The API provides anything you can imagine in a webapp and its really easy to extend any component after some time.

You can plug it to any backend (we use django or php) and reuse or extend any component in several different applications.

You'll need severals months to feel comfortable with it. IMHO.

That said, the lib is sometimes a bit too slow for simples uis like a website (then you can use ExtCore). But when it comes to webapps this is not an issue.

Im not a java guy so GWT was not an option for me :/

hope this helps

于 2010-11-01T15:14:02.047 回答