5 ms·

Google Web Toolkit 1.7

25 points by kirubakaran 17y ago

moe 17y ago
I like it, but it's still java-only. That makes it a private static final No go, for me.
- pohl 17y ago
  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?
  - moe 17y ago
    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.
  - stanleydrew 17y ago
    no, they call it pyjamas: http://pyjs.org/ http://pyjs.org/ http://code.google.com/p/pyjamas/ http://code.google.com/p/pyjamas/
    - lacker 17y ago
      Pyjamas is a port of GWT to python by a different team, by the way (you probably already know, just making it clear)
  - runevault 17y ago
    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).
- simonw 17y ago
  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).
  - tezza 17y ago
    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.
    - swolchok 17y ago
      >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.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
      - hello_moto 17y ago
        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.
  - pohl 17y ago
    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.)
cschneid 17y ago
Is GWT frontend only, or is it a full stack front and backend thing?
- deleted 17y ago
  [deleted]
- johnyzee 17y ago
  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 http://www.teampostgresql.com which we develop using GWT)
  - cschneid 17y ago
    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.
  - bcl 17y ago
    You're contradicting yourself then. If it doesn't implement the backend then it isn't both.
    - johnyzee 17y ago
      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.
bcl 17y ago
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.
- hello_moto 17y ago
  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.
- jm4 17y ago
  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.
  - bcl 17y ago
    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)
    - wicknicks 17y ago
      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.

25 points by kirubakaran 17y ago

moe 17y ago

I like it, but it's still java-only. That makes it a private static final No go, for me.

pohl 17y ago
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?
- moe 17y ago
  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.
- stanleydrew 17y ago
  no, they call it pyjamas: http://pyjs.org/ http://pyjs.org/ http://code.google.com/p/pyjamas/ http://code.google.com/p/pyjamas/
  - lacker 17y ago
    Pyjamas is a port of GWT to python by a different team, by the way (you probably already know, just making it clear)
- runevault 17y ago
  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).
simonw 17y ago
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).
- tezza 17y ago
  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.
  - swolchok 17y ago
    >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.html http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht...
    - hello_moto 17y ago
      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.
- pohl 17y ago
  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.)

cschneid 17y ago

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

deleted 17y ago
[deleted]
johnyzee 17y ago
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 http://www.teampostgresql.com which we develop using GWT)
- cschneid 17y ago
  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.
- bcl 17y ago
  You're contradicting yourself then. If it doesn't implement the backend then it isn't both.
  - johnyzee 17y ago
    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.

bcl 17y ago

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.

hello_moto 17y ago
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.
jm4 17y ago
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.
- bcl 17y ago
  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)
  - wicknicks 17y ago
    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.