Google Web Toolkit对开发复杂的javascripts有用吗？

Question

我非常喜欢javascript框架，特别是jQuery。我一直想设计像“plurk.com”这样的网站，但我知道它需要非常庞大的javascript.so关闭我。但是因为我来了解GWT，我我真的想测试它，并想问你是否使我们的工作比使用javascript或其框架更容易开发复杂的东西。你更喜欢哪一个？

Answer 1

I think a few of the answers on this question are quite un-informed, and I suspect that the people answering them have never used GWT on large scale projects. Yes GWT is a great way to do large AJAX websites, and for large complex sites, involving a back end as well, it kicks things like JQuery up and down the park. The way I always look at it is that javascript on it's own is great for doing small client side things. When you need to do something more complex (like dynamic fields, popups, animations) you bring in something like JQuery or Prototype. When you want to take it one step further you go with GWT.

People assume that because you write it in Java, it's designed for back end developers to do front end development. It's not. Java is simply the language that they chose, mainly because it's widely used, statically typed and there are lots of good editors out there for it.

I don't buy the leaky abstraction theory either, it doesn't try to fully abstract out the HTML elements, as it gives you direct access to both native javascript and the DOM if you choose to use those.

In short we've built very complex sites (one of which was featured on the GWT blog) in GWT, and also using other libraries like JQuery. I can tell you with 100% confidence that once you get your head around GWT it kills those other frameworks dead for complex tasks. It also has some great built in things that help make things better, and even does some things that no other framework supports (like the magic it can do with images). See this blog post for more details:

http://googlewebtoolkit.blogspot.com/2007/10/epo-builder-built-with-gwt.html

Answer 2

Few things scare me like "generated Javascript". The Law of Leaky Abstractions has got to be doubly true in these cases.

Writing effective cross-browser javascript is a tricky process of continuous refinement. Trying to decipher where some generated, obscured Javascript is going wrong is a major headache. It's bad enough fixing bugs in the pure JS libraries.

To me, GWT is a trick aimed at allowing backend developers to write front-end, in-browser code. Unfortunately, the realities of modern web apps mean you just have to know Javascript and the DOM. Something's going to break, and you're going to need to know why.

I think you're better off picking a good javascript library like jquery or prototype, and learning that well. Those libraries abstract away the sort of stuff that SHOULD be abstracted away and is unlikely to break in edge cases, like array operations and AJAX requests.

Answer 3

Yes, it does, since you'll be using Java and not Javascript.

Superb IDEs, static code analysis, searching and refactoring - all this will make your life much easier on large projects.

Answer 4

No. It doesn't.

It doesn't remove the complexity, it just makes it possible for you to deal with it from a Java Perspective. Since that gives you all the Tooling available from Java... that alone might make it worthwhile.

JavaScript IDEs are getting better and better though, and typically if you're using a Framework like jQuery or Prototype, then you're probably going to find it easier than dealing with a heavy weight abstraction layer like GWT.

My personal preference is to take the pure JavaScript approach, but that's because I like being able to work more closely to metal, and I'm disciplined enough to tame my JavaScript cats.

Answer 5

With GWT, you're not actually writing JavaScript; it's entire value proposition is that you can write Java that it will compile down to JavaScript for you.

Answer 6

I'm working on a project that has used GWT to pretty good effect. It's a good choice for us since we're all primarily Java developers working on internal tools. I can't speak to how useful it is for large end-user sites.

One advantage I particularly appreciate is the seamless object serialization and deserialization. Not only are the details of XML-RPC abstracted away, but since the same Java code is compiled to byte code for the server and javascript for the browser, you can code almost as if the server and client were running in separate class loaders in the same JVM. For instance, you can construct a Java object on the server, send it to the browser as the return value from an RPC service call and the browser code can then use the identical Java class to manipulate the object you just returned. Likewise, parameters to RPC calls can be constructed as Java objects, with the server receiving an identical Java object on the other end. All this without mucking about in the details of (de)serialization.