Мої враження після 6 років використання GWT.

Для початку поясню чому вибір взагалі впав на GWT - це дуже просто, бо пристойного іншого не було. Всі сучасні javascript фреймворки(бібліотеки) на той час або ще не існували або тільки тільки зароджувалися. А GWT уже пропонував мінімізацію і оптимізацію коду, розбивку коду на модулі і завантаження за запитом, інтеграцію із мавеном, тестування, дебагінг. Зараз той самий angular чи reactjs можуть робити те саме, але в 2011 - 2012, наприклад, reactjs ще не існував.
І так, що мені подобається в GWT:

• Мова програмування Java - це значить, що швидкість написання коду для клієнта і для сервера однакова, що підтримка зі сторони IDE максимальна. Один і той самий код можна використовувати як для клієнта так і для сервера.
• Дебагінг - хоча в ранніх версіях від був кращий, бо браузери ще підтримували NPAPI GWT плагін дозволяв дебажити прямо в улюбленій IDE. В поточних версіях, так само як і в сучасному javascript, це робиться в developer tools і за допомогою source maps. До того ж підтримка в Chrome найкраща.
• Інтеграція з мавеном - не потрібно нічого придумавати як все збирати і тестити. Наприклад компіляцію GWT можна виділити в окремий профайл.
• Тести за допомогою JUnit - тести виконуються при компіляції, так що головне відділити код основної логіки від предствалення. Саме тому MVP краще підходить ніж MVC.
• Можливість розширення - любий клас чи інтерфейс можна підмінити на свою реалізацію. Плюс код можна згенерувати. Наприклад робота із JSON в GWT схожа на роботу із XML DOM в яві. І щоб руками не пробігати весь JSON і не писати свої парсери, то такий код можна просто згенерувати на етапі компіляції.
• Робота із помилками і логами - із коробки є можливість все відправляти на сервер, де все буде писатися уже в log4j тощо. Плюс якщо трішки послабити опції оптимізації, то можна добитися того, що стек трейси із клієнта будуть містити назву класів і номера рядків ще відбулася помилка. І все це буде писатися на сервері в лог файли.
• Можливіть реалізувати плагіни - головно точка старту в GWT це клас який реалізує EntryPoint. Але якщо таких класів два? Обидва будуть виконані. Навіть якщо другий клас знайходиться в іншому jar файлі. Правда потрібні деякі маніпуляції із конфіг файлом. І виходить, що функціональність аплікухи можна розширяти просто добавляючии залежності в pom.xml.
• Guava - на 99% підтримується в GWT.

Звісно ж у GWT ще багато гарних плюшок типу завантаження коду за запитом, i18n та l10n, інтеграція із javascript тощо. Але й з тим є деякі мінуси.

І ось вони

• Повільна компіляція - наприклад наший проект на роботі збирається десь за 8 хвилин на 4-х ядерному core i7 з 16 гігами пам'яті. Звісно є всякі обхідні варіанти типу при розробці не проводити оптимізації і компіляти тільки для одного браузера. Але всерівно швидкість не така як angular.
• Вихідний код всерівно більш роздутий і це зрозуміло, бо замість того щоб працювати із натівними структурами javascript, ми працюємо із різномантними згенерованими враперами. Наприклад ArrayList врапить доступ до javascript масиву і добавляє методи із інтерфейса List.
• Повільний розвиток - GWT уже далеко не самий популярний фреймворк і як результат його розвиток іде трохи повільнішими кроками ніж хотілось би.

Кілька цікавих і безкоштовнийх бібліотек: guava-gwt, gwt-jackson, gwt highcharts, gwt-charts, GWT-OpenLayers 3, SmartGWT, gwtmaterialdesign, GWTP