4 ms·

FWIW, I'd remove GWT from consideration. I heard that it's shortlisted for end-of-life at Google because it's a hassle to work with. Anecdotally, I agree with

FWIW, I'd remove GWT from consideration. I heard that it's shortlisted for end-of-life at Google because it's a hassle to work with. Anecdotally, I agree with that. I once built a product on GWT because it impressed me so much on paper. Static typing, compiling permutations of your app and loading only what's needed, optimization of stylesheets, rendering only on the client etc. It seemed perfect. IIRC the two main issues at the time, a few years ago, were a) terribly slow tooling for any decent sized app and b) the usual interface-hell of Java. This may not be a problem if you're used to it, but for me it was an issue.

arisAlexis 12y ago
The thing is that it doesn't matter if it is EOLed or rumored to be. These things always have a chicken-egg problem because even the rumor will demoralize people to use it in new projects which will make commits fewer which will make users fewer which will make the project die anyways, and that's because a) Google has a history of abandoning projects b) people like to be optimistic (unrealistic) when they chose a framework so they think it will be good for X years.
jacquesm 12y ago
Wow. That's going to piss off quite a few people if google EOL's GWT and they know about it today but are not communicating it to the outside world. Google has a habit of pushing tech out for people to build on and then pulling the rug right out from under them. A citation would really help here but 'I heard' makes me realize that will probably not be forthcoming.
- syjer 12y ago
  Actually, the GWT governance has been handed over to the community ( http://googlewebtoolkit.blogspot.ch/2013/07/gwt-news.html http://googlewebtoolkit.blogspot.ch/2013/07/gwt-news.html ). It's quite obvious that they have less love for gwt than before, but I don't think we can classify it as a EOLed project (as it's actively developed and there is a community outside of google).
- stephen 12y ago
  I know the Google GWT manager, and unless he's playing his cards very close to his chest, GWT is not EOL'd inside of Google. Google did "re-open source" GWT a few years ago, and unfortunately it coincided their (AFAIK unrelated) closing of their Atlanta office (where most of the old GWT team worked). So, it gave the impression of washing their hands of it, but in reality they a) staffed their GWT team back up to 4-5 people, and b) the open source model is much healthier for the project anyway. (Previously the master GWT SCM has literally Google's internal Perforce/etc. repository, so any patches from external contributors had to be fostered by a Googler that cared about your issue, which made it really hard/impossible to have an external community of committers.)
  - jacquesm 12y ago
    I think it will be a long long time before the tech community will forget about wave, that makes rumours like these so credible.
stephen 12y ago
> I heard that it's shortlisted for end-of-life at Google because it's a hassle to work with. Did you hear that from a Googler that actually knows their long term budget/support plans for GWT, or just the usual misguided rumors? Right now Google has 4-5 full-time developers working on GWT because it's used by AdWords (huge) and literally 1,000+ other projects (private and public) inside of Google (including for parts the new "Sheets 2.0" of Google spreadsheets). The end-of-life comment aside, which I'm admittedly defensive about, your other criticisms are unfortunately very valid. Personally, I think a good framework is essential, and the compiler is a known issue that they currently have several smart people working on. We should see by mid-summer if they pull it off.
flavor8 12y ago
The move to superdevmode is the nail in the coffin for GWT for me. It has been my go-to framework for the past 5 years. I really love doing everything in Java (I don't like Javascript, don't particularly enjoy writing HTML, and find the compile time checks of the UI invaluable); some of the core components are clunky to work with, but you can easily write some component libraries that sit on top of GWT and generate elegant HTML. The killer feature is being able to debug UI code in your IDE (specifically, for me, IntelliJ). With the loss of classic dev-mode (mainly due to browsers being a moving target, and the GWT team being too small) that is no longer possible; you now have to interact with the browser's built in debugger, which is qualitatively much worse. So, I'm on the hunt for a replacement too. It'll still be Java-centric (compiled languages ftw), probably will involve Dropwizard, and ideally will generate much of the Javascript. I don't know if that exists yet though.
- stephen 12y ago
  > ideally will generate much of the Javascript Just to play devil's advocate, but with any compiled-to-JS language, you're right back to where GWT is with superdevmode: stuck in the browser's debugger. My hope is that with enough "compiled-to-JS" languages (Coffeescript, etc.) becoming popular that browser vendors will build a standard debugging wire protocol, much like the JVM's, which would allow IDE-based debugging of sourcemapped JS code. This project is taking that on for Eclipse, which is a huge challenge and I'm very impressed that they're even attempting it: https://github.com/sdbg/sdbg https://github.com/sdbg/sdbg Given you use IntelliJ, which typically has a much faster turn around on supporting bleeding-edge browser/etc. integration, I would actually except them to get it first.

arisAlexis 12y ago

The thing is that it doesn't matter if it is EOLed or rumored to be. These things always have a chicken-egg problem because even the rumor will demoralize people to use it in new projects which will make commits fewer which will make users fewer which will make the project die anyways, and that's because a) Google has a history of abandoning projects b) people like to be optimistic (unrealistic) when they chose a framework so they think it will be good for X years.

