Теперь с GWT 2, каковы преимущества перед калиткой и аналогичным образом?

Question

Помимо аргумента простоты Wicket (то есть Wicket - более простая система IMHO) и отзывчивости GWT в клиенте (состояние на стороне клиента GWT и JavaScript - потенциально сложный код на стороне клиента) и больший потенциал GWT для масштабирования, аргумент в пользу использования GWT вместо Wicket?

Лично я много занимался разработкой Wicket, но давно только взглянул на GWT.

Answer 1

Преимущества в основном в том, что GWT - это инструмент для создания клиента на основе javascript, поэтому он лучше всего подходит, если вам нужен клиент на основе javascript.

Wicket центрируется на сервере, и, хотя довольно просто встроить JavaScript в страницы без сохранения состояния, обработка состояния на стороне сервера является более естественным подходом.

Надо заметить, что архитектуры очень разные.

С GWT ваша архитектура превращается в клиент-сервер, толстый клиент в браузере, совершающий вызовы «процедур» (сервисов) на сервер, отправляя и получая данные .

В случае Wicket (и других серверных сред, ориентированных на компоненты, таких как JSF и Tapestry), архитектура является более «традиционной» трехслойной, и отправляются и принимаются страницы или фрагменты страниц, а не чистые данные.

Хотя вы, безусловно, можете смешать оба варианта для адаптации к другой архитектуре, это просто не будет очень естественным.

Люди склонны концентрироваться на том, «что проще в использовании» (что полностью субъективно, зависит от вашего фона), или «что красивее и содержит больше компонентов», но не следует недооценивать архитектурные различия, которые влияют на подход, который вы должны использовать для обработки таких аспектов, как безопасность и масштабируемость.

Answer 2

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

Честно говоря, я разочарован, когда дело доходит до работы с GWT. Я чувствую - на самом деле всю мою команду - что производительность сильно пострадала. Теоретически GWT великолепен. Но если учесть причуды и ограничения среды, посредственные сообщения об ошибках (особенно когда речь идет об ошибках сериализации), длительное время компиляции (где-то от 3 до 10 минут, а наш проект еще не настолько велик), тот факт, что когда все сказано и сделано, вам все еще нужно протестировать все браузеры и найти твики и обходные пути, тот факт, что он производит огромную первоначальную загрузку (почти МБ, которую мы постепенно сокращаем, но с большим я чувствую, что с Wicket работать намного проще и быстрее.

Я не ненавижу работать с GWT. Это все еще намного лучше, чем большинство фреймворков Java. Просто я ожидал гораздо большего от работы с ним; Я даже ожидал, что это будет лучше, чем Wicket. Но, в конце концов, это просто не imho. Надеемся, что GWT 2.0 улучшит многие вещи, и, надеюсь, некоторые из особенностей плагина Eclipse также скоро будут исправлены.

Answer 3

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

Answer 4

Несколько нечестно сравнивать GWT с калиткой (или аналогично), поскольку они действительно происходят из 2 разных лагерей. Первый представляет собой среду для создания интерфейсных приложений JavaScript, а второй - классическую среду веб-приложений Java.

Таким образом, приведенные ниже пункты - это не столько GWT или калитка, сколько общий список, составленный, когда мы решили использовать GWT для расширенного веб-приложения JavaScript / AJAX:

• скрывает недостатки JavaScript и кросс-браузерную поддержку, позволяя разрабатывать на Java и автоматически компилировать в браузерную версию JavaScript (это не полностью верно из-за Закона Утечки Абстракций, но это главная причина, по которой GWT был создан в первую очередь - см. Использование Ограничений );
• Java предпочитают многие Java-разработчики, когда переходят к расширенному интерфейсу JavaScript / AJAX;
• Полностью поддерживается среда разработки Java и инструменты: плагин Eclipse, отладчик, рефакторинг, режим хостинга в Eclipse;
• Тесты JUnit поддерживаются как с фиктивными объектами, так и в размещенном режиме;
• Чистая интеграция с серверной частью Java (GWT-RPC);
• Относительно богатый набор виджетов пользовательского интерфейса с единообразным внешним видом;
• Наличие сторонних виджетов, каркасов, шаблонов и примеров (все еще ограничено и с длинным списком пожеланий);
• Поддержка Google обеспечивает более широкое признание / популярность и быстрое продвижение фреймворка;
• готовящаяся среда с 1.6+ и предстоящими версиями 2.0: (eventbus, обработчики событий, архитектура GUI с шаблоном MVP, оптимизация компилятора и т. Д.).

Answer 5

На мой взгляд, самое большое преимущество GWT - это возможность работать с одним языком программирования - Java со всеми его достоинствами.

Вместе с CSS они образуют мощную пару.

---

Другими словами, вы можете в основном забыть Javascript и HTML.

Является ли это преимуществом или нет, в основном зависит от ваших навыков и требований. У нас были такие же дебаты внутри, и в конце одна команда выбрала Wicket, а другую GWT.

Answer 6

Я новичок в GWT, но после некоторого изучения я обнаружил, что GWT «подходит» для моего нового проекта веб-приложения с его ориентацией на клиента, что позволяет мне чувствовать себя как программист для настольного приложения. Сегодня у нас есть высокопроизводительный клиент, готовый для запуска приложений на стороне клиента. Мое приложение может быть выполнено исключительно на Java, а Java-класс ООП дает возможность создать нашу собственную готовую к использованию среду для нашей команды.

Answer 7

Есть несколько других преимуществ калитки перед GWT, которые я нахожу.

1. GWT не будет работать с браузером, в котором отключен JavaScript. (это редко, хотя). Wicket всегда возвращается к обычным http-запросам, если javascript недоступен.
2. GWT-приложения - это одностраничные приложения, которые затрудняют создание закладок и использование вкладок браузера. С помощью калитки вы выбираете создание одностраничного или многостраничного приложения. Вы можете сделать страницы закладками, если хотите.
3. В GWT создание собственных компонентов не всегда легко. В калитке, поскольку вы работаете с необработанным html, css и даже javascript, создание пользовательских компонентов очень гибко. Вы даже можете легко обернуть существующий компонент jquery или dojo.
4. Поскольку GWT включает компиляцию java в javascript, вы можете использовать только классы java, которые были эмулированы компилятором GWT. Это может быть ограничением. Wicket - это фреймворк на стороне сервера, и вы можете использовать все, что вы хотите.
5. Работать с CSS и веб-дизайнерами намного проще с калиткой, чем GWT.

Answer 8

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

Answer 9

Я могу придумать несколько причин, по которым GWT является лучшим выбором, чем Wicket, для типичных бизнес-веб-приложений:

1. GWT от Google. Это может быть несправедливо, но наличие большой и уважаемой софтверной компании за инструментом - это огромное преимущество (безопаснее делать ставки на него, больше книг и онлайн-ресурсов, больше сторонней поддержки, лучшая поддержка IDE, ..).
2. Серверно-ориентированные веб-фреймворки, такие как Wicket, устарели. Современные веб-браузеры очень мощные и становятся все более и более, поэтому современная веб-инфраструктура должна помочь вам воспользоваться этим.
3. Кодирование непосредственно в HTML и Javascript никогда не может быть таким продуктивным, как кодирование в Java (по моему опыту, по крайней мере). Кроме того, существуют лучшие инструменты для кода Java (отладчики, статический анализ, модульное тестирование и покрытие кода и т. Д.).