2010-03-18 114 views
7

从下面的框架列表中,您将使用哪一个开发一个丰富的Web应用程序,以及为什么您会选择其他应用程序?哪个Web应用程序框架?

SproutCore的 GWT ExtJS的 GXT SmartGWT的 道场/ Dijit的 的Flex 卡普琴糯 Grails的

+0

什么?没有电梯?电梯和GWT一起美味。添加一些谷歌应用程序引擎的面食基地的混合和重击,你有自己的营养晚餐。 – 2010-03-18 05:15:15

+1

Downvoting this question?这不是一个*坏问题*它只是不太可能会有任何明确的答案... – 2010-03-18 05:30:59

+1

我同意不可能有一个明确的答案,但让人们对这些框架的意见在一定程度上肯定是有用的。我会接受所提供的最翔实和客观的答案。 – Fergal 2010-03-18 05:55:21

回答

5

这些都是基于使用你所提到的框架,我个人的经验。所以,是的,这是一个有点偏。因此,正如其他人说了一遍又一遍,确定您的要求和其根据人们在此提出的建议,您认为一个符合您的要求:

  • GWT是太冗长eventhough我发现许多Java开发人员喜欢GWT,因为你可以单元测试,这一切都在Java中。但我个人不喜欢它,因为它远非简单。有些时候,我觉得我可以用Javascript稍微调整一下,但是对于GWT,我强制要用几行Java代码来完成它。
  • GXT现在离GWT太远了,你会发现很难做事情,因为GXT有自己的做法,这与GWT有很大的不同。当复杂的需求出现时,最终你会回去做简单的GWT。噢,他们的技术支持不是很好,或者我向他们提出几个问题时遇到了一些不好的经历。
  • EXT-JS是好简单的东西以及外观和感觉真的很光滑。但是当事情变得越来越复杂时,你就会打起仗来。尽管我已经处理了GXT技术支持,但我还没有处理ExtJS技术支持,因为他们有不同的人,尽管它在一家公司,所以我不能说太多。
  • Flex很好,真的很好。但是对于简单的东西来说,这又是好事。一旦事情变得更复杂,你会写很多动作,这是不太愉快的。有很多东西可用于开箱,如果您必须使用Javascript进行编码(如多媒体支持),则可能会遇到困难。哦,如果你正在写一个公共网站,你必须考虑到不是太多的用户在他们的浏览器上有Flash插件。
  • Grails,我不确定你将如何使用Grails实现RIA应用程序,因为Grails只是另一个MVC框架,您需要在其上添加自己的RIA框架,比如您提到的框架。
+1

你确定你已经看过GWT足以评论它的简单性吗?我刚刚开始使用它,实际上我很惊讶它的清洁和简单。 – 2010-03-18 16:09:40

+1

这些天来人们使用GWT和MVP模式,这个模式太冗长而复杂。 – 2010-03-18 21:16:22

5

这是严格见仁见智。你不会得到任何人的明确答案,因为任何人的答案都会有他们个人喜欢的。

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

这就是说,我更喜欢GWT。其他人总是不同意我的看法。

的原因,我喜欢GWT:

  • 你可以分享(一些)客户端和服务器端的代码(只要你的服务器是用Java编写的)
  • GWT使得很多先进的性能功能非常简单(如递延JS加载,图片组合,CSS混淆)
  • 一家专注于单页的应用程序,与第三方支持的地方(使用gwt-presenter库)
  • 这只是为方便地添加GWT到现有的网页,因为它是创建一个完整的一年ge GWT应用程序
  • UiBinder允许您使用声明式HTML语法编写您的UI;如果你不想要
  • 浏览器不兼容性(大部分)由GWT处理 - 你只需编写Java代码,并且GWT编译它在每个浏览器上工作

的事情,可能使GWT不适合你:

  • 如果您的服务器已经被写入的东西,除了Java中,你仍然可以写在GWT你的用户界面,但你会失去了一些不错的功能
  • 使用GWT编译时间是一个不平凡的成本 - 开发模式减轻SA很多,但它仍然是有时
  • 正如其他人所说,GWT可以被认为是“冗长”的问题比较简单的JavaScript库,如jQuery或ExtJS的
2

我目前工作的一个圣杯/柔性混合应用程序这比我预期的要好得多。我曾看过GWT,但当时没有太多关于它的书,它似乎强调了我从来不喜欢的类似Swing的编程技术的利用。我同意关于全部尝试的评论。运行他们都有的应用程序,并测量它的修改难度或容易程度。此外,工具(IDE,Maven,CI ...等)的支持也可以成为立即生产力的重要因素。

2

不幸的是,答案将是自以为是的,GWT的最纯粹的形式不是一个眼睛的糖果。这就是说,ExtJs GXT超级豪爽。我面对不断变化的框架所面临的一个主要问题是它们不是绝对没有缺陷的,如果我没有记错的话,那么GWT 2.0就会出现一些新的布局缺失的CSS样式。我试图从最近5天开始在ExtJs/GXT中遇到问题:(框架混淆了很多东西,我将使用任何绝对健壮的框架,并给出相应的错误消息,尽管我没有与其他人一起工作

6

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

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 
    } 
} 

而这甚至二,三线超过必要的...

3

分机GWT已经工作以及我的项目。高级支持一直很好。

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

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

1

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

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

您需要几个月才能感觉舒适。恕我直言。

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

我不是一个java的家伙,所以GWT是不是一种选择对我来说:/

希望这有助于

2

我建议道场。

除了提供的大量基础架构外,Dojo 1.6也是第一个(也是唯一)流行的JavaScript库,可以成功地用于Closure Compiler的高级模式,并且所有的大小,性能和混淆优势都附加在它上面 - 除了Google自己的Closure Library之外,就是。

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

换句话说,使用道场的程序可以是100%的混淆 - 即使库本身。

编译后的代码与纯文本代码具有完全相同的行为,除了它比规模更小(平均值比平均值高25%),运行速度更快(特别是在移动设备上),并且几乎不可能进行反向工程,甚至在通过美化器之后,因为整个代码库(包括库)都被混淆了。

只有“缩小”的代码(例如YUI压缩器,Uglify)可以在穿过美化器后轻松地进行反向设计。

相关问题