jacquesm 12y ago

Wow. That's going to piss off quite a few people if google EOL's GWT and they know about it today but are not communicating it to the outside world. Google has a habit of pushing tech out for people to build on and then pulling the rug right out from under them. A citation would really help here but 'I heard' makes me realize that will probably not be forthcoming.

syjer 12y ago
Actually, the GWT governance has been handed over to the community ( http://googlewebtoolkit.blogspot.ch/2013/07/gwt-news.html http://googlewebtoolkit.blogspot.ch/2013/07/gwt-news.html ). It's quite obvious that they have less love for gwt than before, but I don't think we can classify it as a EOLed project (as it's actively developed and there is a community outside of google).
stephen 12y ago
I know the Google GWT manager, and unless he's playing his cards very close to his chest, GWT is not EOL'd inside of Google. Google did "re-open source" GWT a few years ago, and unfortunately it coincided their (AFAIK unrelated) closing of their Atlanta office (where most of the old GWT team worked). So, it gave the impression of washing their hands of it, but in reality they a) staffed their GWT team back up to 4-5 people, and b) the open source model is much healthier for the project anyway. (Previously the master GWT SCM has literally Google's internal Perforce/etc. repository, so any patches from external contributors had to be fostered by a Googler that cared about your issue, which made it really hard/impossible to have an external community of committers.)
- jacquesm 12y ago
  I think it will be a long long time before the tech community will forget about wave, that makes rumours like these so credible.

stephen 12y ago

> I heard that it's shortlisted for end-of-life at Google because it's a hassle to work with. Did you hear that from a Googler that actually knows their long term budget/support plans for GWT, or just the usual misguided rumors? Right now Google has 4-5 full-time developers working on GWT because it's used by AdWords (huge) and literally 1,000+ other projects (private and public) inside of Google (including for parts the new "Sheets 2.0" of Google spreadsheets). The end-of-life comment aside, which I'm admittedly defensive about, your other criticisms are unfortunately very valid. Personally, I think a good framework is essential, and the compiler is a known issue that they currently have several smart people working on. We should see by mid-summer if they pull it off.

flavor8 12y ago

The move to superdevmode is the nail in the coffin for GWT for me. It has been my go-to framework for the past 5 years. I really love doing everything in Java (I don't like Javascript, don't particularly enjoy writing HTML, and find the compile time checks of the UI invaluable); some of the core components are clunky to work with, but you can easily write some component libraries that sit on top of GWT and generate elegant HTML. The killer feature is being able to debug UI code in your IDE (specifically, for me, IntelliJ). With the loss of classic dev-mode (mainly due to browsers being a moving target, and the GWT team being too small) that is no longer possible; you now have to interact with the browser's built in debugger, which is qualitatively much worse. So, I'm on the hunt for a replacement too. It'll still be Java-centric (compiled languages ftw), probably will involve Dropwizard, and ideally will generate much of the Javascript. I don't know if that exists yet though.

stephen 12y ago
> ideally will generate much of the Javascript Just to play devil's advocate, but with any compiled-to-JS language, you're right back to where GWT is with superdevmode: stuck in the browser's debugger. My hope is that with enough "compiled-to-JS" languages (Coffeescript, etc.) becoming popular that browser vendors will build a standard debugging wire protocol, much like the JVM's, which would allow IDE-based debugging of sourcemapped JS code. This project is taking that on for Eclipse, which is a huge challenge and I'm very impressed that they're even attempting it: https://github.com/sdbg/sdbg https://github.com/sdbg/sdbg Given you use IntelliJ, which typically has a much faster turn around on supporting bleeding-edge browser/etc. integration, I would actually except them to get it first.