Должен ли я использовать фреймворк Vaadin [закрыт]

https://stackoverflow.com/questions/1183801

19-09-2019
|

Вопрос

Я просто пытался поиграть с Фреймворк Vaadin и мне кажется, он очень прост в использовании.Плюс, что мне нравится в его фреймворке, так это то, что он построен поверх Веб-инструментарий Google (GWT).

Как вы думаете, должен ли я продолжать использовать этот фреймворк или лучше придерживаться GWT?

Решение

Привет.Отказ от ответственности: я работаю в компании, разрабатывающей Vaadin.

Vaadin использует GWT таким образом, что у него есть набор компонентов, предварительно скомпилированных в GWT.Конечно, вы можете дополнительно создать свои собственные компоненты, если захотите.Однако набор компонентов достаточно полный и зачастую его можно настроить под собственные нужды.Это означает, что вам не придется перекомпилировать код с Java в JavaScript каждый раз, когда вы меняете приложение.Вы просто объединяете уже имеющиеся компоненты вместе.

Платформа управляется сервером, поэтому вся логика обрабатывается на стороне сервера.Компонент состоит из двух частей: файла клиента и сервера.Клиентская часть — это всего лишь фиктивное «представление» компонента.Как только вы с ним взаимодействуете, он отправляет на сервер сообщение о том, что то или иное было нажато/написано/и т.д.Затем сервер решает, что следует сделать.Это сделано для повышения безопасности, поскольку вы не можете «взломать» логику, поскольку в javascript доступен только небольшой API, предназначенный для отправки запросов.В некоторых случаях это может быть небольшим компромиссом со скоростью приложения, но я не думаю, что это так уж плохо.Худшими ударами по скорости обычно являются обратные запросы к базе данных и тому подобное, что не имеет никакого отношения к выбору инфраструктуры пользовательского интерфейса.Медлительность демо-версий, как было предложено, может быть связана с тем, что вы находитесь далеко от сервера или в данный момент наблюдается большое количество пользователей.Попробуйте это в собственной среде, закройте окончательную версию вашего приложения и посмотрите, насколько хорошо оно работает.Есть несколько готовых приложений, которые вы можете просто развернуть и протестировать.

Я думаю, выбор сводится к тому, что вы пытаетесь сделать.Vaadin хорош для веб-приложений, поскольку вы можете легко создать обычное Java-приложение и создать для него динамический веб-интерфейс.Если вы делаете что-то большее, чем традиционный веб-сайт, где пользователи только просматривают страницу, а не активно взаимодействуют с ней, то Vaadin — не лучший вариант.Используйте другие бесплатные фреймворки, такие как рельсы, PHP-фреймворк и т. д.Я думаю, что вы больше создаете приложение, поскольку предполагаете, что сейчас используете GWT, так что Vaadin должен подойти.

Задавайте больше вопросов здесь, на форумах Vaadin или на irc-канале #vaadin @freenode, и, возможно, кто-нибудь сможет дать вам больше причин, почему или почему не следует использовать Vaadin.

Другие советы

После почти 1,5 лет разработки небольшого приложения GWT с использованием всех лучших практик, которые я узнал из последнего ввода-вывода Google, таких как MVP, EventBus, CommandPattern и т. д.Я говорю это от всего сердца:после нескольких дней попыток добиться того, чтобы все работало так, как хотела моя команда и клиент, как технически, так и визуально, даже после выпуска UiBinder, Vaadin пришел ко мне как свет в конце туннеля.

После написания почти тысячи шаблонных действий для шаблона команд, еще тысячи презентаторов и представлений, еще тысячи обработчиков событий и т. д.Не имея необходимости иметь дело почти с 75% этих классов и при этом сохраняя хороший подход к шаблонам (дополнение appfoundation), небольшие сетевые издержки приемлемы.С Vaadin «из коробки» вы получаете хорошие виджеты, разбиение на страницы, привязку данных и безупречную компоновку.Все это для чего?Еще немного потребления памяти на стороне сервера.

