Мне и хорошо, и плохо отвечать на этот вопрос - хорошо, потому что я использовал его раньше, и плохо, потому что я имел большой опыт работы с HTML / CSS / JavaScript до работы с GWT. Это привело меня в бешенство от использования GWT таким образом, которого не могли знать другие Java-разработчики, которые на самом деле не знают DHTML.
GWT делает то, что говорит - абстрагирует JavaScript и в некоторой степени HTML в Java. Для многих разработчиков это звучит блестяще. Тем не менее, мы знаем, как говорит Джефф Этвуд, все абстракции являются неудачными абстракциями (стоит почитать, если учесть GWT). При использовании GWT это создает следующие проблемы:
Использование HTML в GWT отстой.
Как я уже сказал, в некоторой степени даже абстрагируется от HTML. Это звучит хорошо для разработчика Java. Но это не так. HTML - это формат разметки документа. Если вы хотите создать объекты Java для определения документа, вы не будете использовать элементы разметки документа. Это безумно многословно. Это также недостаточно контролируется. В HTML есть по сути один способ написания <p>Hello how are <b>you</b>?</p>
. В GWT у вас есть 3 дочерних узла (текст B
, текст), прикрепленных к P
узлу. Вы можете сначала создать P или сначала создать дочерние узлы. Один из дочерних узлов может быть возвращаемым результатом функции. После нескольких месяцев разработки со многими разработчиками попытка расшифровать внешний вид вашего HTML-документа путем отслеживания кода GWT вызывает головную боль.
В конце концов, команда решила, что, возможно, использование HTMLPanel для всего HTML - это правильный путь. Теперь вы утратили многие преимущества GWT, заключающиеся в том, что элементы Java легко доступны для легкого связывания данных.
Использование CSS в GWT отстой.
Вложение в абстракцию HTML означает, что способ использования CSS также отличается. Возможно, он улучшился с тех пор, как я последний раз использовал GWT (около 9 месяцев назад), но в то время поддержка CSS была беспорядочной. Из-за того, как GWT заставляет вас создавать HTML, у вас часто бывают уровни узлов, которые вы не знаете, были внедрены (любой разработчик CSS знает, как это может существенно повлиять на рендеринг). Было слишком много способов встраивать или связывать CSS, что приводило к путанице в пространствах имен. Вдобавок к этому у вас была поддержка спрайтов, которая снова звучит неплохо, но на самом деле мутировала ваш CSS, и у нас были проблемы с записью свойств, которые мы затем должны были явно перезаписать позже, или в некоторых случаях, помешали нашим попыткам совпасть с нашими руками. закодировал CSS и просто переделал его так, чтобы GWT не облажался.
Союз проблем, пересечение выгод
Любой язык будет иметь свой собственный набор проблем и преимуществ. Используете ли вы это взвешенная формула, основанная на тех. Когда у вас есть абстракция, вы получаете объединение всех проблем и пересечение преимуществ. У JavaScript есть свои проблемы, и он обычно высмеивается среди инженеров на стороне сервера, но он также имеет довольно много функций, которые полезны для быстрой веб-разработки. Подумайте о замыканиях, сокращенном синтаксисе, специальных объектах, обо всем, что делает Jquery (например, запрос DOM с помощью селектора CSS). Теперь забудьте о его использовании в GWT!
Разделение интересов
Мы все знаем, что по мере роста масштабов проекта хорошее разделение интересов имеет решающее значение. Одним из наиболее важных является разделение между отображением и обработкой. GWT сделал это действительно сложно. Вероятно, не невозможно, но команда, в которой я был, никогда не находила хорошего решения, и даже когда мы думали, что у нас это было, у нас всегда было одно попадание в другое.
Рабочий стол! = Интернет
Как писал @Berin Loritsch в комментариях, модель или образ мышления, для которого создана GWT, - это живые приложения, где программа имеет живой дисплей, тесно связанный с процессором обработки. Это звучит хорошо, потому что многим кажется, что в Интернете этого не хватает. Но есть две проблемы: A) Сеть построена на HTTP, и это по своей сути отличается. Как я упоминал выше, для этой платформы были созданы технологии, основанные на HTTP - HTML, CSS, даже загрузка ресурсов и кэширование (изображения и т. Д.) . Б) Java-разработчики, которые работали в Интернете, не легко переключаются на этот образ мышления настольного приложения. Архитектура в этом мире - совершенно другая дисциплина. Разработчики Flex, вероятно, больше подходят для GWT, чем веб-разработчики на Java.
В заключение...
GWT способен довольно легко создавать быстрые и грязные AJAX-приложения, используя только Java. Если быстро и грязно не похоже на то, что вы хотите, не используйте его. Компания, в которой я работал, была компанией, которая очень заботилась о конечном продукте, и для пользователя это было визуально и интерактивно. Для нас, фронт-эндовых разработчиков, это означало, что нам нужно было управлять HTML, CSS и JavaScript таким образом, чтобы при использовании GWT пытаться играть на пианино в боксерских перчатках.