I am a long time Java web developer and as most web developers I have used quite a lot of JavaScript. Even though I don't hate JavaScript as many other Java developers, I am still aware of its faults.
我是一名Java Web开发人员,而且作为大多数Web开发人员,我使用了大量的JavaScript。即使我不像许多其他Java开发人员那样讨厌JavaScript,我仍然意识到它的错误。
GWT is a way to write javascript using java. Since I know both languages for a long time I am pretty skeptical about this claim. I mean, I having a hard time believing that you can really create full Java dynamic web applications with a rich GUI using just GWT. That is why I am asking here if anyone had the chance to work with GWT on a large scale project. If so, I would really like to hear what they think of it.
GWT是一种使用java编写javascript的方法。由于我很长时间都了解这两种语言,所以我对这种说法持怀疑态度。我的意思是,我很难相信你可以使用GWT真正创建具有丰富GUI的完整Java动态Web应用程序。这就是为什么我在这里问是否有人有机会在大型项目上与GWT合作。如果是这样,我真的很想听听他们对此的看法。
11 个解决方案
#1
38
I've written fairly large sized app in GWT, and i have to say that i'm even more impressed by GWT than i was when the project started. My general 'feel' of the platform is that things are really well thought out, and they don't do things unless they can do it well, and can do it well on all browsers (IE users are still your users!)
我在GWT中编写了相当大的应用程序,我不得不说GWT比项目开始时给我的印象更深刻。我对平台的一般“感觉”是事情经过深思熟虑,除非他们能做得好,否则他们不做事情,并且可以在所有浏览器上做得很好(IE用户仍然是你的用户!)
Now, keep in mind that what GWT really excels at is the creation of large, highly dynamic single-page style webapps. If your goal is to enhance an otherwise static page with some javascript effects, than GWT is massive overkill (gquery may change this, but i don't have experience with gquery)
现在,请记住,GWT真正擅长的是创建大型,高度动态的单页面样式的webapps。如果你的目标是增强一个带有一些javascript效果的静态页面,那么GWT就是大规模的过度杀戮(gquery可能会改变这个,但我没有gquery的经验)
Some features I enjoy include:
我喜欢的一些功能包括:
- The ability to share code between the server side and the client side. (if your server side is written in java, of course). I didn't expect to use this a lot of this at first, but in practice, it can really save a lot of code duplication. However, i find that in general, this only works with code that has been written with GWT in mind - using code that was not written with GWT in mind often doesn't work well. This is because GWT only has a subset of the classes in the JDK, and in javascript, you have to care about performance a lot more than you do on the server side.
- It aims to achieve the fastest javascript, faster than you would ever write by hand (because if you did write it by hand, the code would be unmaintainable). The unfortunate reality is that the browsers that a lot of people use have incredibly slow javascript engines, so the performance of your javascript code matters a lot. Gwt's compiler is a real optimizing compiler - it will inline methods, intern all your strings. devirtualize your method calls when possible, etc. Because you are compiling for each browser and locale, the compiler can also inline browser-specific and locale-specific code. This Google I/O presentation has some benchmarks a few slides in.
- It will also automatically sprite your images together to minimize the number of http requests needed, again improving the speed of your site. GWT 2.0 will allow you to combine together arbitrary files.
- most of the files created by gwt have a strong hash as their filename, which lets you set the files to be cached forever, but not worry about people having old versions if the file changes
- The code splitting in GWT 2.0 is very impressive and would be very difficult to do by hand. As the size of your application grows, dealing with the size of your javascript matters more and more, and you need to be able to split it into chunks
- You are coding in a statically typed language. I know some people prefer dynamic typing, but i like to compare this debate to the emacs vs vi debate - there are a lot of smart people on both camps, and arguing on the internet isn't going to change anyone's preference
- You get to use a lot of the great tools that exist in the java ecosystem, which are generally a lot more mature than the equivilant javascript tools. - junit, java IDEs, java debuggers, refactoring, etc.
能够在服务器端和客户端之间共享代码。 (当然,如果你的服务器端是用java编写的)。我一开始并没有想到会使用这个,但在实践中,它确实可以节省大量的代码重复。但是,我发现一般情况下,这只适用于使用GWT编写的代码 - 使用不是用GWT编写的代码通常不能很好地工作。这是因为GWT只有JDK中的类的子集,而在javascript中,您必须比在服务器端更多地关注性能。
它旨在实现最快的javascript,比你手工编写的更快(因为如果你手工编写它,代码将无法维护)。不幸的是,很多人使用的浏览器都有非常慢的javascript引擎,因此你的javascript代码的性能非常重要。 Gwt的编译器是一个真正优化的编译器 - 它将内联方法,实习所有字符串。尽可能虚拟化方法调用等。因为您正在为每个浏览器和语言环境进行编译,所以编译器还可以内联特定于浏览器和特定于语言环境的代码。这个Google I / O演示文稿有一些基准测试。
它还会自动将您的图像精灵映射到一起,以最大限度地减少所需的http请求数量,从而再次提高您网站的速度。 GWT 2.0允许您将任意文件组合在一起。
gwt创建的大多数文件都有一个强大的哈希值作为文件名,这可以让你设置永久缓存的文件,但如果文件发生变化则不担心人们拥有旧版本
GWT 2.0中的代码拆分非常令人印象深刻,并且很难手工完成。随着应用程序的大小增加,处理javascript的大小越来越重要,并且您需要能够将其拆分为块
您使用静态类型语言编码。我知道有些人更喜欢动态打字,但我喜欢将这场辩论与emacs vs vi辩论进行比较 - 两个阵营都有很多聪明人,并且在互联网上争论并不会改变任何人的偏好
您可以使用Java生态系统中存在的许多优秀工具,这些工具通常比等效的javascript工具更成熟。 - junit,java IDE,java调试器,重构等。
#2
5
If you have familiarity with both JavaScript and Java, you really are perfectly suited to get the most out of GWT. What many people do not realize is that GWT is pretty well layered and that you can really decide which of those levels you want to work at.
如果您熟悉JavaScript和Java,那么您真的非常适合充分利用GWT。许多人没有意识到GWT是非常好的分层,你可以真正决定你想要在哪个级别工作。
For instance, I sometimes write directly against the DOM library for projects. Thats a lot like writing JavaScript code except you're able to use an IDE properly and get the power of a compiler. From the compiler I get static type checking, lots of good compiler optimizations, and (actually my favorite for maintaining code) debug mode assertions. Nobody ever really makes much of the ability to do assertions, but it's so nice to be able to compile a debug mode that does expensive checks to tease out bugs and then turn off the debug mode and have the code just evaporate. (Not just the assert statements go away, but all the code reachable from the asserts also gets compiled out).
例如,我有时直接针对项目编写DOM库。这很像编写JavaScript代码,除非你能够正确使用IDE并获得编译器的强大功能。从编译器我得到静态类型检查,许多良好的编译器优化,以及(实际上我最喜欢维护代码)调试模式断言。没有人真正能够做出很多断言的能力,但能够编译一个调试模式是非常好的,它可以进行昂贵的检查以排除错误,然后关闭调试模式并让代码消失。 (不仅断言语句消失了,而且从断言中可以获得的所有代码也被编译出来)。
Other times, I write code against GWT's UI library. That code looks a bit like swing or SWT code so it is most comfortable to pure java developers. Working at this level, you don't have to worry as much about the DOM and it is usually possible to construct an application without writing any JavaScript. You do occasionally run into a bug where something doesn't work consistently on a particular browser. The GWT folks consider those bugs.
其他时候,我针对GWT的UI库编写代码。该代码看起来有点像swing或SWT代码,因此对于纯Java开发人员来说这是最舒服的。在这个级别工作,您不必担心DOM,并且通常可以在不编写任何JavaScript的情况下构建应用程序。您偶尔会遇到一个错误,在某个特定浏览器上某些内容无法正常工作。 GWT人员会考虑这些错误。
You can kind of pick what level of abstraction you want to work at. There are tradeoffs at each level, but GWT should support them.
您可以选择想要使用的抽象级别。每个级别都有权衡,但GWT应该支持它们。
Also, full disclosure: I'm the dude in the video that Chi linked above, so you might say I'm pretty attached to GWT.
另外,完全披露:我是上面链接的视频中的家伙,所以你可能会说我非常依赖GWT。
#3
4
As with any tool, it needs to be used properly. One can wield a hammer skillfully and build something nice, or just wave it around at stuff and do more harm than good.
与任何工具一样,它需要正确使用。一个人可以巧妙地使用锤子并制造一些不错的东西,或者只是在东西上挥动它并且弊大于利。
Google Wave, I think, has become the prototype of "what's possible" with GWT.
我认为Google Wave已经成为GWT“可能”的原型。
It's still rather hard to find good GWT design patterns because the technology is too new, so that can harm efforts to develop a very rich, large-scale web app in GWT. Before beginning such a project, I would recommend looking at examples of the model-view-presenter (MVP) pattern and be sure to use it, or something like it, as a foundation for the control flow of your web app. One nice thing about GWT, and writing your code in Java, is that the high degree of abstraction and decoupling necessary for a clean MVP implementation is pretty easy (thanks to the compiler).
现在仍然很难找到好的GWT设计模式,因为这项技术太新了,因此可能会损害在GWT中开发一个非常丰富的大型Web应用程序的努力。在开始这样的项目之前,我建议查看模型 - 视图 - 演示者(MVP)模式的示例,并确保使用它或类似的东西作为Web应用程序控制流的基础。关于GWT以及用Java编写代码的一个好处是,清晰的MVP实现所需的高度抽象和解耦非常容易(感谢编译器)。
#4
4
I think GWT does what it says on the tin...
我认为GWT在锡上做的就是......
Top 5 Reasons for choosing GWT:
选择GWT的五大理由:
-
Tapestry can be overly complicated and the learning curve is pretty steep for new developers who are starting out \ joining the team. Esp. on larger projects.
Tapestry可能过于复杂,对于刚开始加入团队的新开发人员而言,学习曲线相当陡峭。 ESP。在较大的项目上。
-
I found that I could develop "richer" applications using GWT seeing that my strength is Java not Javascript. In order for me to implement similar functionality using Tapestry I would have to hand write Javascript which would later become a maintenance nightmare.
我发现我可以使用GWT开发“更丰富”的应用程序,因为我的优势是Java而不是Javascript。为了让我使用Tapestry实现类似的功能,我不得不亲自编写Javascript,这将成为维护的噩梦。
-
Browser compatibility, I would spend large amounts of time trying to get my hand written Javascirpt to work on all the different browsers (like I said Javascript is not my strength :-) The GWT Compiler hides me from this which results in me spending more time writing features.
浏览器兼容性,我会花大量时间试图让我的手写Javascirpt在所有不同的浏览器上工作(就像我说Javascript不是我的力量:-) GWT编译器隐藏了我这导致我花费更多时间写作功能。
-
Back button blues, GWT's History listener is handles the browsers back button in comparison to Tapestry.
后退按钮布鲁斯,与Tapestry相比,GWT的历史监听器处理浏览器后退按钮。
-
GWT has a smaller footprint because only the data is being sent across the wire apposed to refreshing the entire page.
GWT的占用空间较小,因为只有数据通过线路发送,以便刷新整个页面。
The list goes on but all in all, I am very happy to have made the change and have not looked back since.
这个名单还在继续,但总而言之,我很高兴能够做出改变并且从那时起就没有回头。
#5
3
I have created two quite substantial GWT applications in my three years at Google. It delivers what it promises - my apps were far more interactive and far more ajax-y than my knowledge of Javascript and my Javascript tooling would have let me produce using other tools.
我在谷歌的三年里创建了两个非常重要的GWT应用程序。它提供了它所承诺的东西 - 我的应用程序更具互动性,而且比我对Javascript的知识要多得多,而且我的Javascript工具会让我使用其他工具制作。
I also found the apps more interactive and more fun than the purely server-side alternatives I had used before moving to it.
我还发现这些应用程序比我之前使用的纯服务器端替代品更具交互性和趣味性。
It is not free of warts, but it is a very productive environment to do the kinds of apps I do.
它不是没有瑕疵,但它是一个非常高效的环境来做我做的各种应用程序。
And do watch Kelly's presentation. It, and some of the others from I/O, give a really clear idea of what GWT can do. You will pretty quickly get a good idea of whether it is the right tool for the task you are envisioning.
并观看凯莉的演讲。它以及I / O中的其他一些内容可以清楚地了解GWT可以做什么。您很快就会知道它是否是您正在设想的任务的正确工具。
#6
2
I've looked at it briefly for an older application at one of my jobs, and I must admit that it was very impressive. All the code was written in Java, and the javascript was built beautifully.
在我的一个工作中,我已经简要地查看了一个较旧的应用程序,我必须承认它非常令人印象深刻。所有代码都是用Java编写的,而javascript的构建非常精美。
It had AJAX, dynamic pages, the works. There are plugins for it as well, such as the Ext GWT framework.
它有AJAX,动态页面,作品。它也有插件,例如Ext GWT框架。
It's definitely worth looking into and trying out, but you may find that the development cycle doesn't "feel" right, so you might opt to use regular JavaScript.
它绝对值得研究和尝试,但您可能会发现开发周期“感觉”不正确,因此您可能选择使用常规JavaScript。
#7
1
I have been developing a green field application on GWT for a year and it has been surprisingly pleasant. The subset of Java used in GWT causes some headaches but nothing major after all. I didn't have too much JavaScript knowledge when I joined the project but I think that was not a problem.
我已经在GWT上开发了一年的绿色领域应用程序,这令人惊讶地令人愉快。 GWT中使用的Java子集会引起一些令人头疼但毕竟没什么大不了的。当我加入项目时,我没有太多的JavaScript知识,但我认为这不是问题。
The common GWT related problems I have encountered had usually something to do with Ext GWT/GXT framework or FCKEditor integration.
我遇到的常见的GWT相关问题通常与Ext GWT / GXT框架或FCKEditor集成有关。
#8
1
Simply GWT rocks google is making "google wave" fully on GWT.
简单GWT岩石谷歌正在GWT完全“google wave”。
#9
1
I didn't know much Javascript when I tried to create my website. In fact, that is why I had been putting off creating the website.
当我尝试创建我的网站时,我不太了解Javascript。事实上,这就是我推迟创建网站的原因。
So for me, GWT made a huge difference as it enabled me to create a dynamic, cross-browser website that I definitely would not have been able to create without putting in significant effort into learning Javascript.
所以对我来说,GWT产生了巨大的差异,因为它使我能够创建一个动态的跨浏览器网站,如果不花大力气学习Javascript,我绝对无法创建。
#10
0
I've done a few projects over a few years and it is fantastic. Going back to JS/JSP/request based framework is really horrible.
我已经做了几年的一些项目,这太棒了。回到基于JS / JSP / request的框架真是太可怕了。
Don't want to give up compile time checks, unit tests in my IDE, IDE refactoring etc, sharing code between different tiers, solid set of widgets, incredibly well thought out framework.
不想放弃编译时间检查,我的IDE中的单元测试,IDE重构等,在不同层之间共享代码,可靠的小部件集,令人难以置信的深思熟虑的框架。
Can do so much more so much faster in a maintainable way.
可以以可维护的方式更快地做到这么多。
#11
0
There is a steep learning curve, but for really dynamic ui applications, there is just no way that you can build from hand in javascript as efficiently. What I mean in particular is for instance an application frontend for a service where all the searchable fields and result type s and length were completely unknown. For this type of thing, a dynamic runtime defined ui, there is nothing better than GWT in my opinion.
有一个陡峭的学习曲线,但对于真正动态的ui应用程序,你无法像javascript一样高效地构建。我的意思特别是例如服务的应用程序前端,其中所有可搜索的字段和结果类型s和长度都是完全未知的。对于这种类型的东西,动态运行时定义了ui,在我看来没有比GWT更好的了。
The drawbacks are the steep learning curve(especially for non-swing Java programmers, traditional request/response servlet api guys and gals) and getting cornered into GWT once you make that decision.
缺点是陡峭的学习曲线(特别是对于非摆动的Java程序员,传统的请求/响应servlet api人和gals)以及一旦做出决定就进入GWT。
#1
38
I've written fairly large sized app in GWT, and i have to say that i'm even more impressed by GWT than i was when the project started. My general 'feel' of the platform is that things are really well thought out, and they don't do things unless they can do it well, and can do it well on all browsers (IE users are still your users!)
我在GWT中编写了相当大的应用程序,我不得不说GWT比项目开始时给我的印象更深刻。我对平台的一般“感觉”是事情经过深思熟虑,除非他们能做得好,否则他们不做事情,并且可以在所有浏览器上做得很好(IE用户仍然是你的用户!)
Now, keep in mind that what GWT really excels at is the creation of large, highly dynamic single-page style webapps. If your goal is to enhance an otherwise static page with some javascript effects, than GWT is massive overkill (gquery may change this, but i don't have experience with gquery)
现在,请记住,GWT真正擅长的是创建大型,高度动态的单页面样式的webapps。如果你的目标是增强一个带有一些javascript效果的静态页面,那么GWT就是大规模的过度杀戮(gquery可能会改变这个,但我没有gquery的经验)
Some features I enjoy include:
我喜欢的一些功能包括:
- The ability to share code between the server side and the client side. (if your server side is written in java, of course). I didn't expect to use this a lot of this at first, but in practice, it can really save a lot of code duplication. However, i find that in general, this only works with code that has been written with GWT in mind - using code that was not written with GWT in mind often doesn't work well. This is because GWT only has a subset of the classes in the JDK, and in javascript, you have to care about performance a lot more than you do on the server side.
- It aims to achieve the fastest javascript, faster than you would ever write by hand (because if you did write it by hand, the code would be unmaintainable). The unfortunate reality is that the browsers that a lot of people use have incredibly slow javascript engines, so the performance of your javascript code matters a lot. Gwt's compiler is a real optimizing compiler - it will inline methods, intern all your strings. devirtualize your method calls when possible, etc. Because you are compiling for each browser and locale, the compiler can also inline browser-specific and locale-specific code. This Google I/O presentation has some benchmarks a few slides in.
- It will also automatically sprite your images together to minimize the number of http requests needed, again improving the speed of your site. GWT 2.0 will allow you to combine together arbitrary files.
- most of the files created by gwt have a strong hash as their filename, which lets you set the files to be cached forever, but not worry about people having old versions if the file changes
- The code splitting in GWT 2.0 is very impressive and would be very difficult to do by hand. As the size of your application grows, dealing with the size of your javascript matters more and more, and you need to be able to split it into chunks
- You are coding in a statically typed language. I know some people prefer dynamic typing, but i like to compare this debate to the emacs vs vi debate - there are a lot of smart people on both camps, and arguing on the internet isn't going to change anyone's preference
- You get to use a lot of the great tools that exist in the java ecosystem, which are generally a lot more mature than the equivilant javascript tools. - junit, java IDEs, java debuggers, refactoring, etc.
能够在服务器端和客户端之间共享代码。 (当然,如果你的服务器端是用java编写的)。我一开始并没有想到会使用这个,但在实践中,它确实可以节省大量的代码重复。但是,我发现一般情况下,这只适用于使用GWT编写的代码 - 使用不是用GWT编写的代码通常不能很好地工作。这是因为GWT只有JDK中的类的子集,而在javascript中,您必须比在服务器端更多地关注性能。
它旨在实现最快的javascript,比你手工编写的更快(因为如果你手工编写它,代码将无法维护)。不幸的是,很多人使用的浏览器都有非常慢的javascript引擎,因此你的javascript代码的性能非常重要。 Gwt的编译器是一个真正优化的编译器 - 它将内联方法,实习所有字符串。尽可能虚拟化方法调用等。因为您正在为每个浏览器和语言环境进行编译,所以编译器还可以内联特定于浏览器和特定于语言环境的代码。这个Google I / O演示文稿有一些基准测试。
它还会自动将您的图像精灵映射到一起,以最大限度地减少所需的http请求数量,从而再次提高您网站的速度。 GWT 2.0允许您将任意文件组合在一起。
gwt创建的大多数文件都有一个强大的哈希值作为文件名,这可以让你设置永久缓存的文件,但如果文件发生变化则不担心人们拥有旧版本
GWT 2.0中的代码拆分非常令人印象深刻,并且很难手工完成。随着应用程序的大小增加,处理javascript的大小越来越重要,并且您需要能够将其拆分为块
您使用静态类型语言编码。我知道有些人更喜欢动态打字,但我喜欢将这场辩论与emacs vs vi辩论进行比较 - 两个阵营都有很多聪明人,并且在互联网上争论并不会改变任何人的偏好
您可以使用Java生态系统中存在的许多优秀工具,这些工具通常比等效的javascript工具更成熟。 - junit,java IDE,java调试器,重构等。
#2
5
If you have familiarity with both JavaScript and Java, you really are perfectly suited to get the most out of GWT. What many people do not realize is that GWT is pretty well layered and that you can really decide which of those levels you want to work at.
如果您熟悉JavaScript和Java,那么您真的非常适合充分利用GWT。许多人没有意识到GWT是非常好的分层,你可以真正决定你想要在哪个级别工作。
For instance, I sometimes write directly against the DOM library for projects. Thats a lot like writing JavaScript code except you're able to use an IDE properly and get the power of a compiler. From the compiler I get static type checking, lots of good compiler optimizations, and (actually my favorite for maintaining code) debug mode assertions. Nobody ever really makes much of the ability to do assertions, but it's so nice to be able to compile a debug mode that does expensive checks to tease out bugs and then turn off the debug mode and have the code just evaporate. (Not just the assert statements go away, but all the code reachable from the asserts also gets compiled out).
例如,我有时直接针对项目编写DOM库。这很像编写JavaScript代码,除非你能够正确使用IDE并获得编译器的强大功能。从编译器我得到静态类型检查,许多良好的编译器优化,以及(实际上我最喜欢维护代码)调试模式断言。没有人真正能够做出很多断言的能力,但能够编译一个调试模式是非常好的,它可以进行昂贵的检查以排除错误,然后关闭调试模式并让代码消失。 (不仅断言语句消失了,而且从断言中可以获得的所有代码也被编译出来)。
Other times, I write code against GWT's UI library. That code looks a bit like swing or SWT code so it is most comfortable to pure java developers. Working at this level, you don't have to worry as much about the DOM and it is usually possible to construct an application without writing any JavaScript. You do occasionally run into a bug where something doesn't work consistently on a particular browser. The GWT folks consider those bugs.
其他时候,我针对GWT的UI库编写代码。该代码看起来有点像swing或SWT代码,因此对于纯Java开发人员来说这是最舒服的。在这个级别工作,您不必担心DOM,并且通常可以在不编写任何JavaScript的情况下构建应用程序。您偶尔会遇到一个错误,在某个特定浏览器上某些内容无法正常工作。 GWT人员会考虑这些错误。
You can kind of pick what level of abstraction you want to work at. There are tradeoffs at each level, but GWT should support them.
您可以选择想要使用的抽象级别。每个级别都有权衡,但GWT应该支持它们。
Also, full disclosure: I'm the dude in the video that Chi linked above, so you might say I'm pretty attached to GWT.
另外,完全披露:我是上面链接的视频中的家伙,所以你可能会说我非常依赖GWT。
#3
4
As with any tool, it needs to be used properly. One can wield a hammer skillfully and build something nice, or just wave it around at stuff and do more harm than good.
与任何工具一样,它需要正确使用。一个人可以巧妙地使用锤子并制造一些不错的东西,或者只是在东西上挥动它并且弊大于利。
Google Wave, I think, has become the prototype of "what's possible" with GWT.
我认为Google Wave已经成为GWT“可能”的原型。
It's still rather hard to find good GWT design patterns because the technology is too new, so that can harm efforts to develop a very rich, large-scale web app in GWT. Before beginning such a project, I would recommend looking at examples of the model-view-presenter (MVP) pattern and be sure to use it, or something like it, as a foundation for the control flow of your web app. One nice thing about GWT, and writing your code in Java, is that the high degree of abstraction and decoupling necessary for a clean MVP implementation is pretty easy (thanks to the compiler).
现在仍然很难找到好的GWT设计模式,因为这项技术太新了,因此可能会损害在GWT中开发一个非常丰富的大型Web应用程序的努力。在开始这样的项目之前,我建议查看模型 - 视图 - 演示者(MVP)模式的示例,并确保使用它或类似的东西作为Web应用程序控制流的基础。关于GWT以及用Java编写代码的一个好处是,清晰的MVP实现所需的高度抽象和解耦非常容易(感谢编译器)。
#4
4
I think GWT does what it says on the tin...
我认为GWT在锡上做的就是......
Top 5 Reasons for choosing GWT:
选择GWT的五大理由:
-
Tapestry can be overly complicated and the learning curve is pretty steep for new developers who are starting out \ joining the team. Esp. on larger projects.
Tapestry可能过于复杂,对于刚开始加入团队的新开发人员而言,学习曲线相当陡峭。 ESP。在较大的项目上。
-
I found that I could develop "richer" applications using GWT seeing that my strength is Java not Javascript. In order for me to implement similar functionality using Tapestry I would have to hand write Javascript which would later become a maintenance nightmare.
我发现我可以使用GWT开发“更丰富”的应用程序,因为我的优势是Java而不是Javascript。为了让我使用Tapestry实现类似的功能,我不得不亲自编写Javascript,这将成为维护的噩梦。
-
Browser compatibility, I would spend large amounts of time trying to get my hand written Javascirpt to work on all the different browsers (like I said Javascript is not my strength :-) The GWT Compiler hides me from this which results in me spending more time writing features.
浏览器兼容性,我会花大量时间试图让我的手写Javascirpt在所有不同的浏览器上工作(就像我说Javascript不是我的力量:-) GWT编译器隐藏了我这导致我花费更多时间写作功能。
-
Back button blues, GWT's History listener is handles the browsers back button in comparison to Tapestry.
后退按钮布鲁斯,与Tapestry相比,GWT的历史监听器处理浏览器后退按钮。
-
GWT has a smaller footprint because only the data is being sent across the wire apposed to refreshing the entire page.
GWT的占用空间较小,因为只有数据通过线路发送,以便刷新整个页面。
The list goes on but all in all, I am very happy to have made the change and have not looked back since.
这个名单还在继续,但总而言之,我很高兴能够做出改变并且从那时起就没有回头。
#5
3
I have created two quite substantial GWT applications in my three years at Google. It delivers what it promises - my apps were far more interactive and far more ajax-y than my knowledge of Javascript and my Javascript tooling would have let me produce using other tools.
我在谷歌的三年里创建了两个非常重要的GWT应用程序。它提供了它所承诺的东西 - 我的应用程序更具互动性,而且比我对Javascript的知识要多得多,而且我的Javascript工具会让我使用其他工具制作。
I also found the apps more interactive and more fun than the purely server-side alternatives I had used before moving to it.
我还发现这些应用程序比我之前使用的纯服务器端替代品更具交互性和趣味性。
It is not free of warts, but it is a very productive environment to do the kinds of apps I do.
它不是没有瑕疵,但它是一个非常高效的环境来做我做的各种应用程序。
And do watch Kelly's presentation. It, and some of the others from I/O, give a really clear idea of what GWT can do. You will pretty quickly get a good idea of whether it is the right tool for the task you are envisioning.
并观看凯莉的演讲。它以及I / O中的其他一些内容可以清楚地了解GWT可以做什么。您很快就会知道它是否是您正在设想的任务的正确工具。
#6
2
I've looked at it briefly for an older application at one of my jobs, and I must admit that it was very impressive. All the code was written in Java, and the javascript was built beautifully.
在我的一个工作中,我已经简要地查看了一个较旧的应用程序,我必须承认它非常令人印象深刻。所有代码都是用Java编写的,而javascript的构建非常精美。
It had AJAX, dynamic pages, the works. There are plugins for it as well, such as the Ext GWT framework.
它有AJAX,动态页面,作品。它也有插件,例如Ext GWT框架。
It's definitely worth looking into and trying out, but you may find that the development cycle doesn't "feel" right, so you might opt to use regular JavaScript.
它绝对值得研究和尝试,但您可能会发现开发周期“感觉”不正确,因此您可能选择使用常规JavaScript。
#7
1
I have been developing a green field application on GWT for a year and it has been surprisingly pleasant. The subset of Java used in GWT causes some headaches but nothing major after all. I didn't have too much JavaScript knowledge when I joined the project but I think that was not a problem.
我已经在GWT上开发了一年的绿色领域应用程序,这令人惊讶地令人愉快。 GWT中使用的Java子集会引起一些令人头疼但毕竟没什么大不了的。当我加入项目时,我没有太多的JavaScript知识,但我认为这不是问题。
The common GWT related problems I have encountered had usually something to do with Ext GWT/GXT framework or FCKEditor integration.
我遇到的常见的GWT相关问题通常与Ext GWT / GXT框架或FCKEditor集成有关。
#8
1
Simply GWT rocks google is making "google wave" fully on GWT.
简单GWT岩石谷歌正在GWT完全“google wave”。
#9
1
I didn't know much Javascript when I tried to create my website. In fact, that is why I had been putting off creating the website.
当我尝试创建我的网站时,我不太了解Javascript。事实上,这就是我推迟创建网站的原因。
So for me, GWT made a huge difference as it enabled me to create a dynamic, cross-browser website that I definitely would not have been able to create without putting in significant effort into learning Javascript.
所以对我来说,GWT产生了巨大的差异,因为它使我能够创建一个动态的跨浏览器网站,如果不花大力气学习Javascript,我绝对无法创建。
#10
0
I've done a few projects over a few years and it is fantastic. Going back to JS/JSP/request based framework is really horrible.
我已经做了几年的一些项目,这太棒了。回到基于JS / JSP / request的框架真是太可怕了。
Don't want to give up compile time checks, unit tests in my IDE, IDE refactoring etc, sharing code between different tiers, solid set of widgets, incredibly well thought out framework.
不想放弃编译时间检查,我的IDE中的单元测试,IDE重构等,在不同层之间共享代码,可靠的小部件集,令人难以置信的深思熟虑的框架。
Can do so much more so much faster in a maintainable way.
可以以可维护的方式更快地做到这么多。
#11
0
There is a steep learning curve, but for really dynamic ui applications, there is just no way that you can build from hand in javascript as efficiently. What I mean in particular is for instance an application frontend for a service where all the searchable fields and result type s and length were completely unknown. For this type of thing, a dynamic runtime defined ui, there is nothing better than GWT in my opinion.
有一个陡峭的学习曲线,但对于真正动态的ui应用程序,你无法像javascript一样高效地构建。我的意思特别是例如服务的应用程序前端,其中所有可搜索的字段和结果类型s和长度都是完全未知的。对于这种类型的东西,动态运行时定义了ui,在我看来没有比GWT更好的了。
The drawbacks are the steep learning curve(especially for non-swing Java programmers, traditional request/response servlet api guys and gals) and getting cornered into GWT once you make that decision.
缺点是陡峭的学习曲线(特别是对于非摆动的Java程序员,传统的请求/响应servlet api人和gals)以及一旦做出决定就进入GWT。