Я думаю, что могу сказать, что это приемлемо, потому что я не создаю следующий Facebook или что-то в этом роде.Я по-прежнему могу обслуживать тысячи одновременных пользователей на одном сервере среднего размера, сохраняя при этом передачу туда и обратно с низкой задержкой.

С помощью Vaadin я могу создать хорошее приложение, используя почти половину строк кода, и при этом оно будет выглядеть более законченным.:-)

!!ОБНОВЛЕНИЕ от 23 февраля 2011 г.:Я не могу не подчеркнуть, что следует учитывать ограничения каждой платформы.Ваадин ничем не отличается.Следует помнить, что Vaadin абстрагирует любую форму HTML или JavaScript.Кроме того, полученный HTML-код очень тяжелый, и вам придется самостоятельно позаботиться об изменениях состояния истории.Поэтому помните об этих накладных расходах при создании проекта.

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

Как и вы, я наткнулся на этот пост, когда размышлял, какой стек/фреймворк использовать для нового проекта.У меня был солидный опыт работы с Play!(хорошо, в Scala, но здесь это не имеет значения), но привлекательные виджеты и их плавная интеграция с серверной частью + разработка в стиле Swing действительно вызвали у меня интерес.Это было в конце 2010 года, и поскольку ответы убедили меня попробовать Vaadin, я решил вернуться и написать ответ, который мне бы хотелось прочитать здесь, особенно.поскольку вопрос актуален и сегодня.Тем временем Vaadin перешел с версии 6 на 7 с некоторыми заметными улучшениями, которые были необходимы. Играйте!перешел с версии 1 на версию 2, и я (+ небольшая команда) выполнил небольшое количество успешных проектов с обоими фреймворками.

Я думаю, что сравнение интересно, потому что оба фреймворка

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

Хвалить

Короче говоря, если идея переноса настольного приложения в браузер при полном абстрагировании от базового механизма HTTP-запросов/ответов кажется вам привлекательной, то Vaadin, вероятно, является вашим кандидатом на создание веб-приложения.Его Swing-подобный подход к программированию может быть легким делом для тех, кто больше всего счастлив вдали от низкоуровневого HTML и JavaScript.Новый запрос к вашему приложению действительно запускает новый экземпляр, а остальная часть потока зависит от вас и вашей логики.Ссылки возвращаются к старым добрым кнопкам для навигации, и вы можете свободно создавать свои макеты, используя множество встроенных шаблонов, без необходимости настраивать HTML или CSS.API, как правило, довольно последователен и, по общему признанию, хорошо документирован ( Книга Ваадина является обязательным к прочтению.Делайте это тщательно, так как многие вещи легко доступны, например.привязка ваших bean-компонентов к компонентам и валидаторам, ...).Виджеты имеют хорошую общую кросс-браузерную совместимость, что обеспечивает единообразное поведение вашего приложения для широкого круга клиентов.

Проверка в реальных условиях

Мы приятно провели время, разрабатывая и тестируя наши приложения Vaadin.Все стало яснее и детальнее, когда мы выпустили первую версию и начали собирать отзывы.Мы поняли, что на самом деле мы были предвзяты в некоторых фундаментальных аспектах, а именно:

