Tuesday, August 21st, 2007

Google Web Toolkit 1.4 RC 2: Almost there

Category: Google, GWT

The GWT community has released the Google Web Toolkit 1.4 Release Candidate 2.

As Scott Blum says:

This may well be the best and most solid GWT release to date, and we expect this build will become the final 1.4 release.

But:

Still, until we designate a “final” 1.4 release, we strongly recommend against using it in production applications.

There is something enjoyable about watching a new release of GWT. Being able to rerun the compiler and see that your output got leaner, meaner, and faster, is pretty cool. It reminds me of the days of playing with gcc and egcs.

Running Java 5 is going to be great too:

Looking ahead, we plan to start on GWT 1.5 quickly, the main thrust of which will be Java 5.0 language support and all that entails. We intend to make a wholesale shift to 5.0 syntax for all GWT client code; with luck this won’t be problematic, since Java 5.0 syntax is largely backwards compatible.

Posted by Dion Almaer at 12:28 am
14 Comments

+++--
3 rating from 39 votes

14 Comments »

Comments feed TrackBack URI

Great news – the planned Java 5 support in the next GWT version. I miss that for a long time.
GWT guys do a very good job in my opinion:
– you can develop powerful AJAX-driven applications and still stay a Javascript newbie
– you can rely on the quality of GWT and if you are missing any feature – just wait for future releases
– GWT guys make a very good support in Google Groups and do quick bug fixing
Keep it up!

Comment by Alexander — August 21, 2007

Why, oh why would one want to “stay a Javascript newbie”?

Comment by david — August 21, 2007

david – perhaps Alexander should’ve stated it more like : “not have to become a hardcore Javascripter”. Admittedly, from a particular point of view, this might seem like the same thing, but what GWT is doing is allowing someone (and more importantly, a development team) that is very Java-centric be able to rapidly and productively produce DHTML/Rich Internet/AJAX applications…from GUI to Backend. And that’s a good thing….

Comment by Mike Shaffer — August 21, 2007

…since Java 5.0 syntax is largely backwards compatible…

Great!

Comment by Fred — August 21, 2007

“…and if you are missing any feature – just wait for future releases”

this is a good thing??
Incredulous

Comment by sam — August 21, 2007

Mike – you gotta wonder, how much of this cradle-to-grave Java stuff is nothing more than a refusal to give up control? Javascript is expressive in ways that Java couldn’t even dream of until Groovy scripting came along – feeling the heat from Ruby (and Javascript), I would submit. Let’s face it, there is a small army of server-side Java programmers that will go down kicking and screaming, heaping scorn on scripting languages and refusing to learn them. But IMHO it’s a bad career choice. There is nothing pretty about a 27-year-old dinosaur.

Comment by david — August 21, 2007

david, yes, JavaScript is expressive as all your beatyfull script languages. But it’s too hard to refactorize, hard to debug, hard to test, hard to OOP, hard to divide the problem, and hard… hard as…. hard as all Script Languages.

Comment by Tio Malandra — August 21, 2007

Whether or not you agree with the java->javascript translation approach that gwt uses, its hard to argue with the results.
I’m on a team of 5 devs and we’re getting a ton of productivity out of gwt vs. a hybrid java/javascript solution.
– There is very little context switch between server and client work.
– We can share server and client data structures very easily, we’ve got several classes that live all the way from client gwt to hibernate/db with 0 translation. (just to be clear, layers are good but hand-coded translation between layers is not).
– We can use our java ide on our client code to get refactoring support and other helpful features.

Noone on the team is a ‘javascript newbie’, but we all recognize the benefits of the gwt approach. Its worth noting that you still need to do quite a bit of real javascript in native methods if you want to do some of the more interesting stuff.

Anyway, RC2 is great news. We’re anxiously awaiting 1.4 final!

Comment by chris — August 21, 2007

sorry but scripting languages aren`t hard,in many ways you solve things in “scripting” languages ten times faster and shorter that you would do in C#/Java.
for example in Python/Ruby(and many other dynamic languages) i can do dynamic mapping of the database to models without writing one line of code where in C#/Java i would need a code generator for this kind of stuff.
or even worse to map DB models to UI datasources i could write something that work on every model where in Java/C# i would need to write a version for each model since i have staticlly typing.

Comment by Uriel Katz — August 21, 2007

GWT is the most heavy-weight framework there is. Two thumbs down. It has its own compiler and its own special browser? What are these people smocking?

In an effort to isolate the developer from as many technologies as possible Google has created an unwieldy monster. Just look how long it’s taking them to move to Java 5.

It’s far superior to grab something lightweight and bulletproof like Prototype or Mootools and use that instead of the insanity that is GWT. GWT requires a wholesale shift in your thinking and approach to web development. Good frameworks allow piecemeal integration and allow you to think however you like.

GWT is broken by design. What surprised me is that Google actually went for that kind of design trade-off. It proves to me that just because you hire people who can solve puzzles and have fancy degrees/credentials is no guarantee that they are actually smart.

Just my 2c.

Comment by Leo Lipelis — August 21, 2007

The best thing about these “cradle-to-grave” application frameworks is that front and back end development don’t have to be separate tracks with separate teams. Especially when talking about web “applications” (as opposed to widgets or script heavy sites) which GWT is targeting this is invaluable. I can actually do top-down development, something that’s until now been very difficult with an ajax heavy site.

Comment by dotThink — August 21, 2007

Uriel — you’re not understanding. It doesn’t have it’s own “compiler” it translates java code into javascript. It doesn’t have it’s own “special browser” it has a tool that lets you skip translation and deployment phase and see your work faster. More like when you switch from HTML Code view to Design view in Dreamweaver.

Comment by dotThink — August 21, 2007

for example in Python/Ruby(and many other dynamic languages) i can do dynamic mapping of the database to models without writing one line of code where in C#/Java i would need a code generator for this kind of stuff.

Oh, yes, it sounds cool. But I want to see your tiny code running when a guy changes a field name in a table of your database.

Comment by Tio Malandra — August 21, 2007

And I want to see you generating the database schema from the object model instead of object model from schema. It’s IMPOSIBLE with a dinamically typed language like Ruby.

Comment by Tio Malandra — August 21, 2007

Leave a comment

You must be logged in to post a comment.