哪个web应用程序框架[[关闭]

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

• GWT公司
• GXT公司 现在离GWT太远了,你会发现做事情很困难,因为GXT有自己的做事方式,这与GWT太不一样了。当复杂的需求出现时,最终您将返回到普通GWT。哦,他们的技术支持也不是很好,因为我在问他们几个问题时有过一些不好的经历。
• 分机JS
• 弯曲
• 圣杯 ,我不确定如何用Grails实现RIA应用程序,因为Grails只是另一个MVC框架,您需要在上面添加自己的RIA框架,比如您提到的那些框架。

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

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

我喜欢GWT的原因:

• GWT使许多高级性能特性变得非常简单(例如,延迟JS加载、图像spring、CSS模糊处理)
• gwt-presenter
• 将GWT添加到现有网页和创建一个完整的单页GWT应用程序一样简单
• UiBinder
• 浏览器的不兼容性(大部分)由GWT来处理——您只需编写Java代码,GWT就可以编译它在每个浏览器上工作

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

• 如果您的服务器已经用Java以外的语言编写,那么您仍然可以用GWT编写UI,但是您将失去一些不错的特性
• 正如其他人提到的,与jQuery或ExtJS等简单JavaScript库相比,GWT可以被认为是“冗长的”

然而,该项目是供内部使用的,这使得部署仅限于一个操作系统上的一个浏览器,并且没有做出任何努力来更改Ext GWT的默认外观或行为。

完全在Java中开发是一个关键的好处,因为它有助于在添加特性时保持项目的可管理性。

我们在这里使用Grails+ExtJS。由于我们试图创建一个惯用的ExtJS应用程序,Grails并没有得到充分的利用,尽管在服务器端使用Grails而不是JSP仍然是有意义的。

为什么是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
    }
}

不幸的是,答案将是固执己见的,GWT在其最纯粹的形式是不是一个眼睛糖果。也就是说,ExtJs GXT是超级健壮的dory。我在不断发展的框架中面临的一个主要问题是,它们并不是绝对没有缺陷的,如果我没记错的话,gwt2.0在发布时,有些新布局缺少CSS样式。我试图在ExtJs/GXT中解决一个问题,因为过去5天:(,框架混淆了很多东西。我将使用任何绝对健壮并给出适当错误消息的框架。但我没有和其他人一起工作过。

除了它提供的庞大的基础设施之外,Dojo 1.6还是第一个(也是唯一一个)流行的JavaScript库,它可以成功地与闭包编译器的高级模式结合使用,除了Google自己的闭包库之外,它还具有所有的大小、性能和模糊处理优势。

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

只有“小型化”的代码(例如YUI compressor,Uglify)可以在通过美化器后轻松地进行反向工程。

ExtJs非常适合创建复杂的web应用程序。这个API提供了你在webapp中所能想象到的任何东西,而且在一段时间后扩展任何组件都非常容易。

你需要几个月的时间来适应它。依我拙见

也就是说,lib有时对于像网站这样的simples ui来说有点太慢了(然后可以使用ExtCore)。但当谈到webapps时,这不是一个问题。

我不是java人,所以GWT不是我的选择:/

希望这有帮助