В 201x большинство пользователей имели долгую историю использования Интернета, и лишь немногие из них фактически больше не используют настольные приложения.Ключевым моментом здесь является то, что браузеры стандартизировали взаимодействие с пользовательским интерфейсом с помощью гипертекстовых ссылок, кнопок «Назад», «Вперед» и «Обновить», вездесущих вкладок, а иногда и окон, а также основной идеи о том, что большинство действий запускают HTTP-запрос и будут ожидать ответа..Это неявный контракт, которому следуют веб-сайты и на основе которого они создаются.Поэтому мы не должны были удивляться, когда пользователи жаловались, что они не могут использовать кнопки «Назад/Вперед» так, как они привыкли, или что вкладки не работают должным образом.И мы согласились.Мы нарушили невидимый договор, связывающий пользователей и браузеры.Собственно, мы и сами были неявно не использовать наш браузер с приложением Vaadin так, как мы использовали его с любым другим веб-сайтом.Конечно, вы можете вернуться к вышеупомянутой книге и внимательно прочитать о воспроизведении веб-навигации с помощью фрагментов URL-адресов, и вы увидите, что на самом деле это сложнее, чем ожидалось. потому что приложения Vaadin сохраняют состояние.Более того, парадигмы MVC или MVP лишь частично навязываются разработчику, в отличие от Play!где другого выхода практически нет.Не относитесь к этому легкомысленно, но ваш мозг привык к яркому белому экрану, отображаемому на долю секунды после смены страницы.Когда пользователи нажимают кнопку и ожидают перехода на новую страницу, браузер подтверждает это, показывая песочные часы (или их варианты).При использовании AJAX запросы выполняются «за кулисами».Сегодня есть места, где небольшие, почти хирургические удары AJAX стали нормой, но крупных обновлений пользовательского интерфейса пока нет.
Приложения с сохранением состояния приносят свою долю проблем...и беда.Балансировка нагрузки (если вас это беспокоит) для одного сложнее.Концепция транзакции совершенно другая, поскольку сеансы Vaadin охватывают множество запросов и поэтому длительны в отличие от подхода, основанного на REST, но относительно недолговечны с точки зрения UX.Действительно, пользователи нередко возвращаются к форме, которую они начали. несколько часов назад чтобы закончить свою задачу.Теоретически это могло бы работать и с Vaadin, но вам придется поддерживать сеансы в течение долгого времени с постоянно заблокированной памятью и тщательно думать о том, будет ли это масштабироваться относительно.одновременные пользователи.

Страницами с сохранением состояния пользователям сложнее делиться, не говоря уже о создании закладок (при условии, что вы имели дело с фрагментами URL).
Наконец, у нас сложилось впечатление, что пользовательский интерфейс, как правило, работает более медленно, поскольку логика находится на сервере.Конечно, вы всегда можете создать виджет, загруженный клиентским JavaScript, чтобы сократить количество обращений туда и обратно, но вам неизбежно придется внести некоторые обновления пользовательского интерфейса на сервере.По моему опыту, JS уже довольно сложно интерпретировать и усложняет работу на мобильных устройствах (я знаю о TouchKit, но все же:Приложения HTML5 на мобильных устройствах меня просто не устраивают).Кроме того, имейте в виду, что поток пользовательского интерфейса активен после публикации запроса (т.действие пользователя на стороне клиента, аналогично получению обновлений пользовательского интерфейса) и будет доступен вам через различные прослушиватели.Однако обновление пользовательского интерфейса из фоновых потоков более сложное (например.проталкивание обновлений).Однако Vaadin 7 улучшил ситуацию в этом отношении, особенно с относительно более легкий HTML-код.Значительные улучшения реактивности пользовательского интерфейса были заметны даже при простом включении HTTP-сжатия.

Заключение

Поэтому мы остановились и задумались, что же такого привлекательного мы нашли в подходе Ваадина с самого начала.Первоначальная разработка прошла относительно гладко и принесла быстрые результаты, но переработка некоторых концепций с учетом ожиданий веб-UX дала нам сильное впечатление, что мы плывем против течения.Мы пришли к выводу, что соблазнительная идея абстрагироваться (скрыться?) от механизма HTTP-запросов/ответов оказалась обоюдоострым мечом, который обнажил реальное несоответствие импеданса между веб-приложениями и настольными приложениями.

Вместо того, чтобы притворяться, что Интернет — это еще один слой, мы твердо убеждены, что следует принять то, как он работает. и это начинается с создания URL-ориентированного приложения (согласно Rails/Django/Play).Вы, наверное, слышали, как кто-то сказал, что данные живут дольше, чем их применение.В настоящее время к данным обращаются через URL-ресурсы, поэтому можно с уверенностью сказать, что URL-адреса переживают данные.В конце концов, именно их люди добавляют в закладки, не так ли?Таким образом, базовое разделение задач должно применяться и на этом уровне.Вероятно, именно поэтому Интернет стал таким популярным.Поэтому мы пересмотрели наше приложение, чтобы структурировать его вокруг центрального контроллера, реагирующего на действия. в стиле Play сделано на разных путях ресурсов.

