Google Web Toolkit 1.7 | Hacker News Reader

Google Web Toolkit 1.7

code.google.com

25 pointskirubakaran22 comments

Is GWT frontend only, or is it a full stack front and backend thing?

It is both, as it is both a front-end development platform including a full set of widgets and an AJAX implementation that handles all the plumbing of exposing and invoking AJAX services.

It doesn't tell you how to implement the back-end application though so it is not an application framework in that sense.

(I don't mean to pimp, but I have previously mentioned http://www.teampostgresql.com which we develop using GWT)

So it fills the same niche as cappuccino. It's a full featured javascript framework that happens to be written in a different language from javascript.

But it's not like Jaxer, since it doesn't provide a server-side component built in.

You're contradicting yourself then. If it doesn't implement the backend then it isn't both.

It implements the unmarshalling of incoming AJAX requests on the backend. The application developer takes over from there.

There is GWT code running on both the server and the client. That was what I meant in my comment.

How does this make things easier? I find FF + FireBug to be a pretty good dev environment for the front end. The problem is integrated debugging with the back end of things, whether that is PHP, Python or whatever.

It depends on your experience and problems that you need to solve (I'm talking about client-side).

GWT comes with tons of goodies that you probably haven't needed but Google or Yahoo or some other companies do need them.

It sounds like you might be confused about what GWT is. It's not a replacement or alternative to FireBug. They do completely different things.

GWT is basically a set of widgets and controls. It allows you to write Java code that generates a slick HTML/Javascript/AJAX frontend without having to worry much about things like requests and HTTP. It's a web development environment that feels more like a desktop environment.

In any case, it also solves the debugging problem because the whole thing is now in Java. Just use your Java debugger.

That's exactly what I'm asking.

Is the backend also in Java then? So that debugging front and backend is all integrated? My impression from what I've read is that it is strictly front end Java to Javascript conversion, not both sides.

(in my original comment I could have been a bit clearer I suppose -- I currently find the pain in web app development to be debugging the interaction between the UI and the backend. I see how GWT can make UI development easier, but not the full stack)

Yes. Google released an Eclipse plugin which helps you write setup the toolkit and start developing applications in no time. GWT also comes with an in build server which lets you test run your Client side code with complete debugging facilities of Eclipse/Java. I agree that Firebug is a good tool, but I just can't replace Eclipse with FF/Firebug.

The complete backend can be coded in Java. This of course you can debug even after you have compiled the entire front end of pure JS.

GWT also provides some useful data modeling techniques to exchange data between the server and client (basically an abstraction over AJAX).

I used to dislike the earlier versions of GWT because of its dependency on Java 1.2 and not being able to support the higher versions, but the current versions seamlessly compile Java 1.6 code and its awesome.

I like it, but it's still java-only.

That makes it a private static final No go, for me.

What do you mean by java-only? This toolkit is, at its most fundamental level, a Java-to-Javascript compiler. Are you hoping that they write a Python-to-Javascript compiler and still call it GWT?

Well, I'm not realistically hoping for anything wrt GWT.

I was just trying to say: I like the concept, but not enough to walk through java-hell for it.

So, talking about hopes, I hope pyjamas will mature to a point where it becomes a serious option.

no, they call it pyjamas:

http://pyjs.org/ http://code.google.com/p/pyjamas/

Pyjamas is a port of GWT to python by a different team, by the way (you probably already know, just making it clear)

Depends, they could have made it JVM bytecode to html/javascript/etc compiler, allowing you to use any jvm language theoretically, or at least any that can compile to .class files (scala, clojure, probably others I don't know about).

I dislike it because I think JavaScript is a perfectly reasonable language for application development - it may have its warts, but they certainly aren't worth introducing a layer of abstraction that thick over them (and Java is hardly wart-free).

I have used GWT extensively and like it a lot.

You are approaching the problem from the perspective of deploying a new web-application.

GWT is good when you are approaching from an existing service and web-enabling it.

---

Further, some people like compile-time checks and the sophisticated IDEs.

With statically typed languages you can easily build an exhaustive list of all uses of something, where as dynamic/functional is much harder.

This makes changes and refactoring easier IMO.

>With statically typed languages you can easily build an exhaustive list of all uses of something, where as dynamic/functional is much harder. This makes changes and refactoring easier IMO.

This is not guaranteed in Java and C# -- someone might have used reflection somewhere. http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...

Reflection is usually kept at minimum at most libraries and systems. Those reflection codes are also self-contained in most cases (transforming from one object to the other, etc).

So all in all, refactoring is still a lot easier.

Furthermore, GWT takes out Java reflection.

JavaScript is a perfectly reasonable application for the initial stages of application development, I'll grant you that. But it's flawed in the long-term, when it comes time for someone else to maintain and safely refactor the code as the originators leave and someone else needs to inherit the codebase. That's when the static nature of Java bears fruit. The nice side-effect of fully leveraging its static nature is that you always get the minimal amount of javascript to ship over the wire. (Their "pay as you go" design philosophy.)

You're missing the value of having the same language for both client and server. If you have some code that you want to run both in the browser and on a server, GWT lets you write that in Java. Unless you write server-side javascript you can't do this in pure JS. (Too bad appjet is shutting down.)

Reply on news.ycombinator.com