Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GWT in Action

samzenpus posted about 7 years ago | from the read-all-about-it dept.

216

Michael J. Ross writes "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts — including more robust integrated development environments (IDEs). In contrast, Web-focused languages, such as JavaScript, benefit from the global accessibility of the Internet. Bridging this gap, and leveraging the strengths of both sides, has long been an objective of the software development community — though not all attempts have been successful, e.g., Java applets. The Google Web Toolkit (GWT) is the latest attempt, and shows considerable promise, as illustrated in a new book intended to help programmers learn this new technology: GWT in Action." Read on for the rest of Michael's reviewWritten by Robert Hanson and Adam Tacy, this book was published by Manning Publications on 5 June 2007, under the ISBNs 1933988231 and 978-1933988238. For any prospective reader who would like to learn more about the book, they can first try the book's Web page, where they will find online versions of the "about this book" section, table of contents, preface, and index. The publisher offers two freely downloadable chapters, "Creating the Default Application" and "Communicating with GWT-RPC," in PDF format. In addition, there is a link to purchase the book's electronic version, and a link to the author's forum, where readers can post questions about the book or GWT, and likely receive a response — perhaps even by one of the authors.

The book's 17 chapters are organized into four parts, and cover a generous number of topics: introduction to GWT; creating the default GWT application; building your own application based upon the default one; creating widgets and panels, including composite panels; processing user events; creating JSNI components; modularizing your code; communicating using GWT-RPC; client-side RPC; classic Ajax and HTML forms; using JSON for interoperability; automatically generating code; GWT's native properties; testing and deploying GWT applications; more on the inner workings of GWT itself. The book has no appendices, but a substantial index, which is essential for such a technically detailed subject area.

GWT in Action is clearly intended to be a practical and fairly comprehensive coverage of Google's new toolkit. Almost all of the GWT concepts are explained within the context of developing a substantial sample application, the Dashboard, created by the authors. The reader is encouraged to follow along as the authors build the application, thereby learning from doing — almost always an effective approach. At 600 pages, with almost none of the formatting padding found in far too many technical books nowadays, the authors have not skimped on providing the reader with a lot of information. Furthermore, their treatment of application deployment is far better than any other I have encountered.

Unfortunately, the book has many weaknesses. On an overall basis, the order of presentation is at times disjointed — seemingly dictated more by the Dashboard and less by the most logical order for someone new to GWT. Compounding the problem, the authors frequently refer to advanced topics, covered in greater detail later, and also repeat earlier information, occasionally several times. Despite promises to provide a gentle exposition, it can be difficult at times for the reader to determine if any critical steps were skipped, as a consequence of key instructions for building the sample application being spread out, and interspersed with too many references to general comments covered earlier. In turn, readers will likely find it frustrating to try to get the sample application working at each step of the development process — and not just at the end, with the complete code.

One source of these difficulties, is that in the first few chapters, the authors try to introduce too many topics all at once, and as a result do not thoroughly discuss each one in its own section. Instead, they break up the information over multiple sections, scattered throughout the book. An example of this is internationalization. Section 2.2.4 is titled "Implementing Internationalization," and yet provides almost no details, and is essentially unusable by itself. At the very least, it should mention that later sections 3.2.1 and 15.3 provide a lot more information. Furthermore, internationalization was introduced far too early in the book, and greatly complicates the process. Instead, the authors should have created a simple application using only English for the user interface, and introduce internationalization later, after fully explaining the basics of turning Java code into JavaScript functionality.

Part I of the book is the weakest of all of them, which may, sadly, turn off readers who would otherwise get to the better material later. The authors are clearly enthusiastic about the topics at hand, and the number of moving parts associated with Java/JavaScript/GWT development is certainly not trivial. Nonetheless, those initial chapters would greatly benefit from a rewrite; this would make the material more comprehensible and easier to follow, step-by-step.

We can mention some specific flaws: A book like this that is introducing a new technology, must take care to not leave the unwarned reader wondering if they have been left behind in the steps. People reading some of the earlier material may conclude that those steps have already been assumed by the authors, and will not be covered. The authors do not mention how to obtain and install GWT until page 30; that should be right up front. The authors do not appear to mention which version of GWT they used for the book. (I chose 1.3, not 1.4RC, available as of this writing). Any reader trying to follow along and implement their example application (the Dashboard) will probably find several hurdles. First of all, make sure that you have version 1.4 of GWT installed, and not 1.3.3, which does not include some of the panels and widgets used in their sample code.

In Chapter 1, they modify a "Hello world" application to create another application that shows a tic-tac-toe board that has clickable squares, but does not play the game. Chapter 2 describes this as "a fully functioning Tic-Tac-Toe application," which is like claiming a program works because it compiles. Also in Chapter 2, their discussion of development alternatives is slowed down by repetition of the same information. The sample code in the book has minor inconsistencies. For example, naming a password String "oldPass" in one method, then "old" in another, related method. There are other instances, but these give one an idea of some of the inconsistencies.

The coverage of topics is generally quite thorough, though at times verbose and redundant — particularly in Chapter 2, though it is certainly not limited to that chapter. The second and third paragraphs in Chapter 3, for instance, continue the repetitious style which is found in many places throughout the book, and likely has made it longer than necessary. In Chapter 4, the first two pages explain what widgets are, several times, and conclude with a picture of a button — as if any reader who has made it that far into the book doesn't know what a button is. The book could certainly use some trimming.

The downloadable source code is not complete. For starters, it is missing the code from Chapters 1 and 2, though admittedly none of that is too long. The code provided for Chapter 4 is just a portion of what is displayed in the book. Moreover, the directory paths in the sample code archive files, are not consistently named, and some may even be incorrect. For example, the code for Chapter 5 has a folder named "Dashboard — Chapter 4." That sort of thing does not instill confidence in the typical reader. The authors should revisit the sample code — making it complete and consistently named.

The publisher's page for the book does not appear to have a link for errata; perhaps none have been reported yet. Here are some: On page 75, in Table 3.1, in the left-hand column, "gwt-onLoadErrorFn" should instead read ""gwt:onLoadErrorFn." On page 77, in the second paragraph, the file name extension should be all lowercase, not all uppercase. On page 78, in Listing 3.6, the String parameter in the first label.setText() call should be delimited with straight quotes, not curly quotes. (Microsoft Word strikes again?!) On page 81, in the third paragraph, "comply to" should read "comply with." On pages 87 and 88, the -whitelist and -blacklist option values each contain an extraneous space before the "^." There are undoubtedly more such errata throughout the book, and can be corrected in the next edition; but these are enough to at least get an errata file started. Fortunately, none of them would lead an alert reader astray.

Even though the book could use significant reorganization and streamlining in the next edition, GWT in Action is packed with practical information on a wide range of GWT topics.

Michael J. Ross is a Web developer, freelance writer, and the editor of PristinePlanet.com's free newsletter.


You can purchase GWT in Action from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

216 comments

