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.

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/)

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.