Is still GWT pertinent for new projects? [closed]

Question

The question Why should I use jQuery instead of GWT? may be outdated (as its answers). And most of the other SO related questions may also be outdated nowadays. So, let's update the state of the art about GWT relevance for new projects.

GWT is more mature nowadays

Since 2009 questions/answers, GWT has evolved and some JS frameworks are available in Java:

• GwtQuery for jQuery (gQuery)
• GXT for ExtJS (former ExtGWT)
• Smart GWT has superseded GWT-ext
• ... and surely more ... (please feel free to append)

And even more, Java code can be converted to standalone JS libraries: gwt-exporter

But low-level JS frameworks may be enough

But more I read, more I see web developers advising to turn his back on GWT and use directly JS frameworks (Firebug, IDE plugins for JS frameworks...).

Productivity

However I like the idea of developing and debugging using the same IDE (Eclipse, Netbeans, IntelliJ IDEA...). I think I will be more productive... I should also think about Documentation and Community (forum reactivity as for this SO question)...

Questions

1. For what kind of new 2014 project GWT should be (or not) considered?
2. Are there pertinent alternatives to GWT for easy AJAX web application development & deployment?
3. What are the current mode and trend?

My specific case

I have just completed a POC (of an intranet web app) based on Python3 (http.server.HTTPServer) calling (POST) bash scripts (some processing in C++) and retrieving JSON data. Some JS (no framework) in the web page for rendering. So I am wondering the best option for next iteration.

But please answer this question about other cases too. I would prefer a general question/answer to be useful to many more people.

---

UPDATE October 2015

GWT looks less active because no new release since 11 month. But in the past until 13 months between versions 2.4 and 2.5. The Git repo mirror is still very active. Moreover GWT is extensible, and new features can come from GWT libraries without requiring new GWT framework release. See for example the most common mobile GWT libraries and there corresponding release cycles. In the mean time the trend is to use Node.js everywhere! Adoption of GWT for new projects really depends on developers skills/motivation and project lifetime (turnover/training/maintenance). Some other criteria as reuse of available source code and time-to-market may also be taken into account... See excellent below answers.

Stephanystephen

This post may ask for personal opinion, but I think the question deserves to stay on SO because it's of general interest and well developed. – Archiphoneme

I agree with you @LorenzMeyer: It is not easy to request advices on technology decision without provoking personal opinions (personal soft spot, personal experience sharing...) Hope answers will be objective and useful to other people. Please tell me what I should improve in my question (title?) Cheers ;) – Stephanystephen

One year after this question, one year after the last GWT release. As someone evaluating it for a new project, that sounds kinda' dead. – Cutshall

Sorry, what I meant was 11 months and no new releases sounds to me like the project is not very active. I realize that is just one data point (maybe there have been regular updates to the code), but it makes me a little concerned about the wisdom of committing to them in the future. – Cutshall

Thanks @MatthewCornell for your feedback. Yes GWT looks less active. But remember: 13 months between versions 2.4 and 2.5. The Git repo mirror is still very active. Moreover GWT is extensible, and new features can come from GWT libraries. See for example the most common mobile GWT libraries and there corresponding release cycles. In the mean time the trend is to use Node.js everywhere! It really depends on developers skills/motivation... – Stephanystephen

Answer 1

For point 1 I can give you some criteria that I would use:

When using JavaScript based frameworks you are typically very fast in the initial creation of the code. In my experience, you are much slower when it comes to maintenance (bug fixes, new features, refactorings) as tool support isn't that good as it is for statically typed languages. So for bigger or long running projects I would always choose GWT because of Java and it's compiler checks/ecosystem/tooling. I think you will benefit of better efficiency and scaling in development over time as you won't have strange problems due to dynamic typing. For smaller projects that won't live too long or won't need big refactorings, JavaScript Frameworks can be a big push in development speed.

Debugging needs in the context of your target platform are also a criteria for me. Debugging GWT Code is very nice as long as you have a browser that is supported by DevMode or at least can be used with the new source maps based SuperDevMode. E.g. Safari on MacOS X isn't supported. For mobile devices, you can remote debug JavaScript on Android Chrome but as far as I know this isn't possible for GWT.

Another criteria for me is team size and turnover rate. Java based tools (IDE's, code quality checkers, ...) help developers, especially new ones to navigate through other developers' code. This is also true for other statically types languages, but you asked for GWT/Java.

The next one is the stack question ... GWT easily solves the client and remote communication part if use a servlet container on the server side. It's also easy to combine it with mature Java enterprise technologies (JPA, EJB, Spring framework, ...). This is a big strength if you need/want to have the stack. If you are going polyglot without JVM on your server side(as mentioned above), this one isn't for you.

Sure, there are more criteria for both, GWT and JavaScript frameworks.

And the big question is about preferences. JavaScript has really nice concepts (e.g. Closures) but is also a risk due to it's dynamic typing. Which one do you prefer?

Regarding point 2:

I'm not sure if there is a real alternative for GWT that provides similar features and tooling. Most other frameworks focus on one aspect only (Widgets, optimization, databinding, remote communication, browser support, I18n, ...). That doesn't mean, other frameworks are bad, but you typically need a combination of different frameworks to get the functionality that GWT provides.

Regarding point 3:

• I would definitely have a look at TypeScript due to it's improved typing and interoperability with JavaScript
• As far as I remember, Dart has a similar goal
• The evergreen is JQuery but dependent on your needs there are good alternatives. But that is highly subjective
• For widgets, Twitter Bootstrap (http://getbootstrap.com/) is nice if it's way to do things is ok for you. There's even a GWT version of it (http://gwtbootstrap.github.io/)

Demission

Thank you very much Steffen, your answer helps to make the decision. Thanks also for the GWT-Bootstrap link ;) If you want, you may also mention Node.js as a current trend. I am waiting for other answers before accepting... Cheers ;) – Stephanystephen

What about the compiling time of 5 minutes I read in other threads of GWT? – Racon

For development, there are ways to avoid 5+ min of compilation time as you typically don't need a fully optimized version while testing as developer on localhost. When building for production, this isn't a problem from my point of view (use a big server for it). If you do the same things with your JS application (inlining of CSS/images/..., combining all source codes, minification/obfuscation, perfect caching, ...) you will end up using several tools that will take much longer in total than the GWT compiler. And yes you should do all this if you care about latency, bandwidth and other things. – Kennithkennon

so how much compiling time do you actually face when using your development settings? – Racon

Point of reference... My biggest GWT project is around 10k lines of code. I run super dev mode in development (GWT 2.7). Dev cycle is edit, save file, hit the GWT-eclipse-plugin's refresh button, refresh button in the browser and it renders my app in seconds. Production compile is a different story. Compiling for optimized output for all major browsers takes about a minute. Caveat: I'm running on a 6-core mac pro w/ a SSD and 16G of RAM, so I'm sure that helps speed things up. – Aiglet

For my personal opinion gwt is too complex. Actually you can not write just java code. Instead you have to search supported libraries. For example no jodatime (see first comment) in gwt. And this is only opne example. For my point of view It is better to use Angular like front end with pure rest instead of gwt. – Lelalelah

I can just tell you I was given a GWT project to fix and it is a big problem because: GWT is outdated, has internal errors and depends on specific IDE and browser plugin. Currently, one has to install Firefox 24 to run GWT debug plugin. Maybe once GWT was good, but now it creates more drag than thrust so to say. – Fondue

Answer 2

Great answer by Steffen. I started typing it as comment to his, but found that I typed more than I expected, so making it a separate answer. Not hunting for points...

I just wanted to add 1 subjective point of mine. The reality is that majority of developers are so-called backend developers with no knowledge, experience and most importantly desire to develop web frontend. Reality of US IT market is that majority would prefer Java in their resume over JS, PHP, Python and other exotic languages. The reason is compensation. Java developers on average get paid more. Not sure about other countries.

So majority of developers in a company would be Java developers (or .NET, which is outside of this conversation). In order to make them work on UI you have to use a Java compatible technology, which would be JSP or GWT. JSP would require to learn JS libraries to make the frontend more or less presentable.

Obviously, if you want to impress public with unique UI you have to use JS libraries that allow for greater customization. Both JSP and GWT would work as majority of work is going to be done in JS. As I mentioned above, few companies would have experienced JS developers on staff.

Majority of applications though are written for internal use, not facing public. From what you described, your use case may fall under this category.

Internal non publicly facing tools often have a more complex functionality than public websites, but their design requirements are more relaxed as long as functionality is there and convenient for internal use.

In this case you can get away with GWT, which is less foreign for Java developers than jQuery and a high level library such as GXT with standard theme.

GWT with GXT for us was an easy and quick way to create a set of internal applications. With the team of Java developers our company has, we would never come close to the quality or even completeness of projects within the same period of time.

Masterstroke

Answer 3

Just head off to: GWTs example page, showcasing real world examples of GWT applications

Just read about the super heavy weight nature of these examples.

GWT itself is not that light weight, and I doubt it was designed to create a datepicker. GWT is something completely else than jQuery as well. It is maybe more comparable to JSF2 than to jQuery. The question "should I use GWT or jQuery" could be answered like:

if you want to add datepickers, some effects, a sortable table, an autocomplete here and there. You should probably go with jQuery.

If you want to figure out if you want to use GWT as the frontend template / engine mechanism, you should consider other that are actually comparable. When discussing java, probably JSF2 is your only choice. And JSF learning curve is steep.

I am digging deeper and I found a sad post:

http://polygoncell.blogspot.mx/2013/07/gwt-for-new-project-no-thanks.html

I came to this page because I was reading about the upcoming projects like AngularJS, Backbone, single page applications (SPA): In short, google dropped GWT. GWT is now open source, because they just abandoned it. Now AngularJS gets a big push by google.

EDIT our dear andrew told me to "prove my point"

here is the algorithm to use to evaluate if a technic is competitive.

1) Go to your favorite job site

2) Search for {technology which interests you} jobs

3) Check out number of openings, related technology requirement etc

4) Repeat #2 & #3 for competitive technologies

