Я просто попытался сыграть с Vaadin Framework и мне кажется очень простым в использовании. Плюс, что мне нравится в его структуре, так это то, что он построен поверх Google Web Toolkit (GWT).
Как вы думаете, следует ли продолжать использовать эту структуру или лучше придерживаться GWT?
Эй. Как отказ от ответственности, я работаю в компании, разрабатывающей Vaadin.
Vaadin использует GWT таким образом, что он имеет набор компонентов, предварительно скомпилированных в GWT. Вы можете, конечно, дополнительно создать свои собственные компоненты, если захотите. Однако набор компонентов достаточно полный и часто может быть настроен для вашей собственной потребности. Это означает, что вам не нужно перекомпилировать код с Java на JavaScript при каждом изменении вашего приложения. Вы просто объединяете уже имеющиеся компоненты вместе.
Структура управляется сервером, поэтому вся логика обрабатывается на стороне сервера. Компоненты имеют две части: клиентский и серверный. Клиентская сторона - это просто фиктивный "вид" для компонента. После того как вы взаимодействуете с ним, он отправляет на сервер сообщение о том, что то или это было нажато/записано/и т.д. Затем сервер решает, что нужно сделать. Это для повышения безопасности, потому что вы не можете "взломать" логику, поскольку в javascript доступен только небольшой API, предназначенный для отправки запросов. Это может быть в некоторых случаях небольшим компромиссом со скоростью приложения, но я не думаю, что это так плохо. Худшие удары по скорости - это, как правило, db query round-trip и такие, которые не имеют никакого отношения к выбору структуры пользовательского интерфейса. Вялость демонстраций, как было предложено, может быть вызвана тем, что вы далеки от сервера или на данный момент существует высокий пользовательский удар. Попробуйте в собственной среде, закройте окончательное приложение вашего приложения, чтобы узнать, насколько он хорошо работает. Есть несколько готовых приложений, которые вы можете просто развернуть для проверки.
Я думаю, что выбор сводится к тому, что вы пытаетесь сделать. Vaadin хорош для веб-приложений, так как вы можете создать обычное Java-приложение и легко настроить динамический веб-интерфейс. Если вы делаете что-то более традиционного веб-сайта, где пользователи просматривают только страницу - более активно взаимодействуют с ней, то Ваадин - это не лучший способ пойти. Пойдите с некоторыми другими свободными структурами, такими как rails или php framework и т.д. Я думаю, что вы больше выполняете приложение, так как вы предлагаете использовать GWT сейчас, поэтому Ваадин должен быть хорошим.
Задайте больше вопросов здесь, на форумах Vaadin или на канале irС#vaadin @freenode, и, возможно, кто-то может дать вам больше причин, почему или почему не использовать Vaadin.
После почти 1,5-летнего развития не столь огромного приложения GWT, используя все лучшие практики, которые я узнал из последних Google I/O, таких как MVP, EventBus, CommandPattern и т.д. Я говорю это от всего сердца: после проводя дни, пытаясь понять, как моя команда и клиент хотели как технически, так и визуально, даже после выпуска UiBinder, Ваадин пришел ко мне, как свет в конце туннеля.
После написания почти тысячи шаблонных действий для командного шаблона, еще тысячи презентаторов и просмотров и еще тысяча обработчиков событий и т.д. Не имея дело с почти 75% этих классов и по-прежнему поддерживая хороший подход к шаблону (appfoundation add- on), допустимы небольшие сетевые накладные расходы. С Vaadin, готовым к работе, вы получаете хорошие виджеты, пейджинг, привязку данных, безупречную компоновку. Все это для чего? Некоторое потребление памяти на стороне сервера.
Думаю, я могу сказать, что это приемлемо, потому что я не строю следующий Facebook или что-то в этом роде. Я все еще могу обрабатывать тысячи одновременных пользователей на один средний сервер и, тем не менее, поддерживать кругооборот с низкой задержкой.
С Vaadin я могу создать приятное приложение с почти половиной строк кода, и все же приложение кажется более полным.: -)
!! ОБНОВЛЕНИЕ 23 февраля 2011 года: я не могу подчеркнуть, как следует понимать ограничения каждой рамки. Ваадин ничем не отличается. Следует помнить, что Ваадин абстрагирует любую форму HTML или JavaScript. Кроме того, полученный HTML очень тяжелый, и вы должны сами позаботиться об изменениях состояния истории. Поэтому, когда вы строите проект, имейте в виду эти накладные расходы.
Отказ от ответственности. Я не связан ни с одной из библиотек, упомянутых ниже, но знаю, что я хорошо их знаю.
Как и вы, я наткнулся на этот пост, размышляя над тем, какой стек/фрейм использовать для нового проекта. У меня был отличный опыт в Play! (хорошо, в Scala, но это не имеет значения здесь), но убедительные виджеты и их плавная интеграция с серверной стороной + разработка Swing как раз и вызвала мой интерес. Это было в конце 2010 года, и, поскольку ответы убедили меня попробовать Ваадина, я решил вернуться и написать ответ, который мне хотелось бы прочитать здесь, особенно. поскольку этот вопрос по-прежнему актуальен и сегодня. Между тем, Ваадин перешел от версии 6 к 7 с несколькими заметными улучшениями, которые были необходимы, Play! пошел от версии 1 до 2, и я (+ небольшая команда) завершил небольшое количество успешных проектов с обеих сторон.
Я думаю, что сравнение интересно, потому что обе структуры
Хвала
В одном предложении, если вы обнаружите идею переноса настольного приложения в браузер, будучи полностью абстрагированным от основного механизма запроса/ответа HTTP, то Vaadin, вероятно, является вашим кандидатом на создание веб-приложения. Его подход Swing к программированию может быть легким для тех, кто счастлив от низкого уровня HTML и JavaScript. Новый запрос к вашему приложению действительно запускает новый экземпляр, а остальная часть потока зависит от вас и вашей логики. Ссылки возвращаются к старым старым кнопкам для навигации, и вы можете составить свои макеты с помощью множества встроенных шаблонов, не требуя при этом настройки HTML или CSS. API, как правило, довольно согласован и, по общему признанию, хорошо документирован (Книга Ваадина является обязательным чтением. Сделайте это тщательно, поскольку многие вещи легко доступны, например, привязка вашего beans компонентам и валидаторам,...). Виджеты имеют хорошую общую совместимость между браузерами, что обеспечивает последовательное поведение вашего приложения по широкому кругу клиентов.
Проверка реальности
У нас было приятное время для разработки и тестирования наших приложений Vaadin. Все стало более ясным и более тонким, когда мы выпустили первую версию и начали собирать отзывы. Мы поняли, что на самом деле мы были пристрастны довольно фундаментальными способами, а именно:
В 201x году большинство пользователей пользовались большой популярностью в Интернете, и немногие из них практически не используют настольные приложения. Ключевым моментом здесь является то, что браузеры стандартизировали взаимодействие UX с гипертекстовыми ссылками, обратной связью, кнопкой переадресации и перезагрузки, вездесущими вкладками и иногда окнами, а также основной идеей, что большинство действий запускают HTTP-запрос и будут ждать ответа. Это неявный контракт, который веб-сайты придерживаются и вокруг которых они построены. Поэтому мы не должны были удивляться, когда пользователи жаловались, что они не могут использовать кнопки назад/вперед, как они привыкли, или что вкладки не работают ожидаемым образом. И мы согласились. Мы нарушили невидимый контракт, связывающий пользователей и браузеры. Собственно, мы сами неявно не использовали наш браузер с приложением Vaadin так, как мы его использовали с любым другим сайтом. Конечно, вы можете вернуться к вышеупомянутой книге и внимательно прочитать о повторном использовании опыта веб-навигации с фрагментами URL-адресов, и вы увидите, что это на самом деле более активное участие, чем ожидалось , потому что приложения Vaadin имеют состояние. Более того, парадигмы MVC или MVP накладываются только на разработчика, в отличие от Play! где практически нет другого варианта. Не принимайте это легко, но ваш мозг используется на ярком белом экране, отображаемом на долю секунды после смены страницы. Когда пользователи нажимают и ожидают, что будут взяты новые страницы, браузер подтверждает, показывая песочные часы (или их варианты). С AJAX запросы размещаются за кулисами. Сегодня есть места, где небольшие, почти хирургические удары AJAX стали нормой, но не для крупных обновлений пользовательского интерфейса.
Приложения с полномочиями приносят свою долю проблем... и неприятности. Балансировка нагрузки (если вы заинтересованы) для одного более сложна. Концепция транзакции совершенно различна, поскольку сеансы Vaadin охватывают многие запросы и поэтому долго контрастируют с основанными на REST подходами, но относительно недолговечны с точки зрения UX. В самом деле, это не редкость для пользователей вернуться к форме, которую они начали несколько часов назад, чтобы закончить свою задачу. Это теоретически может работать и с Ваадином, но вы должны держать сеансы живыми в течение долгого времени, с блокировкой памяти и все время тщательно продумывать, что это будет масштабировать w.r.t. одновременных пользователей.
Учетные страницы также труднее для пользователей, а тем более для закладки (при условии, что вы имеете дело с фрагментами URL-адресов).
Наконец, мы разделяем впечатление, что пользовательский интерфейс обычно более вялый с логикой, находящейся на сервере. Конечно, вы всегда можете создать виджет, загруженный клиентским JavaScript, чтобы обрезать количество раундов, но вам неизбежно придется сделать некоторые обновления пользовательского интерфейса на сервере. JS уже довольно тяжело интерпретировать в моем опыте и делает для меньшего опыта работы на мобильных устройствах (я знаю TouchKit, но все же: приложения HTML5 на мобильных устройствах просто не режут для меня). Кроме того, имейте в виду, что поток пользовательского интерфейса активен после того, как запрос отправлен (т.е. Действие пользователя на стороне клиента, похожее на вытягивание обновлений пользовательского интерфейса) и будет доступно вам через различные слушатели. Тем не менее, обновление пользовательского интерфейса из фоновых потоков является более сложным (например, нажатие обновлений). Ваадин 7 улучшил ситуацию в этом отношении, особенно с относительно легким HTML-кодом. Значительные улучшения реактивности UI были заметны, просто включив сжатие HTTP.
Заключение
Итак, мы остановились и задались вопросом, что мы нашли настолько привлекательным в подходе Ваадин, чтобы начать с этого. Первоначальная разработка была относительно гладкой, давая быстрые результаты, но переработка некоторых концепций для удовлетворения ожиданий в сети UX дала нам сильное впечатление от плавания против прилива. Мы пришли к выводу, что соблазнительная идея абстрагироваться (скрытая?) От механизма запроса/ответа HTTP показала обоюдоострый меч, который раскрыл реальное несоответствие импеданса между веб-приложениями и настольными приложениями.
Вместо того, чтобы притворяться, что веб-страница является еще одним слоем, мы твердо решили, что нужно использовать способ , и это начинается с использования URL-ориентированного приложения (как наложено Rails/Django/Играть). Вы, наверное, слышали, как кто-то сказал, что данные ожидают применения. В настоящее время данные ссылаются на ресурсы URL, поэтому можно с уверенностью сказать, что URL-адреса перехватывают данные. В конце концов, это то, что люди закладывают, не так ли? Таким образом, основное разделение проблем должно также применяться на этом уровне. Вероятно, именно поэтому сеть стала настолько популярной в первую очередь. Поэтому мы пересмотрели наше приложение, чтобы структурировать его больше вокруг центрального контроллера, реагирующего на действия à la Play, выполненные на разных путях ресурсов.
Пока мы поддерживаем наши приложения Vaadin, но из-за некоторых из этих ограничений и фундаментального сдвига парадигмы мы не будем начинать с ним новые проекты. Однако шляпа уходит в команду, которая построила технически согласованную, сплоченную и хорошо документированную веб-инфраструктуру на 360 ° Java, требующую очень мало знания внутренней работы в Интернете. С другой стороны, они даже поддерживают свою структуру с компанией, продающей консалтинговые услуги. Я благодарен за опыт и за то, как он заставил меня переоценить мои взгляды на веб-приложения. Я буду внимательно следить за его эволюцией, но мы определенно нуждаемся в большем контроле и детализации.
Надеюсь, в один прекрасный день Ваадин освободится от всей архитектуры сервлета, на которой он будет иметь свой собственный HTTP-сервер. Еще лучше будет проект MVC, более глубоко внедренный в структуру. Но это несколько маловероятно в обозримом будущем, поскольку оно, похоже, нашло прибыльную нишу среди опытных корпоративных Java-горилл, которые только клянутся EE. Сияние.
TL; DR: Я думаю, что Ваадин не понимает, что такое webapps и что еще важнее, как они должны себя вести. Это о программистах времени, которые охватили веб-интерфейс и как пользователи взаимодействуют с ним (например, кнопка "Назад", кнопка перезагрузки, вкладки и закладки). Чем ближе веб-приложение привязывается к HTTP-запросам и семантике (глаголам), тем больше вероятность соответствовать ожиданиям пользователей. И этот ключ.
ИЗМЕНИТЬ: Если у вас есть опыт Python, я настоятельно рекомендую попробовать Flask также, чтобы получить вкус ориентированного на URL, программирования веб-приложений на основе REST.
РЕДАКТИРОВАТЬ 2. Если по какой-либо причине вы чувствуете, что должны использовать полноэкранную структуру, похожую на Vaadin, попробуйте Meteor. Это основанная на JavaScript (как внешняя, так и внешняя) структура, которая работает на Node.js с асинхронной связью, происходящей через WebSocket (таким образом, меньшая латентность, чем запрос/ответ), и по умолчанию она реагирует. Множество вещей, которые мне не нравятся в Ваадине, были рассмотрены в Метеор. Например, логика обновлений пользовательского интерфейса работает на клиенте, что делает его гораздо более отзывчивым, чем в Vaadin. Люди в сообществах JavaScript и Java не очень много пересекаются, но когда я впервые услышал об этом, параллия с Ваадином мгновенно ударила меня. В настоящее время он имеет довольно много импульсов в сообществе по причинам, близким к тем, которые сделали Ваадина популярным, т.е. возможность делать настольные веб-приложения. Попробуйте, если вы также осознали, что Java не слишком сильно относится к изображению будущих веб-приложений, или если вы устали от тех длительных циклов развертывания, когда ударяете об обновлении, это все, что нужно. Но подумайте дважды, прежде чем связывать целое приложение с одной библиотекой.
Обычные разговоры о Ваадине касаются набора виджета и беспокойства о связи в оба конца между клиентом и сервером.
Но, на мой взгляд, это игнорирует самый важный (возможно, революционный) аспект Vaadin: он полностью устраняет задачу разработки и реализации взаимодействия клиент-сервер, которая обычно требуется для приложений AJAX ( "A" и "X" ) в AJAX).
С помощью Vaadin вы можете полностью забыть DTO (объекты передачи данных), проблемы безопасности на основе протокола, исключение загрузки с лёгкой загрузкой Hibernate и т.д.
В некотором смысле вы просто пишете обычное старое настольное приложение Java Swing, только вы используете другой инструментарий пользовательского интерфейса от Swing.
Из моего опыта GWT требует много кода шаблона и замедляется при построении завершенного и богатого пользовательского интерфейса. Обычно мы имеем дело с довольно сложными моделями приложений, которые содержат много устойчивых объектов домена. Чтобы донести все эти данные до клиента, вам необходимо ввести отдельную модель клиента и обеспечить механизм преобразования данных. Мы использовали Dozer для этой цели, и требуется много времени, чтобы сопоставить каждую поданную, создать пользовательские преобразователи и протестировать все это.
С другой стороны, если вы не попадаете в overengineering, и если приложение не очень сложно, вы можете воспользоваться преимуществами ресурсов клиента и иметь меньшую нагрузку на сервер. Таким образом, вы можете значительно сократить связь с сервером и получить гораздо более гибкое программное обеспечение.
Вадин выглядит очень девственным разработчиком:) Но я немного боюсь "массивной атаки AJAX" на сервер. У меня есть опыт работы в ZK, и часто мы сталкиваемся с проблемами производительности, когда тривиальная работа в пользовательском интерфейсе работает медленно, потому что для этого требуется связь с сервером.
Wicket - еще одна хорошая структура, но она больше подходит для веб-сайтов. Он может работать с AJAX и без него, может быть проиндексирован поисковыми системами. И самая привлекательная вещь, которая имеет дело с чистым HTML-кодом - никаких пользовательских тегов, никаких структур управления, строгого разделения проблем и только специфических нациглов wicketid для компонентов.
В основном это зависит от ваших потребностей:
Были проблемы с Wicket, использующие сеансы для управления состояниями компонентов и масштабируемостью, аналогичными аргументам, касающимся обработки Vaadin и сервера. За последние 10 лет я узнал, что сообщество Java обычно ошибается в том, как измерять потенциал веб-инфраструктуры (среди прочего). От JSF до Grails обычно требуется несколько сотен ГБ памяти и, по крайней мере, дюжина файлов jar с открытым исходным кодом с перекрывающимися и неэффективными функциями для запуска рабочего приложения. Посмотрите вокруг, и вы увидите, что большинство веб-хостинга компании не предлагают практический вариант java из-за неустойчивого пути Java-технологий для веб-фреймворков. GWT 2.1 по-прежнему борется за использование скорости компиляции, и она просто становится серьезной с MVP и таблицами данных, которые должны были быть с самого начала. Мне нравится Wicket, но Vaadin выглядит многообещающе... но зная, как работают Java-фреймворки, я уверен, что в какой-то момент они будут стрелять в ногу, но я сомневаюсь, что это будет из-за большой обработки на стороне сервера.
Дело в том, что для серьезного развития вы не можете забыть ни о чем, не говоря уже о dtos.. Я являюсь каналом шва и концепцией серверной стороны ui только потому, что я хочу более тонкого контроля над тем, что происходит на проводнике. vaadin проблема для меня в том, что, имея состояние на стороне сервера..
Для создания привлекательных пользовательских интерфейсов я бы сказал, что это будет путь. Плюс это очень хорошо документировано.
Я использую его в течение нескольких недель, а я действительно, как это до сих пор. Код прочный, отлично подходит, очень логичная конструкция, конечные результаты превосходны.
Я люблю его в сочетании с Hibernate, чтобы разобраться во всех темах базы данных.
Plus - легко развертывается (с Tomcat вы можете просто загрузить один .WAR файл через веб-интерфейс, не может быть проще)
взгляните на демо-версию Vaadin с Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html
Также стоит рассмотреть Apache Wicket как сильную альтернативу для компонентных веб-интерфейсов Java Web UI. Ваадин отлично звучит, и я не хочу умалять эту дискуссию, но выбор - это хорошо. Там есть несколько примеров с исходным кодом, связанным с домашней страницей, и даже больше на сайте WicketStuff, а отличная книга от Manning - отличная сторонняя документация.
Я думал, что Wicket - это путь вперед, пока я не попытался заставить его работать эффективно и начал депрессию (шутка). Затем я переключился на GWT, который выглядел великолепно, но есть очень много кодовых табличек кодов для написания, а документация не так уж велика... → Свет пришел от Ваадина: простой, оперативный, никаких ошибок до сих пор...!!!
В нашей компании, которая является преимущественно крупным хранилищем Java SW (помимо всего прочего), появилась возможность создать новый веб-продукт. Это был набор продуктов, и в трех странах это было много команд. Когда дело дошло до нашей команды, у меня был выбор использования Vaadin для использования нашего опыта разработки java. Я искал Google, чтобы помочь мне в моем решении. Я также прочитал этот пост; Однако я выбрал против Ваадина, хотя многие другие команды выбрали Вадина. Ниже приведены причины из почты, которую я отправляю в это время, прежде чем начать работу с продуктом (до Vaadin или Not). Это из моего личного взгляда, и недоверие к рамкам вообще всегда во мне в разной степени. Так что просто хотел дать другому понять этот вопрос читателю.
Хорошо, мы пошли на обучение, изучая HTML, CSS, CSS Selectors, замечательный язык JavaScript и JS libs, JQuery и YUI и со временем создали веб-продукт с полным графическим интерфейсом и соответствием производительности; и я лично счастлив, и команда так же хорошо, как и пользователи.
Другие команды, которые пошли по пути Ваадина, также создали свои продукты вовремя, и я думаю, что они одинаково счастливы. (Только они не знают радости от JavAScript, которую им не хватает:)).
Как сказал кто-то, все абстракции - это непроницаемые абстракции, и когда им приходилось мигрировать с Ваадина 6 на Ваадин 7, им приходилось выполнять некоторую переделку, и потребовалось больше времени, чем кто-либо думал; хотя, конечно, им удалось размалывать и обманывать; Тем не менее было немного задержки из-за этого. Также я предполагаю, что была какая-то проблема с аддоном InvientCharts, который не поддерживал Vaadin 7, заставляя команды покупать ($$) соответствующие дополнения к Vaadin Charts и меняться для этого....
Ваадин или нет
С Vaadin кажется, что базовый JavaScript, HTML и CSS динамически генерируются из приложения типа Java Swing. С предубежденной и, вероятно, глупой точки зрения пуриста, такой "я буду генерировать код для вас" tagline не дает хорошего дизайнерского запаха. Если вам не нужна абстракция, зачем связывать еще одну структуру. Как и в случае любой структуры генерации кода, она должна работать лучше всего для абстракции, которую имел в виду Ваадин, но не очень гибкой; Я чувствую, что, если мы используем веб-технологии, лучше всего использовать инструменты и языки, из которых возникла технология, а именно библиотеки HTML, CSS и JavaScript/JavaScript, а не полагаться на другой уровень абстракции - структуру Vaadin. Это может показаться наивным для опытного разработчика GWT или Vaadin, поскольку, как я полагаю, разработчики Google генерируют наиболее оптимизированный JavaScript, чем ваши закодированные вручную, помогают лучше управлять кодом между несколькими командами и т.д. (Но в основном при разработке довольно крупных веб-приложений), лучше разработчик производительность, упрощение отладки и т.д. Однако писать компоненты в Java для Vaadin, а затем автоматически конвертировать в JS, я чувствую себя не так, потому что многие из наших разработчиков никогда не узнают очень важный язык программирования - JavaScript для веб-разработки (и быстро набирает скорость на стороне сервера - Node.js). Когда вы полагаетесь на фреймворки, чтобы получить право на JavaScript, вы тогда никогда не преуспеете в этом языке. Я думаю, что для компании, основанной на продуктах, важно научиться из первых рук использовать язык Интернета. Поскольку кто-то прокомментировал, что Java стал похож на COBOL в далеком году, и для компетентности необходимо научиться другим важным языкам, таким как JavaScript. Однако, работая в JS в течение небольшого времени, которое у меня есть, я заметил, что если мы будем кодировать некоторую дисциплину (образец модуля), протестировать всю логику - блок JavaScript - JSTestDriver и запустить JSHint, это довольно мощный язык для работы с, и производительность становится лучше, чем Java, когда она будет изучена. Кроме того, большинство примеров важных компонентов - OpenLayers написаны в JS, и если вам нужно расширить их или работать с оптимальным вариантом, вам необходимо знать JavaScript или, если на то пошло, такие мощные библиотеки, как D3.js Короче, хотя есть много преимуществ в использовании Vaadin и фреймворков, в конечном счете, возможно, использование JavaScript важно?
Я тоже использую Ваадина. Хотя приложение не очень большое, мне очень понравилось, что API был совместим, как правило, хорошо документирован, и, учитывая, что я развиваюсь с помощью нового инструмента, я смог вытащить материал для очень требовательный клиент в том же или, в некоторых случаях, лучших таймфреймах, чем инструменты, которые я использовал раньше.
Очень мало проблем. Единственный прямо сейчас - клиент настаивает на использовании IE 7 (не спрашивайте), а некоторые из призрачных глазных конфет не работают полностью 100% в компоненте аддона (диаграмма).
Кстати, я не работаю для Ваадина: -)
Я пробовал Wicket и Vaadin, и если вы действительно попробуете оба в течение некоторого времени, через месяц вы узнаете, что Ваадин - это путь, а не Wicket, период. - Dheeraj G
Мы посмотрели на Wicket, где я работаю, но мы нашли вместо 9000 файлов, у нас могло быть более 30 000. У нас почти 1000 экранов с нашим основным приложением для финансовых услуг, и хотя Wicket выглядит великолепно, очень сложно преобразовать наш код Struts 1.3 в Wicket. Наш архитектор выполнил проект POC, и только 3 экрана добавили несколько сотен классов (многие из них предназначены для повторного использования). Это также сложно протаивать экран с помощью Wicket, так как ваш html должен соответствовать коду Java и наоборот.
Ваадин выглядит многообещающим, но это будет трудная продажа команде.
P.S. Независимо от того, насколько велика структура, никто не узнает ее, если она не используется в промышленности. Wicket существует уже некоторое время, но очень немногие компании используют его. Большинство разработчиков, с которыми я общаюсь, занимаются изучением новой структуры, которая бесполезна в резюме.
Ключевым моментом является то, что Vaadin использует Swing-подобный дизайн, и это помогает мне начать с Java с помощью Swing.
Я использовал Vaadin для разработки giftadvisor в компании, в которой я работаю (а не Vaadin;).
Vaadin позволяет создавать реальные компонентные веб-приложения Swinglike.
Если вас беспокоит кругооборот клиент-сервер за каждый клик, у меня есть это, чтобы сказать: я создал кнопку мыши, которая меняет внешний вид кнопки на "да", "наводка". Для этого структура должна перейти на сервер и обратно. И он работает достаточно быстро imo. Смотрите http://www.cadeau.nl/sophie, чтобы узнать, что я имею в виду.
Мне нравится Vaadin, он удовлетворяет мои потребности и делает webdevelopment легким.
С уважением, Роб.
Я начал с Vaadin всего два дня назад и смог создать небольшое приложение CRUD на OSGi в комплекте с модулями, привязкой данных, службами OSGi для сохранения. Очень приятно, что мой полный пользовательский интерфейс составляет всего 118 строк кода и поддерживает полные операции CRUD для простой структуры java bean.
Также приятно, что Ваадин отлично работает в OSGi. Это уже пакет, и я нашел небольшой мост от Нила Бартлета, который делает vaadin чрезвычайно простым в использовании в OSGi.
Я не против использования состояний на стороне сервера. Он служит своей цели. С облачными вычислениями в настоящее время хранение и пропускная способность становятся дешевыми. Но да, я могу видеть вашу точку зрения с хорошей точки зрения дизайна, особенно если вы хотите RESTify свое приложение. Но я считаю, что в отношении Ваадина и тому подобного больше плюсов, чем против. Одна важная вещь, вам не нужно сильно настраивать свои веб-приложения для определенного браузера, чтобы назвать его IE, для javascript/CSS-тонкостей - особенно если вы ориентированы на задний план, как я. Все ваши веб-приложения становятся совместимыми в браузере, не беспокоясь о чем-либо. Помните, что время разработчика более дорогое, чем время хранения и пропускной способности. Это мое мнение. =)