Помимо аргумента в пользу простоты Wicket (то есть Wicket - это более простая система, IMHO) и отзывчивости GWT на клиенте (состояние на стороне клиента GWT и JavaScript - потенциально сложный код на стороне клиента) и большего потенциала GWT для масштабирования, что является аргументом в пользу используете GWT поверх Wicket?
Лично я много занимался разработкой Wicket, но только бегло взглянул на GWT очень давно.
В основном преимущества заключаются в том, что GWT - это инструмент для создания клиента на основе javascript, поэтому он лучше всего подходит, если вам нужен клиент на основе javascript.
Wicket сосредотачивается на сервере, и, хотя он позволяет довольно легко встраивать javascript в страницы без состояния, обработка состояния на стороне сервера является более естественным подходом.
Надо заметить, что архитектуры очень разные.
С GWT ваша архитектура превращается в клиент-сервер, толстый клиент в браузере, который обращается к «процедурам» (службам) на сервер, отправляя и получая данные.
В Wicket (и других серверных компонентных фреймворках, таких как JSF и Tapestry) архитектура является более «традиционной» трехуровневой, а отправляемые и получаемые данные - страницы или фрагменты страниц, а не чистые данные.
Хотя вы, безусловно, можете смешать и то, и другое, чтобы адаптироваться к другой архитектуре, это было бы не очень естественно.
Люди склонны сосредотачиваться на том, «что проще в использовании» (что полностью субъективно, в зависимости от вашего опыта) или «что красивее и имеет больше компонентов», но не следует недооценивать архитектурные различия, которые влияют на ваш подход. необходимо учитывать такие аспекты, как безопасность и масштабируемость.
Я участвовал в проекте на основе GWT в течение последних нескольких месяцев. Я был частью команды разработчиков Wicket в течение многих лет, с нетерпением ждал перемен и многого ожидал от GWT (который я всегда рекламировал как еще одну отличную среду Java).
Честно говоря, я разочарован, когда дело доходит до работы с GWT. Я чувствую - фактически вся моя команда - что продуктивность сильно пострадала. Теоретически GWT отличный. Но если учесть причуды и ограничения фреймворка, посредственные сообщения об ошибках (особенно когда дело доходит до ошибок сериализации), длительное время компиляции (где-то от 3 до 10 минут, а наш проект еще даже не такой большой), тот факт, что, когда все сказано и сделано, вам все равно нужно протестировать для всех браузеров и найти настройки и обходные пути, тот факт, что он производит огромную начальную загрузку (почти МБ, которую мы постепенно сокращаем, но с большим усилий) и т. д., я считаю, что с Wicket намного проще и быстрее работать.
Я не ненавижу работать с GWT. Он по-прежнему намного лучше, чем большинство фреймворков Java. Просто я ожидал намного большего от работы с ним; Я даже ожидал, что он будет лучше, чем Wicket. Но, в конце концов, это не имхо. Будем надеяться, что GWT 2.0 улучшит многие вещи, и, надеюсь, вскоре будут исправлены некоторые особенности плагина Eclipse.
Несколько нечестно сравнивать GWT с калиткой (или аналогичным образом), поскольку на самом деле они происходят из двух разных лагерей. Первый представляет собой структуру для создания интерфейсных приложений JavaScript, а второй - классическую структуру веб-приложений Java.
Таким образом, приведенные ниже пункты - это не столько GWT и калитка, сколько общий список, который был составлен, когда мы решили использовать GWT для расширенного веб-приложения JavaScript / AJAX:
Одним из преимуществ Wicket перед GWT является то, что Wicket может справиться с ситуацией, когда вы хотите предоставить запасной вариант для клиентов, у которых не включен Javascript. GWT полностью поддерживает Javascript, Wicket позволяет изящно деградировать.
На мой взгляд, самое большое преимущество GWT - это возможность работать с одним языком программирования - Java со всеми достоинствами, которые он приносит.
Вместе с CSS они образуют мощную пару.
Другими словами, вы можете по большей части забыть о Javascript и HTML.
Является ли это преимуществом или нет, в основном зависит от ваших навыков и требований. У нас были такие же дебаты внутри компании, и в конце концов одна команда выбрала Wicket, а другая - GWT.
Я могу придумать несколько причин, по которым GWT является лучшим выбором, чем Wicket, для типичных бизнес-веб-приложений:
Гениальность GWT заключается в том, что вы работаете исключительно с java. Они отлично поработали с RPC, сделав его почти прозрачным для программиста. Часто вам кажется, что кодирование больше похоже на настольное приложение, а не на приложение с действительно определенной клиентской и серверной стороной.
Я новичок в GWT, но после некоторого исследования я обнаружил, что GWT «подходит» для моего нового проекта веб-приложения, поскольку он ориентирован на клиента, что заставляет меня чувствовать себя как кодирующее настольное приложение. Сегодня у нас есть высокопроизводительный клиент, готовый для запуска приложения на стороне клиента. Мое приложение может быть выполнено исключительно на Java, а Java-класс ООП дает возможность создать нашу собственную готовую к использованию структуру для нашей команды.
Я нахожу несколько других преимуществ калитки перед GWT.