На данный момент мы поддерживаем наши приложения Vaadin, но из-за некоторых из этих ограничений и фундаментального изменения парадигмы мы не будем начинать с ним новые проекты.Однако снимаем шляпу перед командой, которая создала технически последовательную, целостную и хорошо документированную веб-инфраструктуру Java на 360°, требующую очень мало знаний о внутренней работе веб-страницы.С другой стороны, они даже подкрепляют свою структуру компанией, продающей консалтинговые услуги.Я благодарен за этот опыт и за то, как он заставил меня пересмотреть свои взгляды на веб-приложения.Я буду внимательно следить за его развитием, но нам определенно нужно больше контроля и детализации.

Будем надеяться, что однажды Vaadin освободится от всей архитектуры сервлетов, от которой зависит наличие собственного HTTP-сервера.Еще лучше было бы, чтобы дизайн MVC был более глубоко укоренен в структуре.Но это маловероятно в обозримом будущем, поскольку он, похоже, нашел прибыльную нишу среди опытных корпоративных Java-горилл, которые доверяют только EE.Сиять на.

ТЛ;ДР:Я думаю, что Ваадин не понимает, что такое веб-приложения и, что более важно, как они должны себя вести.Пришло время, когда программисты освоили Интернет и то, как пользователи с ним взаимодействуют (т.кнопка «Назад», кнопка перезагрузки, вкладки и закладки).Чем ближе веб-приложение соответствует HTTP-запросам и семантике (глаголам), тем больше вероятность того, что оно будет соответствовать ожиданиям пользователей.И это ключевой момент.

РЕДАКТИРОВАТЬ:Если у вас есть опыт работы с Python, я настоятельно рекомендую попробовать Flask, чтобы получить представление о программировании веб-приложений на основе URL-адресов и REST.

РЕДАКТИРОВАТЬ 2:Если по какой-либо причине вы чувствуете, что вам необходимо использовать полнофункциональную структуру, подобную Vaadin, попробуйте Meteor.Это платформа на основе JavaScript (как внешняя, так и внутренняя), которая работает на Node.js с асинхронной связью, происходящей через WebSocket (таким образом, меньшая задержка, чем запрос/ответ), и по умолчанию является реактивной.Ряд вещей, которые мне не нравятся в Ваадине, были решены в Метеоре.Например, логика обновлений пользовательского интерфейса выполняется на клиенте, что делает его гораздо более отзывчивым, чем в Vaadin.Люди в сообществах JavaScript и Java не сильно пересекаются, но когда я впервые услышал об этом, меня сразу поразила параллель с Vaadin.В настоящее время он пользуется большой популярностью в сообществе по причинам, схожим с теми, которые сделали Ваадина популярным, т.е.возможность создавать настольные веб-приложения.Обязательно попробуйте, если вы также поняли, что Java не занимает большого места в картине будущих веб-приложений, или если вы устали от этих долгих циклов развертывания, когда все, что вам нужно, это нажать «Обновить».Но подумайте дважды, прежде чем привязывать все приложение к одной библиотеке.

Обычно разговоры о Vaadin касаются набора виджетов и вопросов связи между клиентом и сервером.

Но, на мой взгляд, это упускает из виду самый важный (возможно, революционный) аспект Ваадина:он полностью устраняет задачу проектирования и реализации связи клиент-сервер, которая обычно требуется для приложений AJAX («A» и «X» в AJAX).

С Vaadin вы можете полностью забыть о DTO (объектах передачи данных), проблемах безопасности на основе протоколов, исключениях отложенной загрузки Hibernate и т. д.

В каком-то смысле вы просто пишете обычное старое настольное приложение Java Swing, только используете другой набор инструментов пользовательского интерфейса, чем Swing.

