Iam a great fan of javascript frameworks especially jQuery .I have always wanted to design sites like "plurk.com" but i know that it needs very huge lines of javascript.so that shut me off.But since i came to know GWT , i really want to test it out and want to ask you if it makes our job easier to develop complex things than with the javascript or its frameworks .Which one would you prefer ?
+1
A:
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.
Hank Gay
2009-01-06 15:43:13
ya i know . but i just want to know , does that simplify the process of developing complex javascripts - very huge lines of javascript code ?
arshad
2009-01-06 15:48:13
I guess if you trust that google will do it better than you would and you know your Java it *could* do - personally I'm against it, but it probably has niche value for someone
annakata
2009-01-06 15:57:00
+2
A:
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.
Allain Lalonde
2009-01-06 15:59:44
+5
A:
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.
Yoni Roit
2009-01-06 16:02:28
+6
A:
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.
Triptych
2009-01-06 16:04:43
Do you think the same way about generated Assembler? Handling all those differences between different Processor architecures? I am not saying, that GWT is necessarily there yet. But Generating one language out of another is nothing scary at all.
Mo
2009-01-06 16:09:11
the problem is that since JS is a high-level language, there are several features you'd like to use. for example a hashtable. it's not exactly the same semantics as Java maps, so they write an emulation layer. therefore they're no longer usable as JS objects. same for other things...
Javier
2009-01-06 16:37:24
Another difference is that, besides being a much more mature technology, assembler is very highly tuned towards a single architecture. The same cannot be said of Javascript, which must support scores of different browsers and version.
Triptych
2009-01-06 17:24:50
not to mention that all modern cpu instruction sets are designed for the compiler, not for a human programmer; just like bytecodes are designed with a specific language in mind.
Javier
2009-01-06 18:09:40
I suspect you've never used GWT in a large scale project. It doesn't make cross browser stuff harder, it makes it easier. People worry about going through generated javascript, but the truth is you never have to, just like you never have to look at java byte code, because the compiler is top-notch.
rustyshelf
2009-01-06 22:03:25
disregarding whether compiled js is good or bad, gwt offers hosted mode debugging, and simple unit test integration, which is a must in large projects. However, there are some growing pains involved with gwt, but nothing too bad. GWT is more suitable for large scale ajax app vs medium scale ones.
Chii
2009-01-07 14:28:55
Using GWT is really no different then using jQuery or Prototype. If there is a bug in the library you are using, it will make your life difficult. The same problems exist for GWT. The difference is that GWT has Google's developers backing it up, not just the few people behind the other libraries.
Jack M.
2009-01-08 18:07:35
+2
A:
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.
Phil
2009-01-06 17:32:00
GWT doesnt actually use XML-RPC, but yea, the rest of the post is my sentiments exactly.
Chii
2009-01-07 14:29:41
+13
A:
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
rustyshelf
2009-01-06 22:01:12