哪个Web应用程序框架?

时间:2010-03-18 04:15:52

标签: gwt grails dojo sproutcore

从以下框架列表中,您将使用哪个框架来开发富Web应用程序,为什么要选择其他框架?

SproutCore的 GWT ExtJS的 GXT SmartGWT的 Dojo / Dijit 柔性 卡布奇诺 Grails的

9 个答案:

答案 0 :(得分:6)

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

答案 1 :(得分:5)

这完全是一个意见问题。你不会得到任何人的任何明确答案,因为任何回答的人都会有他们个人喜欢的一个或另一个。

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

话虽如此,我更喜欢GWT。其他人总是不同意我的看法。

我喜欢GWT的原因:

  • 您可以共享(某些)客户端和服务器端代码(只要您的服务器是用Java编写的)
  • GWT使很多高级性能功能变得非常简单(例如,延迟JS加载,图像精灵,CSS混淆)
  • 专注于单页应用,第三方支持地方(使用gwt-presenter库)
  • 将GWT添加到现有网页同样容易,因为它是创建一个完整的单页GWT应用程序
  • UiBinder允许您使用类似于声明的HTML语法编写UI;如果你不想
  • ,你就不会被写成类似Swing的UI
  • 浏览器不兼容性(大部分)由GWT负责 - 您只需编写Java代码,GWT将其编译为可在每个浏览器上运行

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

  • 如果您的服务器已经用Java编写,您仍然可以在GWT中编写UI,但是你会失去一些不错的功能
  • 使用GWT的编译时间是一项非常重要的成本 - 开发模式可以缓解这一点,但有时仍然存在问题
  • 正如其他人所说,与简单的JavaScript库(如jQuery或ExtJS)相比,GWT可被视为“冗长”

答案 2 :(得分: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框架,例如那些你提到过。

答案 3 :(得分:3)

Ext GWT对我的项目运作良好。高级支持一直很好。

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

完全在Java中进行开发是一项重要的好处,因为它有助于在添加功能时保持项目的可管理性。

答案 4 :(得分:2)

我目前正在开发一款比我预期更好的grail / flex混合应用程序。我看过GWT,但当时并没有很多关于它的书籍,它似乎强调利用我从未喜欢过的类似Swing的编程技术。我同意关于全力以赴的评论。运行他们都拥有的hello app并测量修改的难易程度。此外,工具(IDE,Maven,CI等)支持也可以成为立即生产的一个重要因素。

答案 5 :(得分:2)

不幸的是,答案是固执己见的,GWT最纯粹的形式并不是一个令人瞩目的焦点。话虽这么说,ExtJs GXT是超级笨拙的。我面对不断发展的框架所面临的一个主要问题是它们并非完全没有缺陷,如果我没记错的话,GWT 2.0的部分新布局缺少CSS样式。自从过去5天以来,我试图在ExtJs / GXT中解决一个问题:(,框架混淆了很多东西。我将使用任何绝对健壮的框架并提供相应的错误消息。我没有与其他人合作过

答案 6 :(得分: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
    }
}

这甚至超过了必要的两三行...

答案 7 :(得分:2)

我推荐Dojo。

除了它提供的大规模基础架构之外,Dojo 1.6也是第一个(也是唯一的)流行的JavaScript库,它可以成功地与Closure Compiler的高级模式一起使用,并且具有所有的大小,性能和混淆效益 - - 除了谷歌自己的Closure Library之外,就是这样。

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)可以在通过美化器后轻松进行逆向工程。

答案 8 :(得分:1)

ExtJs非常适合创建复杂的Web应用程序。 API提供了您在webapp中可以想象的任何内容,并且在一段时间后很容易扩展任何组件。

您可以将其插入任何后端(我们使用django或php),并在多个不同的应用程序中重用或扩展任何组件。

你需要几个月才能感觉到舒服。 IMHO。

也就是说,lib对于像网站这样的简单来说有点太慢了(那么你可以使用ExtCore)。但是当涉及到webapps时,这不是问题。

我不是一个java人,所以GWT对我来说不是一个选择:/

希望这会有所帮助