По моему опыту, GWT требует много шаблонного кода и медленный при создании сложного и насыщенного пользовательского интерфейса.Обычно мы имеем дело с довольно сложными моделями приложений, которые содержат множество постоянных объектов домена.Чтобы передать все эти данные клиенту, вам потребуется ввести отдельную клиентскую модель и обеспечить механизм преобразования данных.Для этой цели мы использовали Dozer, и для сопоставления каждого поля, создания пользовательских конвертеров и тестирования всего этого требуется много времени.

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

Вадин выглядит очень дружелюбно к разработчику :) Но я немного опасаюсь «массированной AJAX-атаки» на сервер.У меня есть опыт работы с ZK, и мы часто сталкивались с проблемами производительности, когда тривиальная операция в пользовательском интерфейсе работает медленно, поскольку требует связи с сервером.

Wicket — еще один хороший фреймворк, но он больше подходит для веб-сайтов.Может работать с AJAX и без него, индексироваться поисковыми системами.И самое интересное, что он имеет чистый HTML-код — никаких пользовательских тегов, никаких управляющих структур, строгое разделение задач и только конкретные имена wicketid для компонентов.

Во многом это зависит от ваших потребностей:

Если вам нужно супер быстрое и простое приложение — используйте GWT и задействуйте ресурсы клиента.
Если ваше приложение довольно сложное, то Vaadin будет лучшим вариантом.
Если ваше приложение является общедоступным и вам нужна возможность индексировать его для SEO, выберите Wicket.

Все дело в том, что для серьезного развития нельзя ни о чем забывать, а тем более о дтосе..Я отказываюсь от концепции шва и пользовательского интерфейса на стороне сервера только потому, что хочу более точного контроля над тем, что происходит в сети..Проблема vaadin для меня именно в том, что у меня есть состояние на стороне сервера..

Были «опасения» по поводу использования Wicket сеансов для управления состояниями компонентов и масштабируемости, аналогичные аргументам в отношении Vaadin и обработки на стороне сервера.За последние 10 лет я узнал, что сообщество Java обычно ошибается в том, как измерить потенциал веб-фреймворка (помимо прочего).От JSF до Grails для запуска рабочего приложения обычно требуется пара сотен ГБ памяти и как минимум дюжина jar-файлов с открытым исходным кодом с перекрывающимися и неэффективными функциями.Посмотрите вокруг, и вы увидите, что большинство компаний, занимающихся веб-хостингом, не предлагают практичный вариант Java из-за неустойчивого пути, по которому Java-технологии прошли для веб-фреймворков.GWT 2.1 по-прежнему сложно использовать из-за скорости компиляции, и он только начинает серьезно относиться к MVP и таблицам данных, которые должны были быть там с самого начала.Мне нравится Уикет, но Ваадин выглядит многообещающе...но зная, как работают Java-фреймворки, я уверен, что в какой-то момент они выстрелят себе в ногу, но я сомневаюсь, что это произойдет из-за тяжелой обработки на стороне сервера.

Я бы сказал, что для создания красивых пользовательских интерфейсов это лучший вариант.Плюс это очень хорошо документировано.

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

Мне нравится это в сочетании с гибернацией, чтобы избавиться от всей этой скуки с базой данных.

Плюс - простота развертывания (с Tomcat вы можете просто загрузить один файл .WAR через веб-интерфейс, проще и быть не может)

Также стоит рассмотреть Апач Калитка как сильная альтернатива компонентно-ориентированным платформам веб-интерфейса Java.Ваадин звучит великолепно, и я не хочу отвлекаться от этой дискуссии, но выбор — это хорошо.На главной странице есть несколько примеров со ссылками на исходники, и еще больше на сайте WicketStuff, а отличная книга Мэннинга представляет собой отличную стороннюю документацию.

взгляните на демо-сборку Vaadin с Maven:http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

Я думал, что Wicket — это путь вперед, пока не попытался заставить его работать эффективно и не впал в депрессию (шутка).Затем я переключился на GWT, который выглядел великолепно, но нужно написать ооочень много шаблонного кода, а документация не так уж и хороша...-> Свет исходил от Ваадина:простой, работоспособный, ошибок пока нет...!!!

