Надо разложить по полочкам все недостатки GWT, начиная от реализиции до концепции, т.е. до самой идиотской идеи компилировать ущербный язык Java в JS.
Причем если разработчику на примере «дырявых абстракций» Спольски и других вещей я еще могу объяснить, то как объяснить какомунить руководителю, который зомбирован пиаром этого уг.
Итак что нам известно (наяндексовано):
- убогость концепции java->js: Возможно, самый спорный аспект GWT-архитектуры - преобразование языка Java в код клиента. Некоторые GWT-сторонники говорят, что написание кода клиента на языке Java по сути предпочтительнее, чем написание кода на JavaScript. Это вовсе не всесторонний взгляд на проблему, и несколько JavaScript-разработчиков могли бы с большой неохотой пожертвовать гибкостью и выразительностью их языка ради временами обременительных заданий по разработке на языке Java. Единственная ситуация, в которой замещение JavaScript на Java-код было бы привлекательным, - в команде, в которой не хватает опытных Web-разработчиков. Однако, если эта команда будет двигаться в сторону Ajax- разработок, для нее будет лучше, если нанимать опытных JavaScript-программистов, а не полагаться на Java-программистов для производства JavaScript. Ошибки, вызываемые недостатками знания более высокого уровня абстракции GWT, нежели чем JavaScript, HTTP и HTML, неизбежны, и неопытные Web-программисты потратят много усилий и времени, искореняя их. Как разработчик и блоггер Дмитрий Глазков замечает в этом случае: «Если вы не можете работать с JavaScript, вам не следует писать код для Web-приложений. HTML, CSS и JavaScript - три необходимых условия для этого.» (см. Ресурсы).
- GWT тяжело интегрируется с другими продуктами (Spring, Acegi). Интеграцию сложно выполнить без нарушения стандартного цикла разработки под GWT, что может привести к несовместимости с будущими версиями GWT (нужно это учитывать)
- тладка GWT приложения выполняется через GWT-консоль. Отладка в GWT-консоли – это обычный анализ логов. То есть, Вам придется забыть про всю мощь отладчика среды разработки
- Интернационализация - также большая проблема для GWT. Поскольку Java-классы GWT-клиента запускаются в браузере, они могут не иметь доступа к возможностям или к узлам источников, чтобы взять находящиеся там строки кода во время выполнения.
- К сожалению, иногда абстракции недостаточно: в моей проверке действительности ZIP-кода, к примеру, мне захотелось использовать стандартные выражения, чтобы выполнить проверку. Однако, GWT не может выполнить метод String.match(). Даже если бы он мог, стандартные выражения в GWT имеют свои синтаксические отличия применения кода на сервере или кода клиента. Всё это происходит потому, что GWT при работе полагается на лежащий в основе regexp- механизм среды выполнения, и это пример проблемы, которая делает несовершенными ваши абстракции.
- Однако, GWT-панель инструментов представлена только в бинарной форме, и модификации ее не разрешены. Это верно и для компилятора Java-кода в JavaScript, и обратно, что обозначает, что любые ошибки в вашем сгенерированном JavaScript-коде неконтролируемы. Особая проблема взаимодействия пользователя и GWT-разработчиков: каждая версия нового браузера требует обновления GWT-средств, чтобы обеспечить поддержку.
Кто работал с GWT что скажете плохого об этом поделии?