Sorry! There are no comments related to the filter you selected.

FAG in Action (0, Offtopic)

heauxmeaux (869966) | about 7 years ago | (#20402311)

A gay man, some lube and a Mac - is there anything more natural?

Wow (1, Insightful)

thatskinnyguy (1129515) | about 7 years ago | (#20402343)

That's a lot of reading. Can someone sum it up in 5 words or less for us lazy people? Thanks in advance.

Re:Wow (5, Funny)

Drew McKinney (1075313) | about 7 years ago | (#20402449)

That's a lot of reading. Can someone sum it up in 5 words or less for us lazy people? Thanks in advance.
Comprehensive. Disjointed. Overwhelming. Broken code.

Re:Wow (0, Troll)

fimbulvetr (598306) | about 7 years ago | (#20404925)

"Java" would have sufficed.

Re:Wow (3, Interesting)

cromar (1103585) | about 7 years ago | (#20402467)

He seems to be saying that overall it's a good book :D

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!

Re:Wow (3, Funny)

hansamurai (907719) | about 7 years ago | (#20402481)

From actually having tried out GWT, here's my five (and a half) words of advice:

Don't Use Google Web Toolkit.

Worse than Wicket? (3, Interesting)

kisrael (134664) | about 7 years ago | (#20402741)

Yeah?

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.

Re:Worse than Wicket? (1)

D-Cypell (446534) | about 7 years ago | (#20402837)

Its funny but I happen to think that Wicket [apache.org] is one of the better web frameworks available in the Java world today. Having used GWT I was really put off by the Javascript as 'bytecode' approach. Different strokes for different folks I guess.

Re:Worse than Wicket? (3, Insightful)

kisrael (134664) | about 7 years ago | (#20402905)

I just don't see what Wicket - or possibly any web framework - buys you.

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.

Re:Worse than Wicket? (0)

Anonymous Coward | about 7 years ago | (#20402963)

I just don't see what Wicket - or possibly any web framework - buys you.

Because I'm in Soviet Russia you insensitive clod!

Re:Worse than Wicket? (2, Interesting)

nuzak (959558) | about 7 years ago | (#20404309)

Wicket's an example of a minimalist concept that refused to grow beyond it in order to satisfy some ideology of "purity". Refusing to support even a moral equivalent of taglibs is an example. Tapestry has always struck me as far more pragmatic, and Tapestry5 looks downright amazing. Seam with Facelets strikes me as an awesome solution, though you're dealing with an insanely complex stack (JSF) under the surface, and wherever JSF is inadequate and Seam doesn't cover for it, you're forced into workarounds that may have you ditching Java for your project altogether.

I'm an example of the last case -- a java burnout. We never needed scalability (internal apps with maybe 50 total users), so I'm back to cobbling together perl and python and even php now. Ironically, the need to glue these apps together has led to adopting more enterprisey stuff like SOAP and ESB's, but in a very ala-carte way. Useful enterprise apps remain grown, not engineered.

Re:Worse than Wicket? (1, Interesting)

Anonymous Coward | about 7 years ago | (#20404751)

but often I end up having to put placeholder HTML in the page, and the set visibility = null.
If you're doing anything reasonably complex, there's really no way around that in Wicket.

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.
This pissed me off as well.

One of the parts of Wicket that annoyed me the most, was that if you needed reasonable URLs it offered very little abstraction over plain old servlets. The default URLs (ie. http://example.com/?wicket-id=?30kdjf309fj20fj30f8 4fj4 [example.com] ) really aren't acceptable on public facing websites.... Many would argue that they aren't even acceptable on internal websites used within a single organization. Especially, when you link to that URL and it proceeds to generate session timeouts. To fix the ugly URLs, you have to use BookmarkablePageLink for practically every link in your application, parse the URL arguments for every associated page, and use a sufficient URL coding strategy. Dealing with the session timeouts requires even more boilerplate that apparently most Wicket developers don't even bother with. The wicket examples that are provided by the core Wicket team still suffer from ridiculous URLs and regular session timeouts. I won't even go into how these problems get worse once you start using complicated components and Ajax....

How all this nonsense makes things easier is anyones guess. It's easier and cleaner to write a small abstraction over the servlet API and disregard the framework altogether.

Although I don't really like Wicket, or any Java web framework for that matter, I do think well thought out web frameworks can increase productivity and result in cleaner code when used properly. I think Django, Rails and Seaside are reasonably good examples of this.

Re:Worse than Wicket? (3, Informative)

chillenious (1149451) | about 7 years ago | (#20404821)

I just don't see what Wicket - or possibly any web framework - buys you. Maybe especially core Wicket, which isn't trying to do much but wrap HTML bits as objects. What really is the benefit of that?
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.

but often I end up having to put placeholder HTML in the page, and the set visibility = null.
use <wicket:enclosure> an you don't have to use extra placeholders.

And the Ajax support is so-so.
What's wrong with it? It's entirely optional.

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.
If pages are not session-relative, design them to be bookmarkable. All you need to do is put a default constructor or a page parameters constructor in them. With Wicket, you'll have to do a bit of planning for bookmark-ability. But why is that bad? It is secure by default. In contrast with most application frameworks and the REST approach that let you leak internal things like PK's etc by default, so that you'll have to secure your site as a separate effort. Creating a site in the model 2 two way with Wicket, completely stateless, isn't very hard either. Just make pages for every function (like you'd do with actions for model 2 frameworks) and use page parameters to pass your 'state' around.

Re:Worse than Wicket? (4, Insightful)

eddy the lip (20794) | about 7 years ago | (#20403559)

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.

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.

Re:Worse than Wicket? (2, Interesting)

kisrael (134664) | about 7 years ago | (#20403883)

Yeah.

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 counter argument comes from people who are heavily OO in their outlook. (more specifically, I think a gap tends emerge between people who cut their teeth on simple CGI-wrapping things, and got used to using a HashMap mentality for most client/server interaction, and people who cut their teeth on apps and applets, for whom the gap between Java code and what's physically displayed onscreen seems weird and in need of being abstracted away.) Anyway, these folks say that, look, the organization I want is OO, writing this kind of Object->screen element->response mapping ls a repetitive task, so I'm willing to buy into someone else's approach to do that work. That's where something like Wicket comes in.

My recent semi-revelation for this kind of tool-kit was this: "text" is amazing. It has been the lifeblood of programming for decades, ever since we could get away from punched cards I guess, despite attempts at cutesy visual languages. It's just so powerful, concise, easy to manipulate, easy to automate that manipulation, and in its own way visual (hence the wars over the one true brace style etc) that it will be around for a long long time. But text is, by the way we use it, rather procedural, and while you can do OO in it, that's a new level. But sacrificing the ability to adjust HTML and CSS and Javascript in TEXT on the alter of Objects just seems like too big of a sacrifice to me.

Of course, taking an anti-OO stance is a heresy (see http://geocities.com/tablizer/oopbad.htm [geocities.com] ) and you have to be careful so you don't seem like a crazy nut job who hasn't worked on large scale projects. But my latest take on it is this: "People and Programs are both best defined by what they DO, not what they ARE".

Another way of looking at it: in Java, when stuff goes wrong, what's your stack trace like? There's always that boilerplate JVM/Server engine at the bottom, but if the core of what's at the top ain't your code, your debugging is going to be a lot harder, because your mistake is in how you set up the other guy's objects to do the work, not you doing the work yourself. (Assuming the other guy's stuff is solid.)

Re:Worse than Wicket? (3, Insightful)

joshv (13017) | about 7 years ago | (#20404073)

Sure, using other people's code makes it harder to debug. And some things are just plain out of your control. Over the course of my career I've spent man-months troubleshooting and configuring 3rd party frameworks. I don't care, because I would have spent man-years writing them myself.

Re:Worse than Wicket? (1)

kisrael (134664) | about 7 years ago | (#20404255)

The years vs months comparison... I'm not sure I buy it.
Especially because usually you're just using a subset of the functionality, but to do it right, have to "pay" for (in terms of learning complexity) much more than that.

That's one reason I love APIs to the heavy lifting, but having a core of the Lowest Common Denominator of control code. For Java, this was Servlet/JSP pairs.

Re:Worse than Wicket? (1)

eddy the lip (20794) | about 7 years ago | (#20404919)

Here's a funny thing - I go through the same questions, wondering if I'm holding on to old biases that have gone past their best-before date. Every couple years I'll take a look around to see if I'm missing something, and invariably come to the conclusion that things Aren't Quite There Yet. Then I'll go refactor some of my own light-weight libraries and move on. Which makes me wonder how subject I am to NIH syndrome. But I get things done.

The punch line is that I did cut my teeth on CGI (perl 4) and a hash map for dispatching requests, and now I'm almost completely OO. I don't think it's the only way to do things, but I'm more comfortable with it. I certainly like the freedom to drop into procedural or functional when I think it fits better, but my bias is definitely for objects. I try not to be a zealot about it. That just doesn't have any place in a field with pretty well defined parameters. I like to leave that for the theologians.

Of course, after committing many of my own sins of over (or just poor) engineering, I have a very low tolerance for it in third party stuff. I was recently working in something that had six levels of inheritance put together by someone who obviously didn't understand composition. I didn't sleep well a few nights.

Things like HTML generating classes just for the sake of staying in a comfortable paradigm boggle my mind. Like you said, ain't nuthin' wrong with text. I'd rather learn something new than shoehorn it into The One True Way (whichever way that happens to be.) I find there's a lot more flexibility and power in letting each technology be itself, and adapting to it, instead.

I don't imagine we've seen the last of this kind of thing by a long shot. I'm convinced, though, that sticking to fundamentals is what's helped me keep up on new technologies, and keep myself relevant. If everyone else is on a bandwagon, it just means it's quieter where I am.

(Liked the site linked in your sig, by the way. Good stuff.)

Re:Worse than Wicket? (1)

pebs (654334) | about 7 years ago | (#20404971)

but if the core of what's at the top ain't your code, your debugging is going to be a lot harder, because your mistake is in how you set up the other guy's objects to do the work, not you doing the work yourself. (Assuming the other guy's stuff is solid.)

That's why I like to have the source code for my 3rd party libraries that I use. That way I can learn the other guy's code. I can link the code in with my IDE so that when a problem occurs I can trace through the code in those 3rd party libs.

With Java, I don't use any 3rd party libraries that aren't open source. And some of the key libraries I use (though not all), I am familiar with the source code and how it works. If I am not familiar, I can always become familiar with it when a problem occurs. It's generally good to pick 3rd party projects based on how clean their source code is (among other things), so when you do have to go dig in, its not as difficult.

I think this situation can give you an advantage over writing your own.

Re:Worse than Wicket? (2, Insightful)

poot_rootbeer (188613) | about 7 years ago | (#20403971)

I'm also a big proponent of writing to the language's strengths.

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 natively developed code in each area.

Re:Worse than Wicket? (1)

eddy the lip (20794) | about 7 years ago | (#20405007)

Oh, yeah, that's pretty much what I was trying to get at (unless I misunderstand.) HTML and CSS and javascript and whatever server-side language you're using are all different beasts, and I personally prefer to meet each on their own terms. It might take a bigger learning investment, but the payoff is understanding everything that's going on, and being able to manipulate it at a fine grained level. And you can take advantage of the strengths inherent in each, while occasionally offsetting their weaknesses with one of the other tools in your kit.

I can see the appeal of staying in your own paradigm, and maybe there's even places where it's the right way to go. But I'm pretty sure that knowing each individually gives me better results faster. Might not be true for all.

Re:Worse than Wicket? (2, Informative)

chillenious (1149451) | about 7 years ago | (#20404645)

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.

Sorry to hear it doesn't work for you. A little OO-obsessed though? Because the framework takes a stance to actually try to provide a real OO programming model where other frameworks simply don't?

I agree that there is a lot to say for simplicity. Especially if your problem is simple. However, my experience is that model 2 just doesn't cut it. I shudder to think back to the horrible instances I've seen of code duplication you get when you can't properly reuse widgets and the tons of hacks I've seen to get around the statelessness of web applications. And then scripting in templates, making them hard to sync with changed designs/ hire a designer to work on them and simply hard to track where logic is put in the first place. I don't know about you, but I never had much fun refactoring JSP and Velocity templates.

Wicket focusses on OO as that facilitates reuse and lets you better cope with complexity. Wicket enforces clean templates so that you won't get yourself into maintenance hell. But it may or may not work for you. It does for me and many others [eweek.com] , but so many people, so many tastes. In the end it is a trade off that can be annoying in the short term, but should save you trouble in the long run.

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.

If what you are trying to do fits the request/ response paradigm, that's fine. I for one, prefer to reason about screens that have panels, forms, fields, tabs and buttons on them, and I don't want to rewrite half of my pages just because I decide to put a wizard in a tab, or move a pageable list to another page or whatever.

If you can use Ajax all the way, a simpler approach like using HTML + JS and maybe DWR should work fine, though a library like GWT should help you avoid all those nasty browser issues etc, AND let you write strongly typed (maintainable) code.

Re:Worse than Wicket? (1)

CryBaby (679336) | about 7 years ago | (#20405939)

I felt the same way about GWT -- it's just too much of a black box for my taste. Having said that, it's probably a good idea to reevaluate it now that I use a lot more Ajax and am far more comfortable with JavaScript than I was a year or so ago.

Regarding Wicket, however, I couldn't disagree more. I think Wicket offers by far the best balance of productivity and maintainability compared to any action or component-based Java web framework out there. There are, however, a couple of caveats.

1) Wicket's sweet spot is complex applications (esp. with a lot of Ajax) that *happen* to be served over http. iow, it's probably not a great fit for simple, high-volume public sites (although Wicket devs may disagree by pointing out some of the new features in 1.3 that offer excellent support for stateless pages).

2) You won't like Wicket if any time you see a decorator or composite pattern you either a) don't recognize it or b) refer to it as an "over-engineered" solution. Of course, if that's the case, you probably shouldn't be using Java in the first place.

In general, if you enjoy programming in Java and you like the idea of writing web UI code in more or less the same way you write domain code, you'll probably prefer Wicket to just about any other framework. To back that statement up a bit, I'll mention that *all* of the programmers on my team now write Wicket UI code as well as middle tier code even though some of them have never written a web app before in their life. That was not the case when we used Tapestry because, as nice as that framework is, you still have to think in terms of the request/response cycle to do anything complex and you have to learn a lot about it by rote, as opposed to Wicket where you can learn most of the framework simply by exploring it from within your IDE.

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.

Sure, the "purity" of GWT's approach is undeniably appealing, but I'm reluctant to give up the simplicity of HTML templates, regular Java code that runs on a real JVM, and regular, non-generated JavaScript. As far as being irritated by having to keep your ultra-simple Wicket HTML templates in sync with your straightforward, plain Java code, I'll just say that it's much better than having to keep templates with embedded logic in sync with an abstract, runtime enhanced class along with a bunch of XML configuration. So, coming from Tapestry 4, code/template synchronization in Wicket has been a complete non-issue for me.

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.

I'm not sure if you're advocating the abandonment of all web frameworks or if you just don't see the advantage of a component-based framework as opposed to an action-based framework. The problem with a "bare-bones, no framework" approach is that it usually translates into a custom framework for each application and/or a big mess of copy-and-paste spaghetti code that can only be deciphered by the original author.

The advantage of component-based frameworks is that components naturally correspond to objects whereas action-based frameworks lend themselves to a more procedural approach. I also think that web pages themselves make more sense when viewed as a collection of potentially reusable components (even when I wrote PHP apps, I wrote them in a component-oriented style), but I guess that's a matter of opinion.

Regarding that last statement about "writing HTML in HTML and writing Javascript in Javascript", I would just add "writing Java in Java" and point out that that's exactly why I prefer Wicket over something like GWT or Tapestry. When I'm writing Java, whether it's business or presentation logic, I want it to be "just Java". I want to subclass and compose objects in the normal way without having to understand lots of magical or abstract behavior that the framework is going to invisibly add to my code. When I'm writing HTML, I don't want to mix in logic via JSP tags or pseudo-components like @If -- I'd rather concentrate on layout, CSS, and other purely visual issues. Same with JavaScript -- when I need more JS behavior than what's already built into Wicket (which is essentially just Ajax - think tightly integrated DWR) I can write plain JavaScript using whatever libraries or JS frameworks I prefer. Wicket *allows* you to wrap your JS in Java classes if you want to, but you can also choose to write your JavaScript completely outside of the framework and/or use Ajax callback hooks to push more behavior into pure JS. In my experience, there are good use cases for both approaches.

I don't mean to suggest that Wicket is the ideal solution for every web app. I just wanted to relate a very different experience than you've had and one that I think is more representative of developers who use Wicket on a regular basis. To sum up, I think Wicket lies somewhere between the 100% JavaScript approach of GWT and the "old-fashoined" MVC action-based frameworks. For me, my team, and our applications that's turned out to be the right mix.

Re:Wow (3, Informative)

doofusclam (528746) | about 7 years ago | (#20403177)

Well, i've avoided writing web stuff for my whole career but when I got lumbered with a project at work I used GWT.

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 you need to write anything with a rich web gui and a large amount of interaction between this and a backend. I can use Eclipse to single step through my Java code, with breakpoints and all that stuff. GWT also takes all the browser specific hassles away, for example with the differing rich text area implementations used by all the browsers. Without these niceties i'd have given up on web development before i'd even started.

Oh and the google group for GWT is great - i've had problems answered within ten minutes. The Google team are very visible and are obviously proud of their product. Rightly so, too.

Re:Wow (1)

matto11 (1133407) | about 7 years ago | (#20403263)

if you can't see the benefit of using GWT for certain applications then you don't know what you are doing. why spend valuable time debugging javascript to work across all browsers when you can use GWT and spend that time building more features. use the right tool for the right job.

Re:Wow (1)

trondotcom (1148541) | about 7 years ago | (#20402903)

Screenshots would be helpful as well :-)

Re:Wow (0)

Anonymous Coward | about 7 years ago | (#20403085)

Can someone sum it up in 5 words or less for us lazy people?

Don't buy this book, sir.

Re:Wow (2, Interesting)

Angostura (703910) | about 7 years ago | (#20403483)

Here's what happens when I take the review and run it through Microsoft Word's 'Autosummarize' Tool, set to the most violent setting: "100 words or less":

The publisher offers two freely downloadable chapters, "Creating the Default Application" and "Communicating with GWT-RPC," in PDF format. Unfortunately, the book has many weaknesses. The authors do not appear to mention which version of GWT they used for the book. The sample code in the book has minor inconsistencies. For example, the code for Chapter 5 has a folder named "Dashboard -- Chapter 4."
... yup, that seems to cover most of it.

Re:Wow (1)

thatskinnyguy (1129515) | about 7 years ago | (#20403633)

I was unaware of such a tool. o_O I'll have to use that in the future.

Re:Wow (1)

PoliTech (998983) | about 7 years ago | (#20403869)

At first I thought this was going to be an article about the Global War on Terror.

Google Web Toolkit

Who'd a thunk?

The more I learn about JavaScript... (4, Insightful)

SanityInAnarchy (655584) | about 7 years ago | (#20402385)

The more I learn about JavaScript, the more I like it as a language.

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:The more I learn about JavaScript... (0)

Anonymous Coward | about 7 years ago | (#20402535)

They did it was called Netscape Enterprise Server. SSJS died a horrible death a long time ago thank god!

Re:The more I learn about JavaScript... (1)

SanityInAnarchy (655584) | about 7 years ago | (#20402671)

Care to elaborate on what sucked about it?

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:The more I learn about JavaScript... (0)

Anonymous Coward | about 7 years ago | (#20403445)

It ran on a proprietary webserver.

Re:The more I learn about JavaScript... (0)

misleb (129952) | about 7 years ago | (#20403629)

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.


What more do you expect to get from JavaScript? The simple fact is that it lacks some very basic modern OO language constructs such as interfaces, abstract classes, and threads. And by the time you add those in, you'll just have reinvented Java. So what would be the point?

-matthew

Re:The more I learn about JavaScript... (2, Informative)

Gospodin (547743) | about 7 years ago | (#20404219)

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:The more I learn about JavaScript... (1)

misleb (129952) | about 7 years ago | (#20404761)

Ok, that stuff would be great for better client side programming, but I don't see any point in trying to turn JavaScript into a full server side language. Where there are already languages such as Python or Ruby that do what you want.

-matthew

Re:The more I learn about JavaScript... (1)

Gospodin (547743) | about 7 years ago | (#20405117)

I agree, Javascript is fine as a client side language only. My point wasn't that we need to turn it into a server side language (although this is already being done [wikipedia.org] in a proof-of-concepty way, so it's sort of too late to make this point), but rather that improving Javascript isn't going to magically turn it into Java.

Re:The more I learn about JavaScript... (1)

fredrik70 (161208) | about 7 years ago | (#20405925)

already done actually, you can use jscript as your server side language on on IIS

Re:The more I learn about JavaScript... (1)

Octopus (19153) | about 7 years ago | (#20402537)

JavaScript generated from Java code
EW. LIKE RECONSTITUTED BOOGERS.

Re:The more I learn about JavaScript... (0)

Anonymous Coward | about 7 years ago | (#20402619)

I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.

Someone did build a webserver platform around JavaScript.
It was a product from Borland called Intrabuilder.

Circa 1997:

Borland, with IntraBuilder, is one of the first vendors to release a complete client/server application development environment for intranets. The product is full-featured, including a wizard-filled IDE that supports the JavaScript language for both server- and client-side scripting. A JavaScript server engine for run-time application support (IntraServer) uses the Borland Database Engine for database connectivity during both design and run time.

Re:The more I learn about JavaScript... (2, Funny)

jmyers (208878) | about 7 years ago | (#20402719)

"I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter."

duh... IIS and asp
@ Language=JavaScript

Re:The more I learn about JavaScript... (2, Interesting)

AKAImBatman (238306) | about 7 years ago | (#20402735)

The problem with JavaScript is that it's horribly slow to execute.

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. Which means that Javascript doesn't have to be slow. ;)

I figure you could create a JSHttpServlet object and map a file of your own extension (it can be *.js if you want it to be) to that servlet. The servlet then creates a JS environment that maps HttpRequest and HttpResponse as global variables. You can even map HttpSession and a PrintWriter output stream if you want. (That gets pretty close to JSP territory. ;-)) Load the script at init() time, and execute it when called.

the point of GWT (2, Informative)

davido42 (956948) | about 7 years ago | (#20402739)

"I'm not really sure I see the point of GWT"

(Disclaimer: I evaluated GWT and decided that it was cool for larger web apps, but for a smallish website I think it is overkill. So.. I'm not a GWT user, sorry.)

When I was developing my site (which you will visit now [bitworksmusic.com] and purchase lots of album downloads), I had to deal with the fact that browsers do not implement things consistently. In particular, IE seems to do things differently than every other browser. The idea of GWT is to do all the hard browser bug workarounds and compatibility work for you, so that you write some code in Java and poof! Your web app will look and behave the same across all browsers everywhere. Among the downsides, you have to learn GWT of course, and your resulting code is almost guaranteed to be less efficient and slower to load than if you just code directly in Javascript/HTML/etc.

In the end, I ditched GWT in favor of simplicity, dealing with IE issues as they arose (my native development platform is Firefox). Then again, my site has very limited functionality. YMMV.

david

Re:the point of GWT (1, Interesting)

Anonymous Coward | about 7 years ago | (#20405157)

David --

        Maybe take another look at it. The learning curve is pretty minimal if you a) know java and b) have exposure to any other windowing toolkit, ala tcl/tk, swt, swing, etc. Couple hours tops, honestly. Secondly, the obfustication tech. makes the resulting javascript much smaller than hand-coded javascript, much the same way that a C compiler can write more efficient assembly than you or I could. Finally, I actually found the opposite about app size when I have used it with my customers -- for small apps it is perfect because you can produce a really slick interface very quickly. If you app has a lot of distinct functionality, and maybe parts of it aren't yet ported to GWT (for example) GWT actually gets in your way.

Re:The more I learn about JavaScript... (1)

RManning (544016) | about 7 years ago | (#20402769)

I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.

Not to date myself, but I remember using Netscape LiveWire. It sucked. I was so glad to move to Perl/CGI and then even happier when we moved to J2EE.

Anyway, there's been a number of server side JavaScript implementations [wikipedia.org] .

Re:The more I learn about JavaScript... (2, Interesting)

fireboy1919 (257783) | about 7 years ago | (#20402819)

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 a lot of the modern pure-javascript libraries (prototype especially is known for breaking existing javascript libraries, for example).

Re:The more I learn about JavaScript... (1)

Bluesman (104513) | about 7 years ago | (#20403553)

"I like Javascript, but it has the same problem as PHP: no namespaces."

You can work around this by writing object-oriented Javascript, like this:

function myNamespace()
{
 
}
 
myNamespace.prototype =
{
  var1: null,
  var2: null,
 
  func1: function(){alert('yay');},
};
 
myObject = new myNamespace();
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 variable or function, because of the brain-dead way "this" works in Javascript.

But the vast majority of namespace problems in Javascript can be solved with this approach.

Re:The more I learn about JavaScript... (1)

larry bagina (561269) | about 7 years ago | (#20405169)

function.call and function.apply let you tweak this. Wrap it in an anonymous function and your problem is solved.

Re:The more I learn about JavaScript... (1)

Bluesman (104513) | about 7 years ago | (#20405305)

Thank you, that's a big help. This is going to simplify a lot of things for me.

Re:The more I learn about JavaScript... (1)

majorbugger (1149409) | about 7 years ago | (#20402863)

First, Javascript is a horrendous language. It is full of unexpected quirks, and compared to other dynamic languages such as Python or Ruby it is hell to work with. That's why frameworks like Prototype or jQuery emerged. The power of GWT and similar frameworks is that they provide ready to use components which render similarly across all browsers, making it feasible to prepare a fully functional and nicely lookung web UI in a matter of minutes.

Re:The more I learn about JavaScript... (1)

Abcd1234 (188840) | about 7 years ago | (#20403923)

First, Javascript is a horrendous language. It is full of unexpected quirks, and compared to other dynamic languages such as Python or Ruby it is hell to work with.

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 former).

Re:The more I learn about JavaScript... (1)

larry bagina (561269) | about 7 years ago | (#20405259)

Most javascript complaints are along the lines of:

  • overlaoded + (addition, string concatenation) is confusing (aka you're an idiot and shouldn't be programming)
  • IE/DOM/Event handling quirks (not an issue of the language itself).
  • Numbers are always floating point (valid).
Personally, I consider javascript to be a better designed language than php.

Re:The more I learn about JavaScript... (1)

ZeroConcept (196261) | about 7 years ago | (#20402877)

- In JavaScript you find all errors at runtime, in Java you can catch many at compile time.
- 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:The more I learn about JavaScript... (1)

anomalous cohort (704239) | about 7 years ago | (#20404179)

In JavaScript you find all errors at runtime

This may be more of a DOM issue than a javascript issue but I find a lot of situations where you don't get an error at all. It just doesn't do what you instructed. Sometimes execution just halts in that method and sometimes it doesn't.

Also, don't get me started on javascript's this variable which is a complete joke.

Re:The more I learn about JavaScript... (1)

multipartmixed (163409) | about 7 years ago | (#20402881)

> I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.

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 slower or faster than any similar functional or imperitave language I can think of (Pascal, Object-Oriented Turing, Miranda, LISP) for comparable jobs. Although LISP probably kicks its ass if your job is heavily recursive.

> But then, you still have that problem, even if it's JavaScript generated from Java code.

I don't know what you're talking about here. JavaScript is completely unreladed to Java.

That said, there is a JavaScript interpreter written in Java called Rhino. But if you were looking for speed, I would certainly look at a C implementation (like spidermonkey or NJS) first.

Re:The more I learn about JavaScript... (0)

Anonymous Coward | about 7 years ago | (#20402995)

> But then, you still have that problem, even if it's JavaScript generated from Java code.

I don't know what you're talking about here. JavaScript is completely unreladed to Java.

Do you even know what this article is about? Google Web Toolkit works by compiling Java code into Javascript and HTML.

http://code.google.com/webtoolkit/overview.html [google.com] :

What is Google Web Toolkit?
...

Here's the GWT development cycle:

              1. Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
              2. Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
              3. Confirm that your application works in each browser that you want to support, which usually takes no additional work.

Re:The more I learn about JavaScript... (1)

AKAImBatman (238306) | about 7 years ago | (#20403113)

That said, there is a JavaScript interpreter written in Java called Rhino. But if you were looking for speed, I would certainly look at a C implementation (like spidermonkey or NJS) first.

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:The more I learn about JavaScript... (1)

AKAImBatman (238306) | about 7 years ago | (#20403161)

Sorry, that should read "Spidermonkey has its bytecode own interpreter." Which is slow. Very slow.

Re:The more I learn about JavaScript... (1)

multipartmixed (163409) | about 7 years ago | (#20403651)

> Rhino compiles down to Java bytecode which is then JITed by the JVM. If you want performance, use Rhino

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 concern myself, first and foremost, with correctness and ease-of-coding. Spidermonkey's guts are a little heady but not really all that bad. Design-type comments would be nice, though. ;)

I may change my tune later this month, however, when I try to write multithreaded JavaScript programs.

Have you ever seen C libs embedded in Rhino, maybe built with gcj? I'm no Java guy but I have written enough JNI crap that I could probably cobble together an interface between Rhino and my backend C libs.

Re:The more I learn about JavaScript... (1)

AKAImBatman (238306) | about 7 years ago | (#20404557)

Have you ever seen C libs embedded in Rhino, maybe built with gcj?

I'm not really sure what you're asking here, so I'll just give a generic answer. Rhino compiles scripts to Java classes based on Rhino's hashtable-like data-model classes. Java classes can be passed to Rhino either by extending/implementing the data-model classes [mozilla.org] , or by using the Livescript-like Javascript APIs [mozilla.org] .

Native libraries are incompatible with Java save for when they are mapped to a class through JNI. So if you want to link in a library, make a JNI wrapper. Before you do that, though, make sure there isn't a Java library that already does what you want. There are very few things above the level of a system driver that Java does not have a cross-platform library for.

Re:The more I learn about JavaScript... (1)

larry bagina (561269) | about 7 years ago | (#20405339)

Spidermonkey's guts are a little heady but not really all that bad. Design-type comments would be nice, though. ;)

I think the spidermonkey code is a mess... Try taking a look at kjs/WebKit JavaScriptCore [webkit.org] . It's much cleaner and (imo) easier to add new native functions/classes.

You seem quite confused. (1, Informative)

Anonymous Coward | about 7 years ago | (#20404017)

Languages don't have performance characteristics. They can't be faster or slower than each other. Only implimentations of languages are faster or slower. For instance, the mozilla implimentation of javascript is very slow, rhino is not as slow, but still slower than the official implimentation of python, and most other reasonable language implimentations. I am not aware of any javascript implimentation that comes even close to the performance achieved by high performance implimentations of pascal, miranda, scheme, or common lisp, much less languages with very fast implimentations like ocaml, C++, C, D, etc.

Re:The more I learn about JavaScript... (1)

Bluesman (104513) | about 7 years ago | (#20403401)

A couple of days ago I was thinking about what would an ideal scripting language would look like.

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 was thinking about how much work it would take to implement something like that, and I realized that Javascript has just about every one of those features, although some are implemented in odd ways. The scoping rules are a bit strange, and the "this" operator is handled poorly, IMHO, but everything else is almost exactly what I'd want.

I think Javascript gets a bad rap because you have to worry about browser compatibility. 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.

And it's much more powerful than I used to think, before I started working on my now half-finished Javascript app [sourceforge.net] . (Shameless plug there.)

Its called pike. (1, Interesting)

Anonymous Coward | about 7 years ago | (#20403731)

"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."

You just described pike (although it has both static and dynamic typing).
http://pike.ida.liu.se/ [ida.liu.se]

Re:The more I learn about JavaScript... (1)

multipartmixed (163409) | about 7 years ago | (#20403863)

> I think Javascript gets a bad rap because you have to worry about browser compatibility.
> 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 REALLY don't like is the way it handles inheritance and class hierarchies. I think Smalltalk did a better job there.

I suppose constants and macros would be features worth adding, too... but then, some of the macros I have seen in C make me wish they had never been invented.

But the S-expression-like syntax in JavaScript (var a = {prop: value, prop2: value2}) totally rocks. As do the scoping rules, WITH THE EXCEPTION of it's idiot rule of "oh-its-not-initialized-so-lets-make-it-a-global". I would prefer an error.

Oh, and vian looks neat! Ever thought about writing something like dialog/xdialog/cdialog for the browser? You could use your same screen interface. I think that would be awesome.

Re:The more I learn about JavaScript... (1)

Bluesman (104513) | about 7 years ago | (#20404343)

I haven't considered doing xdialog in the browser, but it's a good idea. Vian came out of a desire for a web-based unix environment. The next step is a command shell, which can use the same editor/cursor class that vian uses, so it should be very easy to do.

I think the coolest thing potentially is being able to send the commands to a real unix server and then pipe the output back to the Javascript shell. Obviously this has potentially serious security implications, but with a secure setup could be extremely useful.

Re:The more I learn about JavaScript... (1)

Abcd1234 (188840) | about 7 years ago | (#20403865)

I realized that Javascript has just about every one of those features

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 programmer can be a little more lazy. But, IMHO, the benefits don't outweigh the risks.

Personally, I much prefer something like Smalltalk (no, not Ruby... Ruby is just a weak attempt to replicate Smalltalk, and they did a crappy job of it). And transforming Smalltalk into a scripting language would be pretty easy, I think...

Re:The more I learn about JavaScript... (1)

misleb (129952) | about 7 years ago | (#20403419)

I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point.


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.

I'm almost tempted to suggest that someone build a webserver platform around a JavaScript interpreter.


Don't give in to the temptation because it would make you look quite foolish.

-matthew

Re:The more I learn about JavaScript... (0)

Anonymous Coward | about 7 years ago | (#20405371)

JavaScript is most CERTAINLY not more powerful than Java.

Err, think again.

Where are the closures in Java? Anonymous functions?

Re:The more I learn about JavaScript... (1)

plams (744927) | about 7 years ago | (#20403441)

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:The more I learn about JavaScript... (0)

Anonymous Coward | about 7 years ago | (#20403657)

Let the Google Masturbation begain...

Re:The more I learn about JavaScript... (1)

skidv (656766) | about 7 years ago | (#20404211)

Do you think that the new
Java 7 Kernel will actually make javascript faster to execute? Sun claims that it will because it only loads the classes it needs. Care to comment?

Re:The more I learn about JavaScript... (1)

AKAImBatman (238306) | about 7 years ago | (#20404461)

Do you think that the new Java 7 Kernel will actually make javascript faster to execute?

I suppose it depends on whether the price of orange juice directly affects the outcome of soccer games played in the Miami Orange Bowl.

Re:The more I learn about JavaScript... (1)

mpcooke3 (306161) | about 7 years ago | (#20404401)

I'm not really sure I see the point of GWT

Millions of dollars and 5 years of Java IDE development by some of the best IDE developers in the world. Also the Hotspot JIT Compiler and class libraries.

There are many 'languages' that Java developers would probably prefer to use if they had had the same massive cross-industry investment as Java - like Ruby, Python or Smalltalk.

Matt

Re:The more I learn about JavaScript... (2, Informative)

ispeters (621097) | about 7 years ago | (#20404571)

The more I learn about JavaScript, the more I like it as a language.

I'm not really sure I see the point of GWT, given that JavaScript is actually a more powerful language at this point.

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. The resulting code is obfuscated, which reduces download time, and has all the dead code eliminated, which reduces download time. Also, for broken interpreters, like the one in IE, a smaller script executes faster, on top of downloading more quickly.

I guess what I'm saying is that GWT brings a compiler to Javascript and that has many benefits. For the GWT compiler, Java is to Javascript as C is to assembler in a C compiler. Generally speaking a C compiler produces better machine code than someone writing assembler by hand. The same is true for the GWT compiler--its output runs faster than a comparable programme hand-written in Javascript.

Ian

I Still don't know what GWT is (4, Informative)

chad_r (79875) | about 7 years ago | (#20402759)

The review had everything except a brief summary of what GWT actually is. I had never heard of it until now. From http://code.google.com/webtoolkit/overview.html [google.com] :

What is Google Web Toolkit?

Google Web Toolkit (GWT) is an open source Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler translates your Java application to browser-compliant JavaScript and HTML.

Here's the GWT development cycle:

  1. Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
  2. Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
  3. Confirm that your application works in each browser that you want to support, which usually takes no additional work.

It's so simple, but... (1, Troll)

C10H14N2 (640033) | about 7 years ago | (#20403967)

Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server. ...provided you have some other server capable of running the necessary services to put the A&X in AJAX, which raises the rather obvious question: what does this simplify again? So it's JSF-lite, except I have to roll my own SOAP services for everything?

Hell. No.

Re:It's so simple, but... (3, Informative)

Eponymous Bastard (1143615) | about 7 years ago | (#20404745)

I looked into GWT a month or two ago. From what I understood, you can write both client and server code in Java and then GWT compiles the client to Javascript and the server to a servlet.

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 at all (that's the reason why we didn't pick it up for our UI, our company does business logic in C#).

Since it is also a widget library you should be able to have complex widgets with multiple DOM elements and access them as a unit. You could write your own javascripts objects to access the DOM, but then it's basically a GUI library.

As far as I can tell, the whole point is to write both client and server with a single language and interface, which is very useful.

For example, in our case, the pages are generated with ASP.Net in C#. If we want to disable a button when the page is served we do buttonSubmit.Enabled=false; but if we want to reenable it without a postback, we have to add javascript code to find the DOM node for the button and then enable it. Imagine how messy it gets when you want to add a row to a datagrid. After a while you can't tell all the interactions in the GUI handling logic. I'd love to have something that allows me to write an event handler where I can just write "buttonSubmit.Enabled=true;" and let the compiler work out all the DOM walking code.

So you have three choices:
- Serve the full page (formatted in server side language) and then tweak it in javascript, relying on knowledge of the widget library's rendering.
- Serve a bare bones page and do all the GUI in Javascript, both initial and updates. Let the server handle business logic only. I see some posters have suggested moving the initial javascript rendering to the server.
- Serve a full page and let something like GWT convert the client side code from working with the same objects as the server to a working Javascript/DOM implementation. This is the approach GWT is taking.

Of course, I only looked at it for a couple hours, so someone will probably tell me all the ways I'm wrong.

Re:I Still don't know what GWT is (1)

jilles (20976) | about 7 years ago | (#20404229)

GWT is a development kit for developing AJAX applications, such as for example GMail. The concept consists of doing all the programming in Java (similar to how you would develop a Java desktop application) and cross compiling the client components to javascript + html. The advantage of this is that you don't have to think about html, javascript, browser-server communication and many other difficult browser issues that most other web developers waste most of their time on (instead of implementing functionality). GWT makes things like interacting with the browser history, back button and other difficult to do stuff dead easy. Basically the toolkit encapsulates all the javascript voodoo that you normally need to do to do this properly & cross browser. Just define all logic as Java code GWT generates the rest. Of course you can also go for a partial approach where you do part of the application using ordinary javascript and html and only do parts of the app in GWT. Basically this allows you to use as much or as little of GWT as you need.

The IDE part is integrated into eclipse and offers all the advanced development features that Java programmers are used to like incremental compilation, refactoring, auto-completion etc. To the developer, GWT looks like just another Java library that builds on all the idioms and patterns they know already. Of course you can debug your application as well either before or after compiling to javascript (i.e. set breakpoint in java code, launch browser to test and trigger the breakpoint, then inspect java code). Basically GWT fixes a lot of stuff that makes AJAX development suck so much: you work in a advanced IDE instead of a crappy text editor that doesn't have a clue about the semantics of what you type; you debug in one of the best debuggers around; browser compatibility issues are taken care off during compilation; you'll know if there's a type error because Java is statically typed; you can do unit testing; etc. In short, GWT is about bringing lots of good development practices from server side Java to browser client side. There's not that many tools around that do this to the extent that GWT does.

GWT is part of a growing set of web development related technology coming from Google. Other nice stuff is the Guice dependency injection serverside component framework for Java and the Gears offline web application component. Presumably, Google eats their own dogfood so the stuff is demonstrably scalable and quite capable as well. Also interesting to learn for the Java hating crowd on slashdot is that the world's largest internet company is a Java shop.

Beyond hope (5, Insightful)

k-zed (92087) | about 7 years ago | (#20402801)

The sentence "Server-side computer languages, such as Java, possess numerous advantages over their client-side counterparts - including more robust integrated development environments (IDEs)." is possibly the most retarded thing I have ever seen on Slashdot. Ever.

Come on, doesn't anybody read these?

Re:Beyond hope (1)

drdanny_orig (585847) | about 7 years ago | (#20403403)

I'm glad to see someone else thinks so too. I was beginning to think it was just me, or that I'd misread it.

Re:Beyond hope (4, Funny)

Bluesman (104513) | about 7 years ago | (#20403485)

Yeah, it's one of the dumbest things on the front page *today*, but ever? Let's not get carried away.

Just when you need mod points (1)

WarwickRyan (780794) | about 7 years ago | (#20403561)

Spot on, that's a really terrible summary. It's like a reverse summary really as there are few to no IDEs which come close to Visual Studio. Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants.

Re:Just when you need mod points (1)

owlstead (636356) | about 7 years ago | (#20404687)

"Even Eclipse, for all its niceness doesn't compare well. Which sucks, as I spend most of my development time working with Eclipse and its variants."

Funny, that, I am using both as well, and I feel the same thing. The other way around. VS is way behind Eclipse on some features, and a lot more on others. VS 2005 now has acceptable support for operations on the abstract syntax tree, but nothing really powerful. Of course, VS has more functionality integrated. But Eclipse has its vast number of functional plug-ins, and it does the parsing and code completion exceptionally well. Anyway, I've to spend most of my time on Eclipse - and that's the one that *I* like - so it seems I got the better deal.

Re:Beyond hope (1)

ceoyoyo (59147) | about 7 years ago | (#20404171)

I thought the same thing. Then I realized that the writer probably doesn't realize there's any other type of programming in the world other than web apps. Then it's just oversimplified and erroneous as opposed to retarded.

Re:Beyond hope (1)

owlstead (636356) | about 7 years ago | (#20404737)

I don't even think that the author does not know this. I think he was deliberately limiting his view to web applications. And to state that there is less support for languages supported in the browser (JavaScript, some Visual Basic) against those supported by the server (all of 'm really). Well, that's true, isn't it? So that would make the statement true, at least in the - supposedly - domain he was targeting. The initial reply of the grandparent was a bit over the top, in my opinion.

GWT *and* Java (4, Informative)

owlstead (636356) | about 7 years ago | (#20402861)

I would like to point out that the GWT can also be used from a Java server application. I'm using a package from Instantiations, WindowBuilder Pro, that can generate Swing (default Java GUI), SWT (IBM/Eclipse GUI) as well as the Google Window Toolkit. It's an application/plugin for creating graphical interfaces, so you would probably not get too exposed to the GWT itself. I haven't yet tried it out, but it might be a good idea to start of with a GUI builder and only delve deeper when needed. Of course, understanding what happens is great when you need to debug something, or if you are not happy with the functionality. But I would not start off by writing web-pages when trying out this relatively new technology.

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:GWT *and* Java (2, Informative)

owlstead (636356) | about 7 years ago | (#20402919)

I *knew* I was too tired to write this reply. Google Web Toolkit it is. Are there any slashdottees that would like to proofread my replies?

Nah, didn't think so :)

Why should GWT be on my radar screen? (2, Insightful)

scottsk (781208) | about 7 years ago | (#20403243)

Does the book - or somewhere else - address why GWT ought to be on my tla radar screen? Does it work with Apache, or just J2EE containers? Is it open source? I know I could find that out by, um, googling the information, but if the book is meant to evangelize the tla, I would have expected it to concentrate more on why I should use GWT and in which situations, not how to build a tic-tac-toe game.

Re:Why should GWT be on my radar screen? (1)

myatmpinis1234 (697897) | about 7 years ago | (#20404231)

It works with apache or any other web server. Basically it just generates javascript which can be hosted anywhere. As for the backend for RPC and server calls for data, I think that's just java based, but works with Tomcat. It's open source. I've done AJAX apps with hand-coded javascript, with toolkits like prototype and yahoo, and with GWT, and IMHO, GWT is pretty nice. Of course that sidesteps the question of whether web apps should be all AJAX'd up, but if you do take a strong look at GWT.

Re:Why should GWT be on my radar screen? (1)

nuzak (959558) | about 7 years ago | (#20404549)

> Does it work with Apache, or just J2EE containers?

It is a servlet, so it works with servlet containers. Like tomcat, resin, jetty, or those big ol JavaEE containers.

I'm not sure that tells you anything about why to use it though.

Oops. (1)

Limburgher (523006) | about 7 years ago | (#20403377)

I thought they said GWOT [wikipedia.org] . My bad.

I want to write desktop apps with JS/GWT/whatever (2, Interesting)

joe_n_bloe (244407) | about 7 years ago | (#20403393)

Some day, I'll be able to use a browser to write desktop apps without resorting to plugins or XUL or whatever. No, Google Gears doesn't do that.

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 (3, Informative)

plams (744927) | about 7 years ago | (#20404077)

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

Re:Very nice toolkit with some problems (1)

owlstead (636356) | about 7 years ago | (#20405741)

"GWT should offer a modified Mozilla with these restrictions removed, or even better, adopting Flash's excellent practise of looking for a crossdomain.xml file in the root of the target webserver (to see whether access is allowed or not)."

Distributing a specific web client to make it possible to view (some) web applications? That's not a good idea. Maybe for intranet use, but people won't go for a specific web client just to view some GWT based websites. The idea of a crossdomain.xml for use within JavaScript is an interesting one though.

"Also, developing on an AMD64 based Linux I discovered that the hosting environment just doesn't work running from a 64bit JVM."

Weird. Just for my information; I assume there are some native parts involved? I could not find any info on that.

Google DB/LDAP API? (1)

Doc Ruby (173196) | about 7 years ago | (#20404477)

Is there anywhere I can find out how to make the Google DB accessible to software that can query only an LDAP API?

Shameless plug - chess board diagram composer (3, Interesting)

SashaM (520334) | about 7 years ago | (#20404593)

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] .

Here's the point of GWT... (0)

Anonymous Coward | about 7 years ago | (#20405059)

If you have a team of Java developers who want to do pretty UI's and AJAXy things, GWT is a framework that lets you use Java to do that, IE: you use your strengths. It makes complete sense too -- essentially a web browser is treated like a compilation target. Kinda like writing C code that then builds assembly, rather than having to hand code the assembly yourself.

Anyone who has maintained a pile of Javascript for a few years understands the problem with hand coding javascript and/or the alternative javascript frameworks on the market right now -- lack of good IDEs/debuggers/tools like for other languages, among other problems. GWT counters this by allowing you to work with Java, and providing tools that integrate with your current toolset -- Intellij, Eclipse, NetBeans, etc.

Personally, I will be surprised if this model isn't the way we are all doing browser development within the next 5-10 years -- write your code in one high-level language and have it compiled into a given target (IE: turned into js, css, html, etc). This is exactly what has happened in the evolution of computing languages over the past 50 years, why shouldn't it happen in the web?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>