为什么我应该使用jQuery而不是GWT?

I need to decide between jQuery and GWT for my new project.

我需要为我的新项目在jQuery和GWT之间做出选择。

I haven't programmed in JavaScript for a while, and I was looking into GWT for the last few days. It looks pretty awesome, generating all the different JS for different browsers and all, however:

我有一段时间没有使用JavaScript编程了，最近几天我一直在研究GWT。它看起来非常棒，为不同的浏览器生成所有不同的JS，但是:

developing in Java takes more time than the same thing using jQuery (at least for this project)
使用jQuery在Java中进行开发要比使用jQuery花费更多的时间(至少在这个项目中)
the documentation is poor (for example, how should I know which elements should I use when designing the page? -- there's not enough documentation for this)
文档很差(例如，我如何知道在设计页面时应该使用哪些元素?——这里没有足够的文档)

I've been using jQuery for most of my projects and it's pretty good.

在我的大部分项目中，我都使用jQuery，它非常好。

I want to convince the client that jQuery is better suited for this project and I need more arguments to support this.

我想让客户相信jQuery更适合这个项目，我需要更多的参数来支持它。

14 个解决方案

#1

I would go with JQuery.

我会选择JQuery。

I once maintained a GWT project that eventually forced me to re-write it twice. First as a refactored GWT app, second in JQuery.

我曾经维护一个GWT项目，最终迫使我重新编写它两次。首先是重构的GWT应用，其次是JQuery。

I haven't touched Javascript seriously for a very long time. The last time was about 2002. I'm a Java developer so my first impression of GWT was awesome. But that was just the impression.

很长一段时间我都没有认真接触过Javascript。上一次是在2002年。我是一个Java开发人员，所以我对GWT的第一印象非常棒。但这只是我的印象。

Problems I found with GWT:

我发现GWT存在的问题:

It forces you to follow its client/server structure. In the end all I want is AJAX and those good widgets. GWT's widgets by itself don't seem that good-looking. Aesthetically, I prefer Adobe Flex! But to keep the comparison closer, JQuery's UI looks better than GWT's. In addition you have that wonderful Theme Roller support from JQuery.

它迫使您遵循它的客户端/服务器结构。最后，我想要的是AJAX和那些好的小部件。GWT的小部件本身并不是那么好看。在美学上，我更喜欢Adobe Flex!但是为了更紧密地进行比较，JQuery的UI看起来比GWT的要好。此外，您还有来自JQuery的出色主题滚轮支持。
I've tried DWR. It's great. It's far easier to enable AJAX in your Java code using DWR than GWT.

我试过了DWR。太棒了。使用DWR在Java代码中启用AJAX要比使用GWT简单得多。
If you're using GWT, eventually you will be forced to learn JavaScript. Arjen of SpringSource once said about XML and SOAP (though not the exact quote): "How can you develop WebServices and not know XML? SOAP is XML. You can't avoid it". Same thing with GWT. It's still Javascript in the end.

如果使用GWT，最终您将*学习JavaScript。SpringSource的Arjen曾经说过XML和SOAP(虽然不是确切的引用):“如何开发web服务而不了解XML?SOAP是XML。你不能避免它”。GWT也是一样。最终还是Javascript。
Realistically, Javascript isn't that hard to learn vs Java. More people know Javascript than Java. Even web designers know it. You're a programmer, and you're scared of Javascript?

实际上，与Java相比，Javascript并不是那么难学。知道Javascript的人比知道Java的人多。甚至连网页设计师都知道这一点。你是一个程序员，你害怕Javascript?
Back to the project I rewrote. When I rewrote our GWT application it took me almost two months to rewrite it. With JQuery it took me two weeks, and I was rusty with JavaScript.

回到我重写的项目。当我重新编写GWT应用程序时，我花了将近两个月的时间重写它。使用JQuery花了我两周的时间，我对JavaScript已经生疏了。
With JQuery you don't really write hardcorde JavaScript. That's why you use JQuery in the first place. Maintaining code with GWT is horrible. You wanna see the latest changes you did in the code... go compile... wait for GWT... 5 minutes... rinse... and repeat and hope it doesn't throw an error. If it does, you'll be recompiling again, and waiting for another 5 minutes. Rinse and repeat. With JQuery change a line, refresh your browser. Done.

使用JQuery，您不必真正编写hardcorde JavaScript。这就是为什么首先使用JQuery。用GWT维护代码是很可怕的。你想看看你在代码中做的最新修改……去编译…等待GWT……5分钟……冲洗……重复并希望它不会出错。如果是这样，您将再次重新编译，并等待另外5分钟。清洗和重复的方法。使用JQuery更改行，刷新浏览器。完成了。

I know I'm not being objective here, but I'm just sharing my experience :) The moral is don't be scared of Javascript. Google uses Javascript anyway