5) Evaluate

today 19. may 2016, on upwork i searched for GWT jobs.

Jobs: 23.

I searched for angularjs jobs.

Jobs: 1338. That's right. one thousand three hundred thirty eight.

point proven?

Racon

@Tokskan "In short, google dropped GWT"... Update, google inbox (a new google product) uses GWT: googlewebtoolkit.blogspot.com/2014/11/… – Aiglet

true, sounds promising what they are writing. Another super heavy weight app of course. Let's see what the future brings. – Racon

I think it depends what you mean by heavy. I rewrote an ADF (a JSF-based framework I'd consider heavy) application into very optimized GWT (stripping out the default GWT styles, compiling in all the CSS, images, etc.) and it reduced the bandwidth needed by 75% and the # of requests to build the page by 90%. This is rendering the exact same content, images, etc. Compared to ADF I'd definitely say GWT it can be very light (obviously learning to optimize whatever tool you're using helps). I can't speak to how it compares to straight JS w/ libraries. What were you comparing it to? – Aiglet

with heavy I actually meant more of a desktop application style. In that meaning heavy. Gimmicks connections and dependencies in pretty much all elements. Sure it will reduce load a lot. – Racon

Ah, I see what you mean. Google Adwords (mentioned here gwtproject.org), might be an example of a more simple classic example as opposed to desktop app replacements. – Aiglet

This is exactly why such questions are seldom allowed in StackOverflow. You are making a very biased statement here. If you make a statement about something, the onus is on you to prove that. Otherwise, don't make such statements. – Minardi

@Minardi well, why don't you go ahead and state why my post is biased? instead of just crying about how unfair life is. – Racon

@Stinky cough google adwords certainly is a great example of a not simple example. You are really saying googles adwords mechanism is simple? the bread and butter, the moneymaker of google? but i think you are more referring to that it does not take up the whole screen? it loads quickly? – Racon

@Minardi i updated my answer. Is it ok for you like that now? – Racon

@Racon That proves my point. It is now indeed clear your claim is based on some basic notion you have with the Technology rather than technical or evaluated logic. To clear the matter, GWT is intended for Java developers, search for Java developers. Also, the availability of jobs for a particular technology is not necessarily an indicator of whether the technology is stronger. It can have multitude of reasons. The onus is on you to prove, cause you claim it here, not me. – Minardi

haha good joke man :D it really made me laugh. Now a java developer is a programmer. Why don't we search for programmer instead of searching for GWT? you are really funny. haha :) – Racon

Answer 4

I guess to answer point 1, you'd have to look at what your current situation is and what your goals are.

If you have a team of developers that have been using Java most of their careers, you can probably expect a good 6 months for them to learn the paradigms of JavaScript. If the have experience in languages like Groovy or Clojure, you could probably cut that time down some. So, if you aren't expecting the project to last more than a year or so, then GWT would probably be the way to go.

Conversely, if you have a team of JS developers, they may find the static typing system rather frustrating and learning to use it effectively could take half a year for them. So if this is the case, then you probably wouldn't want to use GWT for any new project where the learning curve outweighs the productivity.

I'm not really sure what point 2 is asking. If you are asking about whole stack frameworks, I'm guessing you could find something using nodejs, though I don't think I have enough experience to advise on that.

On point 3, where I work, we seem to be moving towards using JS frameworks (AngularJS in particular) with some (new) servers/services written in Python and Groovy, and the legacy systems still in Java. We also have a couple of services being written in Clojure.

Taylor

GWT has a Java to JS compiler, not JVM bytecode to JS compiler. That means other JVM languages can be used only for backend. Frontend has to be written in Java. – Prehensile

Answer 5

GWT is pertinent. It has 130,000 developers using it. If you don't believe me just look at [GWT is coming back in .. in 2015][blog.xam.de/2014/02/gwt-is-coming-back-in-2015.html] and another stackexchange question which talks about this. GWT shouldn't be you're first option because it adds a lot of complexity.

What projects are GWT good for? GWT is much more complicated:

• Java is a harder language that makes it hard to write bad code
• Compiling to javaScript adds complexity
• GWT was built from the ground up for extremely complicated web apps
• the GWT community tends to prioritize user experience and performance over developer experience more than the javaScript community

However, the it's cleaner more maintainable code, it's java, it's faster, and you can reuse your code on the jvm and ios if you use J2ObjC

there are some very compelling reasons to use GWT - Java
- reuse your own code from other platforms. For example, google inbox reuses most of it's android code on the web using GWT and reuses it's code again on iPhone(thank J2ObjC) and the server(thank the JVM's ability to run on many different platforms). - use java libraries and tools, java developers - many developers prefer java to js and have good reasons to prefer it - built from the ground up for complicated, performant web apps. - Java code is cleaner and more maintainable

GWT has been going down according to google trends and indeed job trends but javaScript and jQuery are also going down. I don't know why these technologies are all going down. My theory is that there's a lot of new frameworks that are stealing developers from GWT and javaScript. I don't think this necessarily means that javaScript and GWT are dying yet though. This nothing more than the result of having a lot more competition.

Muskellunge