| GWT in Action | |
| author | Robert Hanson and Adam Tacy |
| pages | 600 |
| publisher | Manning Publications |
| rating | 6 |
| reviewer | Michael J. Ross |
| ISBN | 1933988231 |
| summary | A practical introduction to programming with the Google Web Toolkit (GWT). |
All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.
The more I learn about JavaScript... (Score:5, Insightful)
I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point. I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.
Well, almost. The problem with JavaScript is that it's horribly slow to execute. But then, you still have that problem, even if it's JavaScript generated from Java code.
Re: (Score:2, Funny)
duh... IIS and asp
@ Language=JavaScript
Re: (Score:3, Interesting)
Depends on your engine. I've put some thought into the same sort of server-side Javascript engine as you have. Someone else mentioned the Netscape Enterprise Server. That was... not so great. I was thinking more along the lines of building on top of a Java Servlet Engine. The Mozilla Rhino [mozilla.org] Javascript Engine actually compiles the JS down to Java byte code. That wouldn't be all that special, except that the JVM then JITs that to native code. Wh
Re: (Score:3, Interesting)
But then, you still have that problem, even if it's JavaScript generated from Java code.
That's not really what's going on.
GUI stuff happens in Javascript. Anything really complicated gets sent over to Java. That's why it's called an AJAX framework, not a Javascript framework.
I like Javascript, but it has the same problem as PHP: no namespaces. Using it as a real language would causes the same problems you see there: security issues, hard-to-read code, difficulty refactoring, interoperability problems, etc. You can actually see those problems and the various mechanisms to overcome them in
Re: (Score:2)
You can work around this by writing object-oriented Javascript, like this:
The only problem you run into is if you want to call a member function as a result of an event. I haven't found a good way to do this without using some sort of global varia
Re: (Score:2)
- Differences in browsers object models makes it counter-intuitive to write cross-browser JavaScript code, GWT can take care of these differences for you.
Re: (Score:2)
Netscape did that, back in the "four days", google up "server-side javascript".
> Well, almost. The problem with JavaScript is that it's horribly slow to execute.
Bullshit. The types of JOBS people usually try to do with JavaScript may be slow, however. Or the native methods that the javascript programs are using might be... But that's a far cry from making it a slow language. It's not substancially s
Re: (Score:2)
That's just goofy. Spidermonkey is quite a bit slower than Rhino. They both contain runtime compilers, but Spidermonkey has its own interpreter. Rhino compiles down to Java bytecode which is then JITed by the JVM. If you want performance, use Rhino!
Re: (Score:2)
Re: (Score:2)
Now that IS interesting, I wasn't aware of that. Thanks!
ATM, Spidermonkey seems to perform VERY well for my needs. I have used NJS in the past and been satistfied with it (from a speed perspective) as well.
Of course, when I profile my javascript code... only a VERY SMALL amount of time is spent in the JavaScript interpreter. Wall time is mostly consumed doing pesky things like I/O. So I tend to conce
Re: (Score:2)
The first thing I'd like are some of my favorite features from Common Lisp, like first class functions, ability to do procedural, functional, and object oriented programming with the same language, dynamic typing, macros, closures, and lexical scoping.
Having a C-like syntax would be good for people who are used to C or Perl and don't want to learn about s-expressions. Automatic memory management is a must.
So I
Re: (Score:2)
> But if you ever use it while only targetting a single browser, it's a dream to work with,
> and all of the annoyances go away.
I use JavaScript frequently, and have for years. I don't write much for the browser any more, but I often use JavaScript for general purpose projects.
I'm a hardcore C hacker, know enough LISP to write macros for emacs, and I totally agree with your assessment. About the only thing I RE
Re: (Score:2)
Funny thing is, so does, say, Perl (probably to an even greater degree... how do you do macros in Javascript? I know Perl allows script pre-processing modules). However, both language suffer from a flaw that I think makes it difficult to write large scale applications: weak typing. Dynamic typing, that kicks ass, absolutely. But *weak* typing creates a whole class of errors easily avoided with a strong type system, just so the program
Re: (Score:2)
Um, you understand that GWT is not a language, it is a framework, right? Java is the language. And JavaScript is most CERTAINLY not more powerful than Java.
Don't give in to the temptation because it would make you look quite foolish.
-matthew
Re: (Score:2)
I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point.
I think "the point of GWT" is clearly stated on their front page [google.com]. The ability to write your web application more like a real application. The ability to share client and server side code. The possibility of using a real debugger. Support for browser history (havn't seen this for AJAX before).. just to name a few.
Re: (Score:3, Informative)
I agree with you that Javascript is a nicer language than Java and more powerful to boot, but I'm using GWT for one big reason: dead code elimination. The GWT compiler takes advantage of the static analysis possibilities in Java and the closed-world nature of a web page and produces dramatically optimized Javascript. Th
Re: (Score:2)
I know, for one thing, that JavaScript started out as a horrible little language, and within a year or so, it became a beautiful little language. I imagine that we could do better, were the same thing attempted today.
Re: (Score:3, Informative)
Not. Java doesn't have closures. Java functions aren't first-class objects.
JavaScript, OTOH, isn't typed.
There's loads of differences between them. All I'd want from JavaScript is more performance, namespaces, and possibly some very basic native OO concepts so that I can define an inherited class without three or four declarations and maybe have private and static members.
Re: (Score:3, Insightful)
more info here [mozilla.org]
Re: (Score:2)
Would you care to explain? I've used all of these languages to some degree, and Javascript seems no better or worse than the others (well, depending on your preferences... Python and Ruby are both dynamically, strongly typed, and Javascript is dynamically, weakly typed. If you're prejudiced against the latter, then of course you'll prefer the
I Still don't know what GWT is (Score:5, Informative)
It's so simple, but... (Score:2, Troll)
Hell. No.
Re: (Score:3, Informative)
You don't actually write any SOAP code, but rather use Java Remoting to call across the wire, getting a Java object back that you can manipulate. The GWT compiler translates that into a XML request and writes all the serialization/deserialization code and so on. In fact it doesn't seem to be able to call an XML web service
Beyond hope (Score:5, Insightful)
Come on, doesn't anybody read these?
Re: (Score:2)
Re:Beyond hope (Score:5, Funny)
Parent
Just when you need mod points (Score:2)
Re: (Score:2)
GWT *and* Java (Score:5, Informative)
Before somebody grills me, the version of WindowBuilder Pro that I am using is a bit unstable and crashes Eclipse now and then. Lots of memory is also recommended (then again, if you are a developer, you need lots of memory anyway).
Re: (Score:3, Informative)
Nah, didn't think so
Why should GWT be on my radar screen? (Score:3, Insightful)
Oops. (Score:2)
I want to write desktop apps with JS/GWT/whatever (Score:3, Interesting)
JS is a great language and GWT is a great tool, especially the hosted development environment. But it will never reach its potential until it is a general purpose application programming language.
Very nice toolkit with some problems (Score:4, Informative)
The content on Google's GWT site [google.com] almost speaks for itself concerning the power of it, so I'll elaborate on some negative aspects I've encountered.
I went to explore the possibility of a non-servlet based backend and very quickly encountered problems that are not really GWT's fault but a side effect of having a hosted environment: the browser is based on Mozilla and thus inherits the security restrictions of it. I could not make RPC calls to my backend web server because Mozilla disallows cross-domain access. I spent a lot of time trying to circumvent this, and did find some work-arounds but nothing that worked to my satisfaction (too cumbersome). GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml [crossdomainxml.org] file in the root of the target webserver (to see whether access is allowed or not).
Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM. Setting up a 32bit JVM isn't that difficult, but it's not a good solution (However, I talked to a GWT developer on IRC who claimed this issue was high on their priority list).
Lastly, GWT is a nice environment, but it's still a bit young. It seems stable enough, but if you engage in a large GWT based project you may find yourself doing a lot of low-level client-side code unless their limited palette of widgets and other client-side features completely cover your needs
Shameless plug - chess board diagram composer (Score:4, Interesting)
Just a few hours ago I finished a small, mostly-for-fun project in GWT, and now I see a GWT-related story on slashdot. Surely it's not a coincidence and therefore I must pimp my project: a chess board diagram composer [jinchess.com].
GWT in Python and Ruby (Score:3, Informative)
So I want to give oyou two pointers to projects that could need help to transfer the idea of GWT from Java to Python and Ruby:
Python: pyjamas - build AJAX apps in Python (like Google did for Java) [pyworks.org].
Ruby: Blog Entry from Michael Neumann, who tries to port GWT to Ruby [ntecs.de].
The Ruby stuff is in the very early stages
Bye egghat.
Re:Wow (Score:5, Funny)
Parent
Re:Wow (Score:4, Interesting)
Is it just me or is anyone else glad to see a review on Slashdot without a chapter by chapter summary? One of the most pointless, pedantic mistakes in book reviews is to summarize each chapter. Hoozah for the writer!
Parent
Re:Wow (Score:4, Funny)
Don't Use Google Web Toolkit.
Parent
Worse than Wicket? (Score:4, Interesting)
I did an evaluation of it. I kind of liked it, but in general don't like "lets make a servlet environment pretend its an applet", so I didn't endorse.
Now, after months of using Wicket, I wish I had pimped for it more. Seriously. If you're gonna pretend it's an applet, then REALLY do it like GWT does, fake JVM and all. This Wicket stuff.... ugh. keeping the html view and java in synch for anythign complex is SO IRRITATING.
Seriously, after years of Struts and stuff like Wicket, I don't see any real advantage over "Model 2+" (Servlet/JSP pairs) that I started with in 2001. There is a benefit to simplicity and writing HTML in HTML and writing Javascript in Javascript that over-engineers who are, frankly, a little OO-obsessed just don't get.
Maybe years of Perl CGI has bent my brain but The HTTP Request/Response paradigm just doesn't seem so awful that it needs to be (leaky) abstracted away.
Parent
Re: (Score:2)
Re:Worse than Wicket? (Score:4, Insightful)
Maybe especially core Wicket, which isn't trying to do much but wrap HTML bits as objects. What really is the benefit of that? Nothing seems simpler and it often seems to be getting in the way-- maybe it's a mental gap problem, but often I end up having to put placeholder HTML in the page, and the set visibility = null. And the Ajax support is so-so.
I mean, I think the fact that the static Wicket homepages often produce session timeout exceptions is pretty damning that it encourages poor web programming.
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
You're obviously missing the point indeed. What it aims to do besides providing abstractions is facilitate a stateless programming model that is safe by default and doesn't leak implementation details of widgets all over the place.
Re:Worse than Wicket? (Score:5, Insightful)
I couldn't agree more. I like my code structured, clean and simple, and layering abstraction upon abstraction is not a good way to achieve that. I'm also a big proponent of writing to the language's strengths. JavaScript has some annoying weaknesses (lack of namespaces), but things like it's object prototyping are very powerful, and it seems silly to give that up. For all the browser inconsistencies, HTML + CSS is actually quite a nice layout tool. Getting them all to work together requires some organizational skills, but it pays off in ease of use and a higher level of control.
These are tools a web developer really should be comfortable with anyway, so while I can see the utility of something like GWT if you're not, to really excel at it, you should be knowledgeable about them.
Parent
Re: (Score:2, Interesting)
Sometimes I worry that I come up with my philosophy about languages to suit my personal gripes and history, and that ultimately that limits me as a developer, but...
Anytime you borrow someone else's toolkit that adds some kind of organization/abstraction over an existing technology... well, either you're losing bits of the functionality of the lower level, or what you're learning is about as complex as the lower level.
My strong personal preference is to write your OWN, app-specific organization.
The cou
Re:Worse than Wicket? (Score:4, Insightful)
Parent
Re: (Score:3, Insightful)
You can't really write a web application using a (single) language, though; you need to have some degree of expertise in HTML and CSS AND Javascript AND whatever language(s) your server-side code is written in...
I can see some appeal in toolkits that unify everything into just one language, for the developer's convenience. It's still pretty much impossible that the output of such a toolkit will be anywhere near as elegant or efficient as nativ
Re: (Score:3, Informative)
Firstly, I had loads of problems. However they were mainly down to broken stuff in the RC builds (all fixed now that it's out of beta) and the fact that I was learning Java as I went along. Nothing that was a major problem was down to the architecture of GWT.
If i'd have written pure javascript instead then doubtless it'd have taken far longer and worked less well.
GWT rocks for anything where yo
Re: (Score:3, Interesting)