В нашей компании, которая в основном является крупным подразделением Java SW (среди прочего), нам представился шанс создать новый веб-продукт.Это был набор продуктов, и над ним работало много команд в трех странах.Когда дело дошло до нашей команды, у меня был выбор в пользу использования Vaadin с целью использования нашего опыта разработки на Java.Я поискал в Google, чтобы принять решение.Я тоже прочитал этот пост;Однако я предпочел не использовать Vaadin, хотя многие другие команды выбрали Vadin.Ниже приведены причины из письма, которое я отправил в то время, прежде чем приступить к работе с продуктом (в Vaadin или нет).Это с моей личной точки зрения, и недоверие к фреймворкам вообще всегда присуще мне в той или иной степени.Поэтому просто хотел предложить читателю еще один взгляд на этот вопрос.

Что ж, мы отправились на учебу, изучая HTML, CSS, CSS-селекторы, замечательный язык JavaScript и библиотеки JS, jQuery и YUI, и вовремя создали веб-продукт с полным графическим интерфейсом и соответствием производительности;и я лично доволен, и команда довольна, и пользователи тоже.

Другие команды, которые пошли по пути Vaadin, также создали свои продукты вовремя и, я думаю, не менее счастливы.(Только они не знают, какой радости от JavaScript им не хватает :)).

Как кто-то сказал, все абстракции - это дырявые абстракции, и когда им пришлось перейти с Vaadin 6 на Vaadin 7, им пришлось проделать довольно большую переделку, и это заняло больше времени, чем кто-либо думал;хотя, конечно, им удалось его измельчить и отшлифовать;Тем не менее, из-за этого произошла небольшая задержка.Также я предполагаю, что была какая-то проблема с аддоном InvientCharts, который не поддерживал Vaadin 7, из-за чего командам пришлось купить (за $ $) соответствующий аддон Vaadin Charts и изменить его....

В Ваадин или Нет

С Vaadin кажется, что базовые JavaScript, HTML и CSS динамически генерируются из приложения типа Java Swing.С предвзятой и, вероятно, глупой пуристской точки зрения, такой слоган "Я сгенерирую код для вас" не придает дизайну хорошего запаха.Если вам не нужна абстракция, зачем связываться с еще одним фреймворком.Как и в случае с любым фреймворком для генерации кода, он должен лучше всего подходить для абстракции, которую имел в виду Ваадин, но не очень гибкий;Я считаю, что если мы занимаемся веб-технологиями, то лучше всего делать это с помощью инструментов и языков, из которых эта технология возникла, а именно HTML , CSS и JavaScript / JavaScript библиотеки, а не полагаться на другой уровень абстракции – фреймворк Vaadin.Опытному разработчику GWT или Vaadin это может показаться наивным, поскольку я предполагаю, что компиляторы Google генерируют наиболее оптимизированный JavaScript, чем закодированный вами вручную, , помогает лучше управлять кодом между несколькими командами и т.д. (Но в основном при разработке довольно крупных веб-приложений), повышает производительность разработчиков, упрощает отладку и т.д.Однако написание компонентов на Java для Vaadin, а затем автоматическое преобразование в JS, я считаю неправильным, поскольку многие из наших разработчиков никогда не изучат очень важный язык программирования – JavaScript для веб-разработки (и быстро набирающий обороты на стороне сервера – Node.js ).Полагаясь на фреймворки, чтобы правильно использовать свой JavaScript, вы никогда не преуспеете в этом языке.Я думаю , что для компании , ориентированной на продукт , важно не понаслышке изучить язык Интернета .Как кто-то прокомментировал, Java стала похожа на COBOL прошлого года, и для повышения квалификации крайне важно изучать другие важные языки, такие как JavaScript.Однако, поработав в JS в течение того небольшого времени, которое у меня есть, я заметил, что если мы кодируем с использованием некоторой дисциплины (шаблона модуля) , тестируем всю логику - JavaScript unit – JsTestDriver и запускаем JSHint , это довольно мощный язык для работы, и производительность становится выше, чем Java, после его изучения.Также большинство важных компонентов , например OpenLayers , написаны на JS , и если вам нужно расширить их или оптимально работать с ними, вам необходимо знать JavaScript или, если уж на то пошло, мощные библиотеки, такие как D3.js Итак, вкратце, хотя в использовании Vaadin и фреймворков есть много преимуществ, в долгосрочной перспективе, возможно, использование JavaScript важно?

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

