Помимо аргумента простоты Wicket (то есть Wicket - более простая система IMHO) и отзывчивости GWT в клиенте (состояние клиентской стороны GWT и JavaScript - потенциально сложный код на стороне клиента) и большой потенциал GWT для масштабирования, что такое аргумент для использования GWT над Wicket?Теперь с GWT 2, каковы преимущества над калитки и аналогичным образом?
Лично я много сделал для разработки Wicket, но только недавно взглянул на GWT.
По моему мнению, самое большое преимущество GWT - это позволить вам работать с одним языком программирования - Java, со всей добротой, которую он приносит.
Вместе с CSS они образуют мощную пару.
Иными словами, вы можете основном забыть Javascript и HTML.
Независимо от того, какое преимущество или нет, в основном зависит от ваших навыков и требований. У нас были такие же дебаты внутри, и в итоге одна команда выбрала Wicket и еще одну GWT.
Я могу назвать несколько причин, почему GWT является лучшим выбором, чем калиткой, для типичных бизнес веб-приложений:
Я не согласен с GWT "огромным" преимуществом.Есть много крупных компаний, которые выпускают дрянные фреймворки (например, в случае с JSF). Конечно, Google в целом вносит свой вклад в хорошие рамки, но в конце концов, это более важно, кто на самом деле работал над этим, а не с компанией, в которой они работали. – Eelco
На самом деле, при чтении двух других моментов, я подозреваю, что вы мало знаете о Wicket и для чего он предназначен. – Eelco
«Серверные веб-фреймворки, такие как Wicket, устарели». Вы когда-нибудь пытались создать веб-приложение RESTful с HTML 4 и JavaScript (написано с GWT или нет)? HTML 5 изменит некоторые вещи, которые облегчат (или, возможно, в некоторых случаях). Кабинет сэкономит вам массу головных болей. – deamon
Это несправедливо сравнивать GWT с калитки (или аналогичным образом), поскольку они действительно происходят из 2 разных лагерей. Первый - это основа для создания интерфейсных приложений JavaScript, а вторая - классическая инфраструктура веб-приложений Java.
Итак, пункты ниже не такие, как GWT vs.Калитка, а общий список, который был составлен, когда мы решили использовать GWT для продвинутых веб-приложений JavaScript/AJAX:
Гениальность GWT заключается в том, что вы работаете исключительно с java. Они отлично справились с RPC, сделав его почти прозрачным для программиста. Много раз вы чувствуете, что кодируете больше, чем настольное приложение, а не приложение с действительно определенной клиентской и серверной стороной.
Это очень похоже на цели калитки. – ireddick
Да, это именно то, что он чувствует при написании приложений с помощью Wicket - всем знакомым и легкостью написания настольного приложения. Преимущество Wicket над GWT IMHO заключается в том, что, как и в мире разработки настольных систем, привязка пользовательского интерфейса к объектам модели домена в Wicket достигается стандартными вызовами методов и ссылками на объекты. В GWT при привязке вашего пользовательского интерфейса к объектам модели домена вам нужно лечь в постель с очень странным партнером по постели: «сортировать объекты» - это нормально, если вам нравится делать что-то трудное. – Volksman
Преимущества в том, что GWT - это инструмент для создания клиента на основе javascript, поэтому он лучше всего подходит, если вы хотите использовать javascript-клиент.
Калитки сосредоточены на сервере, и, хотя он делает его довольно простым для встраивания javascript в страницы без гражданства, управление положением на стороне сервера является более естественным.
Следует отметить, что архитектура отличается от других.
С GWT ваша архитектура превращается в клиент-сервер, толстый клиент в браузере, вызывая вызовы на «процедуры» (услуги) на сервер, отправляя и получая данные.
С Wicket (и другие стороны сервера-ориентированными структурами компонентов, такими как JSF и Tapestry), архитектурой является более «традиционным» 3-слойной один, и то, что посылается и принимается являются страниц или фрагментов страниц, а не чистых данных.
В то время как вы можете смешать оба, чтобы адаптироваться к другой архитектуре, это просто не очень естественно.
Люди склонны сосредотачиваться на «более удобном в использовании» (который является полностью субъективным, в зависимости от вашего фона) или «который более красив и имеет больше компонентов», но нельзя недооценивать архитектурные различия, которые влияет на подход, который вы должны предпринять для решения таких аспектов, как безопасность и масштабируемость.
Я думаю, что одна общая проблема заключается в том, что люди учитывают масштабируемость, но переоценивают свои требования к веб-уровню и не замечают аспектов безопасности. По крайней мере, мой опыт. – Eelco
Я согласен с тем, что большинство людей просто не знают, как справиться с безопасностью, и полагают, что это волшебство «произойдет» с некоторой конфигурацией где-нибудь. Что касается масштабируемости, я думаю, что обе технологии будут одинаково хорошо работать с масштабируемостью «не-facebook», но подходы будут разными. И использование неправильного подхода приведет к столь же уродливым проблемам. – tetsuo
Забавно, как изменилось определение «традиционный» со временем. Много лет назад это означало бы подход клиент-сервер (толстый клиент). До этого это был немой терминал и сервер (тонкий клиент). Теперь, когда мы вернулись к толстым клиентам с JavaScript, мне интересно, как будет выглядеть следующая архитектура тонкого клиента. –
Я принимал участие в проекте на основе GWT в течение последних нескольких месяцев. Я был, будучи частью команды разработки Wicket в течение многих лет, с нетерпением ожидая перемен и ожидал многого от GWT (который я всегда рекламировал как еще одну отличную платформу Java).
Честно говоря, я разочарован, когда дело доходит до работы с GWT. Я чувствую - вся моя команда на самом деле - эта производительность сильно пострадала. Теоретически GWT велик. Но когда вы учитываете причуды и ограничения структуры, посредственные сообщения об ошибках (особенно когда речь идет о ошибках сериализации), длинные сроки компиляции (где-то между 3-10 минутами и нашим проектом еще не так уж и велики) тот факт, что, когда все сказано и сделано, вам все равно нужно протестировать все браузеры и найти настройки и обходные пути, тот факт, что он производит огромную начальную загрузку (почти МБ, который мы сокращаем постепенно, но с большим количеством усилий) и т. д., и т. д., я считаю, что Wicket намного проще и быстрее работать.
Я не ненавижу работать с GWT. Это все еще намного лучше, чем большинство Java-фреймворков. Просто я ожидал гораздо большего от работы с ним; Я даже ожидал, что это будет возможно лучше, чем Wicket. Но, в конце концов, это просто не имхо. Надеюсь, GWT 2.0 улучшит многие вещи, и, надеюсь, некоторые из приколов плагина Eclipse скоро будут исправлены.
Имея некоторый (в основном косвенный) опыт работы с GWT 2.0 и UiBinder, я могу подтвердить, что все стало лучше. Я все еще чувствую, что вам нужно много сантехнического кода, чтобы сделать все, что не сложно сделать, используя JavaScript. – Eelco
Одним из преимуществ Wicket over GWT является то, что Wicket может обрабатывать случай, когда вы хотите предоставить резерв для клиентов, у которых нет Javascript. GWT - это целая борода для Javascript, Wicket позволяет грациозно деградировать.
+1 для грамотной деградации без включенного Javascript. –
Есть несколько других преимуществ калитки над GWT, которые я нахожу.
Wicket не всегда возвращается к нормальному HTTP, Javascript недоступен. Только компоненты, предназначенные для резервного копирования. – Jesse
Я новичок в GWT, но после некоторого исследования я нашел, что GWT «подходит» для моего нового проекта веб-приложения для его клиентского фокуса, который заставляет меня чувствовать себя как кодирование настольного приложения. Сегодня у нас есть высокопроизводительный клиент, готовый запустить приложение на стороне клиента. Мое приложение может быть выполнено исключительно на Java, а класс Java OOP дает возможность создать собственную готовую к использованию инфраструктуру для нашей команды.
Вы можете сделать почти такой же аргумент для кодирования в Wicket ..? – Tim
__No__, вы не могли. Можете ли вы написать богатые клиентские приложения в Wicket без Javascript? –
Хороший вопрос. Можете ли вы также написать GWT с помощью Scala? –