Когда не следует использовать Google Web Toolkit? [закрыто]

55

Я рассматриваю возможность использования GWT в крупном собственном проекте по разработке веб-приложений, а именно, на мой взгляд, его главным преимуществом является кросс-компиляция в Javascript, которая (по крайней мере теоретически) поможет моей команде уменьшить размер стека технологий на один ,

Однако, будучи сожженным ранее (как и большинство разработчиков), я хотел бы услышать от программистов, которые действительно использовали его для любых проблем с GWT, которые мешали или ограничивали его использование в определенной проблемной области.

Какие аргументы против использования GWT и почему?

java javascript ajax gwt Jas
источник
11
Я думал, что GWT умер.
Аарон Макивер
1
@ Аарон, правда?
Jas
10
Я не рекомендую GWT лично. Мышление заставляет вас работать с настольными приложениями, но у вас возникнут проблемы с попытками мыслить таким образом в функциях HTML. Я фанат соответствия парадигмы кодирования и рассматриваемой проблемы, и абстракция мешает мне. Вот почему каждый раз, когда я начал оценивать это, я решил не использовать его.
Берин Лорич
2
@Jas Опыт был пару лет назад; в зачаточном состоянии и в то время это было очень сыро. Это изменилось? Возможно .... но я медленно пытаюсь изучить основы фреймворков вместо того, чтобы полагаться на сами фреймворки. В конце дня это мясорубка для сбивания JS; не то, чтобы это было плохо, но не то, куда я хочу приложить свои усилия. Многие из этих платформ выбраны из-за недостатка знаний о технологии X или чего-то подобного ... но в какой-то момент вам в конечном итоге потребуется знание технологии X, что может сойти с этого пути.
Аарон Макивер
10
Я очень хорошо разбираюсь в JS, написал там несколько довольно серьезных вещей, однако сейчас я работаю над очень критичным по времени проектом, и я не могу позволить себе тратить время младшего персонала из-за ошибок, вызванных переключением контекста, скажем, с Java на JS. Поэтому, пожалуйста, если у вас есть реальный пример того, почему GWT не работает для вас, то, пожалуйста, опишите его, иначе давайте не будем тратить время друг на друга на гипотетические и очень субъективные обсуждения.
Jas

Ответы:

84

Мне и хорошо, и плохо отвечать на этот вопрос - хорошо, потому что я использовал его раньше, и плохо, потому что я имел большой опыт работы с 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 пытаться играть на пианино в боксерских перчатках.

Николь
источник
2
Я узнал некоторые из причин, по которым мы выбрали Wicket вместо GWT, снимаю шляпу перед презентацией.
Бизиклоп
12
-1 для FUD мой опыт использования GWT для малых и крупных приложений оказался скорее положительным, чем отрицательным. И я не сталкивался ни с одной из этих «проблем», таким образом, с комментариями FUD. Мы успешно встраиваем сгенерированные GWT виджеты в очень сложные HTML-страницы без особых усилий. Если вы знаете, что делаете, это замечательно, если вы не хотите думать, что может быть новый лучший способ сделать что-то, тогда следуйте этому «ответу» и игнорируйте этот комментарий.
9
@Jarrod Это не «проблемы», а простые описания природы GWT. Там, где это уместно, я также квалифицировал их как негативы, особенно в рамках целей нашего проекта. Если у вас есть альтернативный опыт, не стесняйтесь записать его. До тех пор единственной недоказанной информацией является ваше утверждение, что GWT «новый и лучший». Кстати - с тех пор как я написал этот ответ, компания (на которую я больше не работаю) потратила более года на работу нескольких инженеров и переписала проект без GWT. За меньшее время
Николь
1
@JarrodRoberson Я согласен с NickC, было бы здорово прочитать столь же подробное описание вашего опыта.
фанкибро
8
@NickC «За меньшее время» переписывание проекта не считается огромным ударом по GWT IMO; любой проект, в котором вы в основном повторяете то, что было сделано ранее, даже в другой среде или на другом языке, должен занимать «меньше времени».
фанкибро
24

Мы используем GWT для большого веб-приложения электронного правительства (SOA в серверной части), которое интенсивно используется. Старый пользовательский интерфейс был в DHTML, но у нас были проблемы с совместимостью браузеров, оптимизацией производительности и процессом разработки, поэтому мы искали альтернативы.

Наши требования были:

  • уровень пользовательского интерфейса на стороне клиента для минимизации нагрузки на сервер
  • совместимость браузера
  • веб-RIA
  • Простая оптимизация производительности
  • Не требует установки клиентских плагинов, должна работать с простой установкой Windows

Мы выбрали GWT, и я никогда не жалею об этом. У новой команды не было опыта работы с DHMTL, поэтому процесс разработки GWT на Java оказался очень полезным. Что вы получаете из коробки:

  • совместимость браузера
  • Процесс разработки на основе Java и повторное использование кода
  • простая минимизация запросов (пакет изображений, ...)
  • простое агрессивное кэширование (новые приложения полностью кэшируются на стороне клиента)
  • простое сжатие всех ресурсов (даже с js на старых, глючных IE)
  • и многое другое, чтобы многое упомянуть здесь

Наше приложение при запуске выдает только один запрос к серверу. Отрицательной стороной является то, что GWT (а также Android) имеют плохой дизайн из коробки, но в любом случае, если вы применяете свой собственный внешний вид и чувствуете, что вы должны адаптировать CSS. В качестве альтернативы вы можете использовать различные библиотеки компонентов для GWT, которые позволяют легко применять надлежащие стили и темы.

Для меня нет никакого смысла, что, возможно, HTML DOM не так хорош, как ручной, это никогда не было проблемой. Когда я разрабатываю на C ++, я не смотрю на сгенерированный ассемблерный код. Когда я разрабатывал в GWT, у меня никогда не было причины смотреть на код JS, и только однажды была причина взглянуть на DOM и провести некоторый рефакторинг.

Для меня GWT - единственный выбор, когда речь заходит о разработке RIA, и я надеюсь, что у GWT большое будущее. См. Заявление о миссии по адресу:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

Но не следует упоминать, что Google не использует GWT во многих своих внутренних проектах и ​​что в настоящее время ходят слухи о будущем GWT, см.

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC

ChrLipp
источник