Очень мало проблем.Единственное, что сейчас происходит, так это то, что клиент настаивает на использовании IE 7 (не спрашивайте), а некоторые из более интересных вещей не работают на 100%. в аддон-компоненте (график).

Кстати, я тоже не работаю на Ваадина :-)

Я пробовал и Wicket, и Vaadin, и если вы действительно попробуете оба в течение некоторого времени, через месяц вы поймете, что Vaadin — это лучший вариант, а не Wicket, и точка.- Дирадж Дж.

Мы просмотрели Wicket, где я работаю, но обнаружили вместо 9 000 файлов их может быть более 30 000.У нас есть около 1000 экранов с нашим основным приложением финансовых услуг, и хотя Wicket выглядит великолепно, преобразовать наш код Struts 1.3 в Wicket чрезвычайно сложно.Наш архитектор выполнил POC-проект, и всего к 3 экранам добавилось несколько сотен классов (многие из них предназначены для повторного использования).Также сложно создать прототип экрана с помощью Wicket, поскольку ваш HTML-код должен соответствовать коду Java, и наоборот.

Ваадин выглядит многообещающе, но команде будет сложно его продать.

P.S.Независимо от того, насколько хорош фреймворк, никто не сможет его изучить, если он не будет использоваться в отрасли.Wicket существует уже некоторое время, но очень немногие компании используют его.Большинство разработчиков, с которыми я общаюсь, озабочены изучением нового фреймворка, который бесполезен в резюме.

Ключевым моментом является то, что Vaadin использует дизайн, подобный Swing, и мне помогает то, что я начал работать с Java, используя Swing.

Я использовал Vaadin для разработки советника по подаркам в компании, в которой работаю (не Vaadin;).

Vaadin позволяет создавать настоящие компонентные веб-приложения типа Swing.

Если вас беспокоит обмен данными между клиентом и сервером для каждого клика, я хочу сказать следующее:Я создал кнопку наведения курсора мыши, которая меняет внешний вид кнопки при наведении курсора мыши.Для этого фреймворк должен дойти до сервера и обратно.И он работает достаточно быстро, имхо.Видеть http://www.cadeau.nl/софи чтобы проверить, что я имею в виду.

Мне нравится Vaadin, он соответствует моим потребностям и упрощает веб-разработку.

С уважением, Роб.

Я начал работать с Vaadin всего два дня назад и смог создать небольшое CRUD-приложение на OSGi с модульностью, привязкой данных и службами OSGi для обеспечения устойчивости.Очень приятно то, что мой полный пользовательский интерфейс состоит всего из 118 строк кода и поддерживает полные операции CRUD для простой структуры Java-компонента.

Также приятно, что Vaadin прекрасно работает в OSGi.Это уже пакет, и я нашел небольшой мост от Нила Бартлета, который делает vaadin чрезвычайно простым в использовании в OSGi.

Видеть Пример списка задач Vaadin

Я не против использования состояний на стороне сервера.Он служит своей цели.Сегодня, благодаря облачным вычислениям, хранилище и пропускная способность становятся дешевыми.Но да, я понимаю вашу точку зрения с точки зрения хорошего дизайна, особенно если вы хотите RESTify свое приложение.Но я считаю, что в отношении Ваадина и ему подобных больше плюсов, чем минусов.Одна важная вещь: вам не нужно сильно настраивать свои веб-приложения для конкретного браузера, назовем его IE, для тонкостей Javascript/CSS - особенно если вы, как я, ориентированы на серверную часть.Все ваши веб-приложения становятся совместимыми в браузере, и вам не о чем беспокоиться.Помните, что время разработчиков обходится дороже, чем хранилище и пропускная способность.Это мое мнение."="

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow