我个人厌倦了浏览器的不一致。如果别人已经解决了这个问题，我宁愿不再这样做。这就是为什么我对 cappuccino 和 qooxdoo 等前端越来越感兴趣。它们是零 HTML 零 CSS 解决方案。
I'm personally tired of browser inconsistencies. If someone else has solved the problem, I'd rather not do it again. That's why I'm getting more interested in front ends like cappuccino and qooxdoo. They are a zero-HTML zero-CSS solution.
These are based on my personal experiences using the frameworks you have mentioned. So yes, it is a bit biased. So as others have said over and over again, define your requirements and which one do you think fits your requirement based on what people have suggested here.
GWT is too verbose eventhough I found many Java developers love GWT because you can unit test it and it's all in Java. But I personally don't like it because it is far from being simple. There are times when I feel I can tweak a little bit with Javascript, but with GWT I am enforced to do it with several lines of Java code.
GXT is too far from GWT these days and you will find it difficult to do things as GXT has its own way of doing things which is way too different from GWT. When complex requirement come up, in the end you are going to go back doing plain GWT. And oh, their technical support is not that good either as I had several bad experiences when asking few questions to them.
Ext-JS is good for simple stuff and the look and feel is really slick. But when things gets more complex, you are going to fight you're way through. Eventhough I have dealt with the GXT tech support, I haven't dealt with the ExtJS tech support since they have different people eventhough it's in one company, so I can't say much.
Flex is nice, really nice. But again it is good for simple stuff. Once things gets more complicated you are going to write lots of actionscript, which is less enjoyable. There are many things that is available out of the box which may be to difficult if you have to code it in Javascript, like multimedia support. And oh, if you are writing for a public website you must consider that not too many user has flash plugin on their browser.
Grails, I'm not sure how you would implement RIA apps with Grails since Grails is just another MVC framework which you need to add your own RIA framework on top of it such as the ones that you have mentioned.
This is strictly a matter of opinion. You will not get any definitive answers from anyone, since anyone that answers will have one or another that they personally prefer.
Try each one for long enough to decide which one is best for your (or your team's) purposes.
That being said, I prefer GWT. Others will invariably disagree with me.
Reasons that I like GWT:
You can share (some) client- and server-side code (as long as your server is written in Java)
GWT makes a lot of advanced performance features really easy (e.g., deferred JS loading, image spriting, CSS obfuscation)
A focus on one-page apps, with third-party support for Places (using the gwt-presenter library)
It's just as easy to add GWT to an existing web page as it is to create a full one-page GWT app
UiBinder allows you to write your UI using a declarative HTML-like syntax; you're not stuck writing Swing-like UI if you don't want to
Browser incompatibilities are (mostly) taken care of by GWT -- you just write Java code, and GWT compiles it to work on every browser
Things that may make GWT not right for you:
If your server is already written in something besides Java, you will still be able to write your UI in GWT, but you'll lose out on some nice features
Compilation time using GWT is a non-trivial cost -- Development Mode mitigates this a lot, but it's still an issue sometimes
As others have mentioned, GWT can be considered "verbose" compared to simple JavaScript libraries like jQuery or ExtJS
Ext GWT has worked well for my project. The premium support has been good.
However the project is for internal use which has allowed deployment to be restricted to one browser on one OS, and no effort has been made to change the default appearance or behaviour of Ext GWT.
Developing entirely within Java is a key benefit as it helps to keep the project manageable as features are added.
I am currently working on a grail/flex hybrid app that is working a lot better than I expected. I have looked at GWT but there were not a lot of books about it at the time and it seemed to stress the leveraging of Swing-like programming techniques which I have never liked. I agree with the comment about trying them all out. Run hello app they all have and measure how hard or easy it is to modify. Also tool (IDEs, Maven, CI...etc) support can be a big factor as well in terms of being immediately productive.
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
}
}
甚至比必要的多了两三行......
We are using Grails+ExtJS here. Since we try to make an idiomatic ExtJS application, Grails is not fully utilized, though it still makes sense to use Grails instead of, say, JSP, for the server-side part.
Why ExtJS: Because it's a very rich toolkit for GUI-like web applications. Our job is to replace an old Motif GUI, so this is exactly what we need.
Why Grails: Because it gets the job done easily and quickly. For the communication with the ExtJS part, we need a lot of JSON, and in Grails it's like that:
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
}
}
And that's even two or three lines more than necessary...
Unfortunately the answer will be opinionated, GWT in it's purest form is not an eye-candy. That being said, ExtJs GXT is super hunky dory. One of the major issues I face with evolving frameworks is that they are not absolutely defect free, If I remember correctly, GWT 2.0 was shipped out with missing CSS styles for some of the new layouts. I am trying to trouble shoot an issue in ExtJs/GXT since last 5 days :(, frameworks obfuscate a lot of things. I will go with any framework that is absolutely robust and gives appropriate error messages. I haven't worked with others though.
In addition to the massive infrastructure it provides, Dojo 1.6 is also the first (and only) popular JavaScript Library that can be successfully used with the Closure Compiler's Advanced mode, with all the size, performance and obfuscation benefits attached to it -- other than Google's own Closure Library, that is.
In other words, a program using Dojo can be 100% obfuscated -- even the library itself.
Compiled code has exactly the same behavior as plain-text code, except that it is much smaller (average 25% over minifiers), runs much faster (especially on mobile devices), and almost impossible to reverse-engineer, even after passing through a beautifier, because the entire code base (including the library) is obfuscated.
Code that is only "minified" (e.g. YUI compressor, Uglify) can be easily reverse-engineered after passing through a beautifier.
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 :/
发布评论
评论（9）
我个人厌倦了浏览器的不一致。如果别人已经解决了这个问题，我宁愿不再这样做。这就是为什么我对 cappuccino 和 qooxdoo 等前端越来越感兴趣。它们是零 HTML 零 CSS 解决方案。
I'm personally tired of browser inconsistencies. If someone else has solved the problem, I'd rather not do it again. That's why I'm getting more interested in front ends like cappuccino and qooxdoo. They are a zero-HTML zero-CSS solution.
这些是基于我使用您提到的框架的个人经验。所以是的，这有点偏见。因此，正如其他人一再说过的那样，根据人们在这里的建议来定义您的要求，以及您认为哪一个适合您的要求。
These are based on my personal experiences using the frameworks you have mentioned. So yes, it is a bit biased. So as others have said over and over again, define your requirements and which one do you think fits your requirement based on what people have suggested here.
这完全是一个见仁见智的问题。您不会从任何人那里得到任何明确的答案，因为任何回答的人都会有他们个人更喜欢的一个或另一个答案。
尝试每种方法足够长的时间，以确定哪一种最适合您（或您的团队）的目的。
话虽这么说，我更喜欢 GWT。其他人总是会不同意我的观点。
我喜欢 GWT 的原因：
UiBinder允许您使用声明性 HTML 编写 UI类似语法；如果您不想。不适合您：
This is strictly a matter of opinion. You will not get any definitive answers from anyone, since anyone that answers will have one or another that they personally prefer.
Try each one for long enough to decide which one is best for your (or your team's) purposes.
That being said, I prefer GWT. Others will invariably disagree with me.
Reasons that I like GWT:
UiBinderallows you to write your UI using a declarative HTML-like syntax; you're not stuck writing Swing-like UI if you don't want toThings that may make GWT not right for you:
Ext GWT 对我的项目效果很好。溢价支持一直很好。
然而，该项目仅供内部使用，允许部署仅限于一种操作系统上的一种浏览器，并且没有做出任何努力来更改 Ext GWT 的默认外观或行为。
完全使用 Java 进行开发是一个关键优势，因为它有助于在添加功能时保持项目的可管理性。
Ext GWT has worked well for my project. The premium support has been good.
However the project is for internal use which has allowed deployment to be restricted to one browser on one OS, and no effort has been made to change the default appearance or behaviour of Ext GWT.
Developing entirely within Java is a key benefit as it helps to keep the project manageable as features are added.
我目前正在开发一个 grail/flex 混合应用程序，它的工作效果比我预期的要好得多。我看过 GWT，但当时关于它的书籍并不多，而且它似乎强调利用类似 Swing 的编程技术，而我从来不喜欢这种技术。我同意关于尝试所有这些的评论。运行他们都有的 hello 应用程序，并测量修改的难易程度。此外，工具（IDE、Maven、CI...等）支持对于立即提高生产力而言也是一个重要因素。
I am currently working on a grail/flex hybrid app that is working a lot better than I expected. I have looked at GWT but there were not a lot of books about it at the time and it seemed to stress the leveraging of Swing-like programming techniques which I have never liked. I agree with the comment about trying them all out. Run hello app they all have and measure how hard or easy it is to modify. Also tool (IDEs, Maven, CI...etc) support can be a big factor as well in terms of being immediately productive.
我们这里使用 Grails+ExtJS。由于我们试图创建一个惯用的 ExtJS 应用程序，因此 Grails 并未得到充分利用，尽管在服务器端部分使用 Grails 而不是 JSP 仍然有意义。
为什么选择 ExtJS：因为它是一个非常丰富的工具包，适用于类似 GUI 的 Web 应用程序。我们的工作是替换旧的 Motif GUI，所以这正是我们所需要的。
为什么选择 Grails：因为它可以轻松快速地完成工作。为了与 ExtJS 部分通信，我们需要大量的 JSON，在 Grails 中是这样的：
甚至比必要的多了两三行......
We are using Grails+ExtJS here. Since we try to make an idiomatic ExtJS application, Grails is not fully utilized, though it still makes sense to use Grails instead of, say, JSP, for the server-side part.
Why ExtJS: Because it's a very rich toolkit for GUI-like web applications. Our job is to replace an old Motif GUI, so this is exactly what we need.
Why Grails: Because it gets the job done easily and quickly. For the communication with the ExtJS part, we need a lot of JSON, and in Grails it's like that:
And that's even two or three lines more than necessary...
不幸的是，答案是固执己见的，最纯粹的 GWT 并不美观。话虽这么说，ExtJs GXT 是超级棒的。我在不断发展的框架中面临的主要问题之一是它们并非完全没有缺陷，如果我没记错的话，GWT 2.0 发布时缺少一些新布局的 CSS 样式。自过去 5 天以来，我一直在尝试解决 ExtJs/GXT 中的问题:(，框架混淆了很多事情。我会使用任何绝对强大并提供适当错误消息的框架。不过我还没有与其他人合作过。
Unfortunately the answer will be opinionated, GWT in it's purest form is not an eye-candy. That being said, ExtJs GXT is super hunky dory. One of the major issues I face with evolving frameworks is that they are not absolutely defect free, If I remember correctly, GWT 2.0 was shipped out with missing CSS styles for some of the new layouts. I am trying to trouble shoot an issue in ExtJs/GXT since last 5 days :(, frameworks obfuscate a lot of things. I will go with any framework that is absolutely robust and gives appropriate error messages. I haven't worked with others though.
我推荐道场。
除了提供的大规模基础设施之外，Dojo 1.6 也是第一个（也是唯一一个）流行的 JavaScript 库，可以成功地与闭包编译器的高级模式一起使用，并具有附加的所有大小、性能和混淆优势 - 除了就是 Google 自己的 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）在经过美化器后可以轻松进行逆向工程。
I'd recommend Dojo.
In addition to the massive infrastructure it provides, Dojo 1.6 is also the first (and only) popular JavaScript Library that can be successfully used with the Closure Compiler's Advanced mode, with all the size, performance and obfuscation benefits attached to it -- other than Google's own Closure Library, that is.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
In other words, a program using Dojo can be 100% obfuscated -- even the library itself.
Compiled code has exactly the same behavior as plain-text code, except that it is much smaller (average 25% over minifiers), runs much faster (especially on mobile devices), and almost impossible to reverse-engineer, even after passing through a beautifier, because the entire code base (including the library) is obfuscated.
Code that is only "minified" (e.g. YUI compressor, Uglify) can be easily reverse-engineered after passing through a beautifier.
ExtJs 非常适合创建复杂的 Web 应用程序。该 API 提供了您可以在 Web 应用程序中想象到的任何内容，并且在一段时间后扩展任何组件非常容易。
您可以将其插入任何后端（我们使用 django 或 php），并在多个不同的应用程序中重用或扩展任何组件。
您需要几个月的时间才能适应它。恕我直言。
也就是说，对于像网站这样的简单用户界面来说，lib 有时有点太慢了（那么你可以使用 ExtCore）。但对于网络应用程序来说，这不是问题。
我不是一个java人，所以GWT对我来说不是一个选择：/
希望这有帮助
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