我知道我在这里不是客观的，但我只是分享我的经验:)寓意是不要害怕Javascript。谷歌使用Javascript无论如何

#2

I would suggest using GWT for teams with people who don't understand JavaScript but are (perhaps) more comfortable with Java. With GWT, you're likely to save yourself days if not weeks in compatibility testing, and will avoid a lot of common JavaScript pitfalls that people new to the language smash into. GWT also has great packaging features for CSS sprites, embedded data, and more.

我建议将GWT用于不理解JavaScript但(可能)更喜欢Java的团队。使用GWT，您可以在兼容性测试中节省几天甚至几周的时间，并且可以避免许多新接触到这种语言的人可能会遇到的常见JavaScript陷阱。GWT对于CSS精灵、嵌入式数据等也有很好的打包特性。

However, if you know and understand JavaScript, I would use JavaScript, whatever your library of choice may be. Although I haven't had a chance to inspect GWT's generated code too closely, I saw some examples at Google I/O, and while it looked all candy and sparkles, you're likely create more elegant JavaScript code doing it the ol' fashioned way.

但是，如果您了解并理解JavaScript，我将使用JavaScript，无论您选择的库是什么。虽然我还没有机会仔细检查GWT生成的代码，但是我在谷歌I/O上看到了一些示例，虽然看起来很漂亮，但是您很可能会创建更优雅的JavaScript代码，以ol的方式进行。

#3

If your group is most familiar with Java and you're planning on doing significant amounts of client-side functionality then you should at least evaluate GWT. The type safety, Eclipse debugging and shared code between the server-side/client-side will feel comfortable to your Java development team.

如果您的团队最熟悉Java，并且您计划做大量的客户端功能，那么您至少应该评估GWT。类型安全、Eclipse调试和服务器端/客户端之间的共享代码将使Java开发团队感到舒适。

However, if your team is used to JavaScript programming with jQuery or another JavaScript library then it may be easier to stick to a technology that is pure JavaScript. GWT has a way of taking over large sections of the page, which is unfamiliar to most JavaScript developers. By take over the page I mean that typical GWT code likes to create its own DOM Elements instead of adding functionality to existing Elements on the page. This is why many GWT apps have a "loading..." screen when the page first loads. This isn't necessary, but it's the most common style of GWT development.

但是，如果您的团队习惯于使用jQuery或其他JavaScript库进行JavaScript编程，那么可能更容易坚持使用纯JavaScript技术。GWT有一种方法可以接管页面的大部分内容，这对大多数JavaScript开发人员来说是陌生的。通过接管页面，我的意思是典型的GWT代码喜欢创建自己的DOM元素，而不是向页面上的现有元素添加功能。这就是为什么许多GWT应用程序在页面首次加载时都有一个“load…”屏幕。这不是必需的，但它是GWT开发中最常见的样式。

The fact that generated code comes out of GWT is less relevant for most GWT developers. GWT allows you to compile Java into something equivalent a normal java *.class file but in a JavaScript syntax that the web browser understands how to interpret. GWT acts much more like a compiler than a template-driven code generator. There are times that you will need to inspect the generated code but for the most part your debugging will be in Java via your Java debugger.

生成的代码来自GWT这一事实对大多数GWT开发人员来说并不重要。GWT允许您将Java编译成相当于普通Java *的东西。类文件，但在JavaScript语法中，web浏览器理解如何解释。GWT更像一个编译器，而不是模板驱动的代码生成器。有时您需要检查生成的代码，但是在大多数情况下，您的调试将通过Java调试器在Java中进行。

Another thing to think about is that regardless of the client-side technology you choose, your development team will need to be familiar with HTML, JavaScript, CSS and browser programming in general. GWT lets you write client-side code in a familiar Java environment but it doesn't hide the fact that you're working from within a browser.

另一个需要考虑的问题是，不管您选择什么客户端技术，您的开发团队都需要熟悉HTML、JavaScript、CSS和浏览器编程。GWT允许您在熟悉的Java环境中编写客户端代码，但它不会隐藏您在浏览器中工作的事实。

#4

First of all comparing GWT with jQuery doesn't make much sense. While jQuery was build to make cross browser working with the DOM much easier, GWT is build to create large web applications.

首先，将GWT与jQuery进行比较没有多大意义。虽然jQuery的构建是为了让跨浏览器更容易地使用DOM，但是GWT的构建是为了创建大型web应用程序。

So if you a bunch of static sides with some independent widgets, like calendar, slider and so on, jQuery is enough. If you want to build single page app, maybe with a large team, GWT is the better way. GWT has a lot well design architecture under the hood, especially the build in MVP pattern, UI-Binder templating system, i18n support etc.

如果你有一些独立的控件，比如日历，滑动器等等，jQuery就足够了。如果您想构建单页应用程序，也许需要一个大型团队，GWT是更好的方法。GWT有很多很好的设计架构，特别是MVP模式的构建、UI-Binder模板系统、i18n支持等。

So as JavaScript developer working more than year on a large GWT app, I would recommend never ever build a single page app only with jquery cause it wasn't build for. If you wanna use JavaScript take a look at backbone, spine, knockout or dojo.

因此，作为一个在大型GWT应用上工作了多年的JavaScript开发人员，我建议永远不要只使用jquery构建一个页面应用，因为它不是为jquery构建的。如果您想使用JavaScript，请查看主干、脊柱、击倒或dojo。

Btw, as good the GWT architecture is build, you will have a lot of JAVA overhead. So if you project is growing, the time to compile your css and i18n properties will come annoying.

顺便说一句，由于构建了良好的GWT体系结构，您将会有大量的JAVA开销。因此，如果您的项目正在增长，编译css和i18n属性的时间将会变得很烦人。

#5

"Horses for Courses"

“马课程”

Pick whichever one makes the most sense for the project. Some things to consider

选择最适合这个项目的。有些事情需要考虑

Tight timescales and more familiar with one over the other
时间紧迫，而且更熟悉其中一个
Speed and maintainability for other developers to use the chosen tool. Prevalence of one over the other may have implications here too
其他开发人员使用所选工具的速度和可维护性。其中一种的流行程度可能在这里也有影响
Have any code that could be used already in the project e.g. plugins, utility functions, etc.
有任何可以在项目中使用的代码，例如插件、实用功能等。

Without knowing specifics about what the project is about, what your experience is and how open the client is to using different technologies/frameworks, there will be no decisive answer here.

如果不了解项目的具体内容、您的经验以及客户对使用不同技术/框架的开放程度，这里就没有决定性的答案。

Make that list of compelling arguments for one over the other, as I have started here and then discuss with others involved on the project to come to a conclusion.

把这些引人注目的论点一一列举出来，就像我在这里开始的那样，然后与项目相关的其他人讨论得出结论。

#6

The answer is not easy. The answer is "it depends":

答案并不容易。答案是“视情况而定”:

GWT:

吕震中本:

if you know and like Java
如果你知道并且喜欢Java
if your server code is also written in Java, writing client code in Java makes it possible to use the same code on client and server
如果您的服务器代码也是用Java编写的，那么用Java编写客户机代码可以在客户机和服务器上使用相同的代码
if you like things provided by strongly-typed languages: compile-time type checking, automated refactoring, automated code generation (Ctrl+1 in Eclipse), code completion (Ctrl+Space)
如果您喜欢强类型语言提供的内容:编译时类型检查、自动重构、自动代码生成(Eclipse中的Ctrl+1)、代码完成(Ctrl+Space)
if you like component-oriented programming (eg MenuBar creates a menu)
如果您喜欢面向组件的编程(例如MenuBar创建一个菜单)
if complexity of GWT (compared to jQuery) is not problem for you
如果GWT(与jQuery相比)的复杂性对您来说不是问题
if big generated code is not a problem for you
如果大型生成的代码对您来说不是问题的话

jQuery:

if you know and like JavaScript
如果你知道并且喜欢JavaScript的话
you don't need to use the same code on client and server (eg. client - JS, server - Java or PHP)
您不需要在客户端和服务器上使用相同的代码。客户端- JS，服务器- Java或PHP)
if you don't need compile-time type checking, automated refactoring, etc
如果您不需要编译时类型检查、自动重构等等。
if you don't need component-oriented programming (to create a complex component in jQuery you need to create a series of divs, and call $("those divs").makeXXXXControl())
如果不需要面向组件的编程(要用jQuery创建复杂的组件，需要创建一系列div，并调用$(“那些div”).makeXXXXControl())
if you like simplicity (jQuery is simpler than GWT)
如果您喜欢简单性(jQuery比GWT更简单)
if you need very small code (eg to make website loading faster)
如果你需要非常小的代码(如使网站加载速度更快)

Personally I would recommend GWT for most projects, but jQuery also has pros and some people may prefer jQuery.

我个人建议大多数项目使用GWT，但jQuery也有优点，有些人可能更喜欢jQuery。

#7

I agree with Russ Cam that it depends on what your team is familiar with. When I am doing work for my personal business apps, I much prefer GWT. I find javascript, even with jquery, to have annoying object oriented syntax. If you have an app with 10,000 lines of UI code, jquery strikes me as something that would lead to a mess of hard to maintain code with poor reuse.

我同意Russ Cam的观点，这取决于你的团队熟悉什么。当我为我的个人业务应用程序工作时，我更喜欢GWT。我发现javascript，即使是jquery，也有令人讨厌的面向对象语法。如果你有一个拥有10,000行UI代码的应用程序，jquery会让我觉得它会导致一堆难以维护的代码，而且重用性很差。

Does anyone know of a large scale project done in jquery?

有人知道用jquery完成的大型项目吗?

I think if you are trying to squeeze every last byte out of the resulting filesize, don't use any library and write the javascript from scratch (ie: google homepage fade effect).

我认为，如果您试图从产生的文件大小中挤出最后一个字节，请不要使用任何库并从头开始编写javascript(即:谷歌主页褪色效果)。

Something to think about regarding javascript/jquery versus gwt. If you use common object oriented principles and design patterns, you will likely get better performing code with gwt. Why?

关于javascript/jquery和gwt，需要考虑一些问题。如果您使用面向对象的通用原则和设计模式，您可能会使用gwt获得性能更好的代码。为什么?

Let's take the example of polymorphism. If you write an app that uses heavy polymorphism in javascript, you will get the benefit of maintanability and code reuse this provides. However, your code will also get the performance hit of using polymorphism.

我们以多态性为例。如果您编写的应用程序在javascript中使用了大量的多态性，那么您将获得可维护性和代码重用的好处。但是，您的代码也将受到使用多态性的性能影响。

Now, if you used gwt, you will also get the benefit of maintanability and code reuse this provides, BUT the gwt compiler will optimize away the polymorphism into concrete class usage, hence increasing performance.

现在，如果您使用gwt，您也会得到维护和代码重用的好处，但是gwt编译器会将多态性优化为具体的类使用，从而提高性能。

#8

I think GWT is too much abstraction. Javascript is in fact a powerful language. You can write object oriented code and use namespaces. With a library like jQuery you won't have to worry about browser compatibility issues for most of what you do. With all the great browser developer tools available (like Firebug) in all major browsers now a days it is very easy to work with javascript. When a javascript error occurs I can easily pinpoint where it happened in my code. I can watch variables and know all that is going on in detail because I am working against code I wrote (unlike GWT).

我认为GWT太抽象了。Javascript实际上是一种强大的语言。您可以编写面向对象的代码并使用名称空间。使用jQuery这样的库，您不必担心大多数工作的浏览器兼容性问题。现在所有主要浏览器都有各种优秀的浏览器开发工具(比如Firebug)，使用javascript非常容易。当出现javascript错误时，我可以很容易地指出它在代码中的位置。我可以监视变量并详细了解所有的情况，因为我正在处理我编写的代码(与GWT不同)。

#9

The main problems I see with GWT vs. a native Javascript solution (jQuery or others) are:

我在GWT和原生Javascript解决方案(jQuery或其他)中看到的主要问题是:

There is an additional process that separates you from your final product. You develop your app in Java and you debug the Java code, yet you release a machine translated version of this code. For a decently sized app I can't imagine that you won't need to debug the actual code running on the browser at times, and this is going to be a headache, since it isn't your code.

还有一个额外的流程将您与最终产品区分开来。您使用Java开发应用程序，调试Java代码，但是您发布了这个代码的机器翻译版本。对于一个相当大的应用程序，我无法想象您不需要调试在浏览器上运行的实际代码，这将是一个令人头痛的问题，因为它不是您的代码。
Since you write your code in Java you are limited to use Java libraries. If you find some JS library that you like it would be awfully difficult to add it to your GWT project, you may need to write a Java wrapper for it. If you are developing native JS you can just add it to your project.

由于您使用Java编写代码，所以只能使用Java库。如果您找到一些您喜欢的JS库，将其添加到GWT项目中是非常困难的，您可能需要为它编写一个Java包装器。如果您正在开发本机JS，可以将其添加到项目中。
JS is an awesome language in its own right, with a solid object model that is different than Java's. I have developed a few apps in native JS for HP webOS and was surprised to find that many of the preconceptions I had about the language were not true. You can write clean, efficient and maintainable code in JS as much as you can in Java, and if you take the time to understand the JS object model you won't even need to use a support library to mimic a more typical class/object model like those of Java and C++ on top of JS. Javascript's prototypes are pretty cool.

JS本身就是一种很棒的语言，有一个与Java不同的实体对象模型。我为HP webOS开发了一些基于本地JS的应用程序，我惊讶地发现，我对该语言的许多先入之见都是错误的。您可以编写干净、高效和可维护的代码JS尽可能在Java中,如果你花时间去了解JS对象模型你甚至不需要使用一个支持库模仿更典型的类/对象模型像Java和c++ JS。Javascript的原型很酷。
If you may ever consider releasing your app on mobile platforms, then a native JS app can easily be wrapped inside phonegap and have access to several mobile platforms, without additional effort. There is a GWT wrapper for phonegap as well, but going back to my first item, if you have the choice to work with the real thing then why choose a solution that requires translation/emulation?

如果你曾经考虑过在移动平台上发布你的应用程序，那么一个本地的JS应用程序可以很容易地封装在phonegap中，并且可以访问几个移动平台，而不需要额外的努力。phonegap也有一个GWT包装器，但是回到我的第一个条目，如果您可以选择使用真实的东西，那么为什么要选择需要翻译/模拟的解决方案呢?

Good luck.

祝你好运。

#10

All the great tips and no one spoke about JSNI! A feature in GWT that allows you to use javascript if you wish.

所有伟大的提示，没有人谈论JSNI!GWT中的一个特性，允许您使用javascript。

https://developers.google.com/web-toolkit/doc/latest/DevGuideCodingBasicsJSNI

#11

jQuery = low-level understanding

jQuery =低层次的理解

Aside from the normal one javascript and the other is java explanation, Jquery has a closer one-to-one mapping with javascript while GWT is more abstracted away. So if you prefer to have a deeper understanding of what's happening with your code at the low-level (javascript) then jquery is the right way.

除了普通的一个javascript和另一个java解释之外，Jquery与javascript有更紧密的一对一映射，而GWT则更抽象。因此，如果您更喜欢对底层(javascript)代码中发生的事情有更深入的了解，那么jquery是正确的方法。

GWT = abstraction understanding = functional guarantee

GWT =抽象理解=功能保证

GWT offers the advantage of compiler generated code so it may offer more of guarantee that your website will function normally. However like any large scale API you need to take the time to understand what this class does and what that class does and whether or not it is compatible with this API or nor.

GWT提供了编译器生成代码的优势，因此它可以提供更多的保证，保证您的网站正常运行。但是，与任何大型API一样，您需要花时间了解这个类做什么，这个类做什么，以及它是否与这个API或nor兼容。

low-level understanding may be more useful

低层次的理解可能更有用

Personally I get much more satisfaction from coding the low-level myself. I have built some web applications at work from pure javascript that functioned flawlessly. Once wrote javascript code that took data from a database and generated a complete microsoft word research report. The complexity of this project demanded a lower-level grasp of javascript. I'm not sure this could have been done easily with a java based solution.

就我个人而言，我从编写底层代码中获得了更多的满足感。我已经使用纯javascript构建了一些正在运行的web应用程序，这些应用程序运行良好。曾经编写javascript代码，从数据库中获取数据并生成完整的microsoft word研究报告。这个项目的复杂性要求对javascript的理解更低。我不确定使用基于java的解决方案是否可以轻松实现这一点。

GWT reassures managers but costly

GWT使管理者放心，但代价高昂

But then again java and asp.net tend be preferred by larger companies b/c there is greater technical support (i.e. Oracle and Microsoft) and uptight on-the-edge managers tend to get better sleep at night when they know they can solve problem A by simply paying x amount of dollars for support. So after adopting the system they soon start realizing that technical support costs too much and it's cheaper to pay more for better developers. Hence a java or .net career will usually put food on the table.

但是，java和asp.net更倾向于大公司b/c，有更大的技术支持(比如Oracle和Microsoft)，紧张的边缘管理人员会在晚上睡得更好，因为他们知道只要支付x美元的支持，他们就能解决问题A。因此，在采用这个系统之后，他们很快就意识到技术支持的成本太高了，为更好的开发人员支付更多的费用也更便宜了。因此，java或。net职业通常会把食物摆在桌面上。

Maintainability

可维护性

Also API's like GWT are easier to maintain. I could only imagine the horror that someone would go through if they had to debug my javascript code. But that was before I became a better and cleaner programmer and since I knew every aspect of the code there is nothing to debug b/c there was never a problem with it.

同样，像GWT这样的API更容易维护。我只能想象，如果有人不得不调试我的javascript代码，会有多么可怕。但那是在我成为一个更好、更干净的程序员之前，因为我知道代码的每个方面，所以没有什么可以调试b/c的，它从来没有问题。

Low-level coding gives you almost a 100% understanding of what is happening, however with API's you spend time playing bug detective on google and posting questions on sites like *. But managers don't understand this b/c most aren't programmers.

低级别编码让您几乎100%了解正在发生的事情，但是使用API，您将花费时间在谷歌上玩bug检测，并在*这样的站点上发布问题。但是经理们不理解这个b/c，大多数不是程序员。

#12

GWT is a compiler (Java to JavaScript) and jQuery is a framework. You don't have to choose one over the other. You can use one of them, both or neither.

GWT是编译器(Java到JavaScript)， jQuery是框架。你不必选择其中之一。你可以使用其中的一个，要么两者都用，要么两者都不用。

For instance you can code in Java if you want to or have existing source code and then use jQuery for other stuff. There are available wrappers, but GWT can call JavaScript (and vice versa) see http://svenbuschbeck.net/wordpress/2012/06/how-to-use-jquery-in-gwt/

例如，如果您想要或有现有的源代码，可以使用Java编写代码，然后使用jQuery进行其他工作。有可用的包装器，但是GWT可以调用JavaScript(反之亦然)参见http://svenbuschbeck.net/wordpress/2012/06/how-to-use-jquery-in-gwt/

#13

my personal opinion would be for jQuery but thats because I never use Java and really like using the jQuery plugins.

我的个人观点是jQuery，但这是因为我从来没有使用过Java，而且非常喜欢使用jQuery插件。

#14

Active user group and recent gaining popularity clearly indicates jQuery is the winner.

活跃的用户组和最近的流行明显表明jQuery是赢家。

#1