Должен ли я использовать Vaadin Framework
Я только что попробовал поиграть с Vaadin Framework, и он мне кажется очень простым в использовании. Плюс, что мне нравится в его фреймворке, это то, что он построен поверх Google Web Toolkit (GWT).
Как вы думаете, я должен продолжать использовать этот фреймворк или лучше придерживаться GWT?
19 ответов
Привет. Как заявление об отказе от ответственности, я работаю в компании, разрабатывающей Vaadin.
Vaadin использует GWT таким образом, что он имеет набор компонентов, предварительно скомпилированных в GWT. Вы можете, конечно, дополнительно сделать свои собственные компоненты, если вы этого хотите. Тем не менее, набор компонентов довольно полный, и часто может быть настроен для ваших собственных нужд. Это означает, что вам не нужно перекомпилировать код из Java в JavaScript каждый раз, когда вы меняете свое приложение. Вы просто объединяете уже имеющиеся компоненты вместе.
Фреймворк управляется сервером, поэтому вся логика обрабатывается на стороне сервера. Компоненты состоят из двух частей: файла клиента и сервера. Клиентская сторона - просто фиктивное "представление" для компонента. Как только вы взаимодействуете с ним, он отправляет на сервер сообщение о том, что тот или иной был нажат / записан / и т.д. Затем сервер решает, что должно быть сделано. Это для повышения безопасности, потому что вы не можете "взломать" логику, поскольку в javascript доступен только небольшой API, предназначенный для отправки запросов. В некоторых случаях это может быть небольшим компромиссом со скоростью приложения, но я не думаю, что это так плохо. Наихудшие удары скорости - это, как правило, обходы запросов по БД и тому подобное, которые не имеют никакого отношения к выбору инфраструктуры пользовательского интерфейса. Медлительность демонстраций, как предлагается, может быть вызвана тем, что вы находитесь далеко от сервера или в настоящий момент наблюдается высокий уровень пользователей. Попробуйте в своей среде, закройте окончательное приложение вашего приложения, чтобы увидеть, насколько хорошо оно работает. Есть несколько готовых приложений, которые вы можете просто развернуть, чтобы протестировать их.
Я думаю, что выбор сводится к тому, что вы пытаетесь сделать. Vaadin хорош для веб-приложений, поскольку вы можете создать обычное Java-приложение и легко создать для него динамический веб-интерфейс. Если вы делаете нечто большее, чем традиционный веб-сайт, где пользователи только просматривают страницу - более чем активно взаимодействует с ней, то Vaadin - не лучший путь. Пойдите с некоторыми другими бесплатными фреймворками, такими как rails или php-фреймворк и т. Д. Я думаю, что вы больше делаете приложение, поскольку вы предлагаете использовать GWT сейчас, так что Vaadin должен быть хорош.
Задайте дополнительные вопросы здесь, на форумах Vaadin или на IRC-канале #vaadin @freenode, и, возможно, кто-то может дать вам больше причин, почему или почему бы не использовать Vaadin.
После почти полутора лет разработки небольшого приложения GWT с использованием всех лучших практик, которые я извлек из последних операций ввода-вывода Google, таких как MVP, EventBus, CommandPattern и т. Д. Я говорю это от всего сердца: потратив несколько дней на попытки чтобы все получилось так, как моя команда и клиент хотели технически и визуально, даже после выпуска UiBinder, Ваадин пришел ко мне как свет в конце туннеля.
После написания почти тысячи шаблонных действий для шаблона команд, еще тысячи презентаторов и представлений и еще тысячи обработчиков событий и т. Д. Не имея дело с почти 75% этих классов и все еще поддерживая хороший шаблонный подход (дополнение appfoundation), допустима небольшая нагрузка на сеть. С Vaadin, из коробки вы получаете хорошие виджеты, подкачку страниц, привязку данных, безупречную верстку. Все это для чего? Еще немного потребления памяти на стороне сервера.
Я думаю, что могу сказать, что это приемлемо, потому что я не создаю следующий Facebook или что-то в этом роде. Я по-прежнему могу обрабатывать тысячи одновременных пользователей на одном среднем сервере, и в то же время сохраняю циклические обходы с низкой задержкой.
С помощью Vaadin я могу создать хорошее приложение с почти половиной строк кода, и все же приложение кажется более полным.:-)
!! ОБНОВЛЕНИЕ 23 февраля 2011: я не могу подчеркнуть, как нужно знать об ограничениях каждой структуры. Ваадин ничем не отличается. Следует помнить, что Ваадин абстрагируется от любой формы HTML или JavaScript. Кроме того, полученный HTML-код очень тяжелый, и вы должны позаботиться об изменениях состояния истории самостоятельно. Так что, будьте в курсе этих накладных расходов при создании проекта.
Отказ от ответственности: я не связан ни с одной из библиотек, упомянутых ниже, но, похоже, знаю, как с ними справляться.
Как и вы, я наткнулся на этот пост, размышляя, какой стек / фреймворк использовать для нового проекта. У меня был солидный опыт с Play! (хорошо, в Scala, но здесь это не актуально), но убедительные виджеты и их бесшовная интеграция с серверной частью + разработка, похожая на Swing, заинтересовали меня. Это было в конце 2010 года, и когда ответы убедили меня попробовать Ваадина, я решил вернуться и написать ответ, который мне бы хотелось прочитать здесь, особенно. так как вопрос все еще актуален сегодня. Тем временем Vaadin перешел с версии 6 на 7 с несколькими заметными улучшениями, которые были необходимы, Play! Я перешел с версии 1 на 2, и я (+ небольшая команда) выполнил небольшое количество успешных проектов с обеими платформами.
Я думаю, что сравнение интересно, потому что обе структуры
- работать на JVM и может использовать свою богатую экосистему
- не может быть более противоречивым в их подходе к веб-приложениям и к тому, о чем вы, как разработчик, должны заботиться, и
- в меньшей степени, как они связаны с Java EE.
Хвалить
В одном предложении, если вы обнаружите идею переноса настольного приложения в браузер, будучи полностью абстрагированным от основного механизма HTTP-запросов / ответов, то Vaadin, вероятно, ваш кандидат на создание веб-приложения. Его Swing-подобный подход к программированию может быть легким делом для тех, кто больше всего счастлив от низкоуровневости HTML и JavaScript. Новый запрос к вашему приложению действительно запускает новый экземпляр, а остальная часть потока зависит от вас и вашей логики. Ссылки возвращаются к старым добрым кнопкам для навигации, и вы можете создавать макеты, используя множество встроенных шаблонов, без необходимости настраивать HTML или CSS. API, как правило, довольно непротиворечивый и, по общему признанию, хорошо документированный ( Книга Ваадина - обязательное чтение. Делайте это тщательно, так как многие вещи легко доступны, например, связывание ваших компонентов с компонентами и валидаторами,...). Виджеты имеют хорошую совместимость с различными браузерами, что обеспечивает согласованное поведение вашего приложения для широкого круга клиентов.
Проверка на практике
Мы хорошо провели время, разрабатывая и тестируя наши приложения Vaadin. Все стало яснее и более нюансировано, когда мы выпустили первую версию и начали собирать отзывы. Мы поняли, что на самом деле мы были предвзяты довольно фундаментально, а именно:
В 201x году у большинства пользователей была долгая история использования Интернета, и лишь немногие из них фактически уже не пользуются настольными приложениями. Ключевым моментом здесь является то, что браузеры стандартизировали взаимодействие UX с гипертекстовыми ссылками, кнопками "назад", "вперед" и "перезагрузка", вездесущими вкладками и иногда окнами, а также с основной идеей, что большинство действий инициируют HTTP-запрос и будут ожидать ответа. Это неявный договор о том, что веб-сайты соблюдаются и вокруг которых они построены. Поэтому мы не должны были удивляться, когда пользователи жаловались на то, что они не могут использовать кнопки "назад" / "вперед", как они привыкли, или что вкладки не работают ожидаемым образом. И мы согласились. Мы нарушили невидимый договор, обязывающий пользователей и браузеры. На самом деле, мы сами не использовали наш браузер с приложением Vaadin так, как мы использовали его на любом другом веб-сайте. Конечно, вы можете вернуться к вышеупомянутой книге и внимательно прочитать репликацию веб-навигации с фрагментами URL-адреса, и вы увидите, что на самом деле это более сложный процесс, чем ожидалось, поскольку приложения Vaadin с состоянием. Более того, в отличие от Play, парадигмы MVC или MVP навязываются разработчику только свободно! где практически нет другого варианта. Не принимайте это всерьез, но ваш мозг привык к яркому белому экрану, отображаемому за долю секунды после смены страницы. Когда пользователи нажимают и ожидают, что будут открыты новые страницы, браузер подтверждает это, показывая песочные часы (или их варианты). С 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, но из-за некоторых из этих ограничений и фундаментального изменения парадигмы мы не будем запускать новые проекты с ним. Тем не менее, спасибо команде, которая создала технически согласованную, целостную и хорошо документированную 360-градусную веб-среду Java, требующую очень мало знаний о внутренней работе веб-сайта. С другой стороны, они даже поддерживают свою структуру с компанией, продающей консалтинговые услуги. Я благодарен за опыт и за то, как он заставил меня пересмотреть свои взгляды на веб-приложения. Я буду внимательно следить за его развитием, но нам определенно нужно больше контроля и детализации.
Надеемся, что однажды Vaadin освободится от всей архитектуры сервлетов, от которой зависит собственный HTTP-сервер. Еще лучше будет дизайн MVC, более глубоко укоренившийся в структуре. Но это в некоторой степени маловероятно в обозримом будущем, поскольку, похоже, оно нашло выгодную нишу среди опытных корпоративных горилл Java, которые клянутся только EE. Сиять на.
TL; DR: Я думаю, что Ваадин не понимает, что такое веб-приложения и, что более важно, как они должны себя вести. Речь идет о времени, когда программисты охватили веб и то, как пользователи взаимодействуют с ним (т. Е. Кнопка назад, кнопка перезагрузки, вкладки и закладки). Чем ближе веб-приложение придерживается HTTP-запросов и семантики (глаголов), тем больше вероятность того, что оно будет соответствовать ожиданиям пользователей. И это ключ.
РЕДАКТИРОВАТЬ: Если у вас есть опыт работы с Python, я настоятельно рекомендую попробовать Flask, чтобы получить представление о программировании веб-приложений на основе REST на основе URL.
РЕДАКТИРОВАТЬ 2: Если по какой-либо причине вы чувствуете, что должны использовать полноценный Vaadin-подобный фреймворк, то попробуйте Meteor. Это основанная на JavaScript (как frond, так и внутренняя) среда, которая работает на Node.js с асинхронной связью, происходящей через WebSocket (таким образом, меньшая задержка, чем запрос / ответ), и по умолчанию она реактивна. Некоторые вещи, которые мне не нравятся в Ваадине, были рассмотрены в Метеоре. Например, логика для обновлений пользовательского интерфейса запускается на клиенте, что делает его намного более отзывчивым, чем в Vaadin. Люди в сообществах JavaScript и Java мало пересекаются, но когда я впервые услышал об этом, параллель с Ваадином поразила меня сразу. В настоящее время он пользуется большой популярностью в сообществе по причинам, схожим с теми, которые сделали Ваадин популярным, т.е. возможность создавать настольные веб-приложения. Попробуйте, если вы также поняли, что Java не очень важна для будущих веб-приложений, или если вы устали от этих длительных циклов развертывания, когда нажатие на обновление - это все, что нужно. Но подумайте дважды, прежде чем привязывать все приложение к одной библиотеке.
Обычный разговор о Vaadin касается набора виджетов и заботы о двусторонней связи между клиентом и сервером.
Но, на мой взгляд, это упускает из виду наиболее значительный (возможно, революционный) аспект Vaadin: он полностью исключает задачу проектирования и реализации взаимодействия клиент-сервер, которое обычно требуется для приложений AJAX ("A" и "X" в AJAX),
С Vaadin вы можете полностью забыть DTO (объекты передачи данных), проблемы безопасности на основе протоколов, исключения отложенной загрузки Hibernate и т. Д.
В некотором смысле вы просто пишете обычное старое настольное Java-приложение Swing, только вы используете другой инструментарий пользовательского интерфейса из Swing.
Исходя из моего опыта, GWT требует много стандартного кода и медленно работает при создании полноценного и богатого пользовательского интерфейса. Обычно мы имеем дело с довольно сложными моделями приложений, которые содержат много постоянных доменных объектов. Чтобы передать все эти данные клиенту, вам нужно будет ввести отдельную модель клиента и предоставить механизм преобразования данных. Мы использовали Dozer для этой цели, и требуется много времени для отображения каждого файла, создания пользовательских конвертеров и тестирования всего этого.
С другой стороны, если вы не впадаете в слишком трудоемкую работу и если приложение не очень сложное, вы можете воспользоваться преимуществами использования клиентских ресурсов и снизить нагрузку на сервер. Таким образом, вы можете значительно сократить общение с сервером и получить более гибкое программное обеспечение.
Вадин выглядит очень взволнованным разработчиком:) Но я немного боюсь "массивной AJAX-атаки" на сервер. У меня есть опыт работы с ZK, и часто мы сталкиваемся с проблемами производительности, когда тривиальная операция в пользовательском интерфейсе работает медленно, поскольку требует взаимодействия с сервером.
Wicket - еще один хороший фреймворк, но он больше подходит для веб-сайтов. Он может работать с AJAX и без него, может быть проиндексирован поисковыми системами. И самое привлекательное, что он имеет дело с чистым HTML-кодом - нет пользовательских тегов, нет управляющих структур, строгое разделение задач и только конкретные обозначения для компонентов.
Это в основном зависит от ваших потребностей:
- Если вам нужно супер быстрое и простое приложение - используйте GWT и используйте ресурсы клиента
- Если ваше приложение довольно сложное, то Vaadin выглядит лучшим вариантом
- Если ваше приложение является общедоступным и вам нужна возможность проиндексировать его для SEO, выберите Wicket.
Дело в том, что для серьезного развития вы не можете ничего забыть, не говоря уже о dtos.. Я отказываюсь от шва и концепции пользовательского интерфейса на стороне сервера только потому, что желаю более точного контроля над тем, что происходит по проводу... Проблема Ваадина для меня это именно то, имеющее состояние на стороне сервера..
Существовали "опасения", связанные с использованием Wicket сеансов для управления состояниями компонентов и масштабируемости, аналогично аргументам о Vaadin и обработке на стороне сервера. За последние 10 лет я узнал, что сообщество Java обычно ошибается в том, как измерить потенциал веб-фреймворка (помимо прочего). От JSF до Grails обычно требуется пара сотен ГБ памяти и по крайней мере дюжина файлов JAR с открытым исходным кодом с перекрывающимися и неэффективными функциями для запуска производственного приложения. Посмотрите вокруг, и вы увидите, что большинство веб-хостинговых компаний не предлагают практичный вариант Java из-за нестабильного пути, который Java-технологии выбрали для веб-фреймворков. GWT 2.1 по-прежнему проблематичен из-за скорости компиляции, и он только серьезно относится к MVP и таблицам данных, которые должны были появиться с самого начала. Мне нравится Wicket, но Vaadin выглядит многообещающе... но, зная, как работают Java-фреймворки, я уверен, что в какой-то момент они сами выстрелят себе в ногу, но я сомневаюсь, что это произойдет из-за интенсивной обработки на стороне сервера.
Я бы сказал, что для создания привлекательных интерфейсов я бы выбрал этот вариант. Плюс это очень хорошо задокументировано.
Я пользуюсь им пару недель, и мне до сих пор это нравится. Код надежен, документация хорошая, очень логичная конструкция, конечные результаты отличные.
Я люблю это в сочетании с Hibernate, чтобы разобраться со всеми скуками базы данных.
Плюс - простота развертывания (с Tomcat вы можете просто загрузить один файл.WAR через веб-интерфейс, это не может быть проще)
Также стоит рассмотреть Apache Wicket в качестве сильной альтернативы для компонентно-ориентированных сред Java Web UI. Ваадин звучит великолепно, и я не хочу отвлекать от этой дискуссии, но выбор - это хорошо. Есть несколько примеров с источником, связанным с домашней страницей, и даже больше на сайте WicketStuff, и отличная книга от Мэннинга представляет собой отличную стороннюю документацию.
Я думал, что Wicket - это путь вперед, пока я не попытался заставить его работать эффективно и не начал депрессию (шутка). Затем я переключился на GWT, который выглядел великолепно, но так много кода для написания котельной пластины и документации не так уж и много... -> Свет от Vaadin: простой, работоспособный, никаких ошибок пока нет...!!!
Взгляните на демонстрационную сборку Vaadin с Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html
В нашей компании, которая является преимущественно крупным Java-домом (среди прочего), появилась возможность создать новый веб-продукт. Это был набор продуктов, и в трех странах его разработали многие команды. Когда дело дошло до нашей команды, у меня был выбор - использовать Vaadin, чтобы использовать наш опыт разработки java. Я искал в Google, чтобы помочь мне в моем решении. Я также прочитал этот пост; Однако я отказался от использования Vaadin, хотя многие другие команды выбрали Vadin. Ниже приведены причины из письма, которое я отправил в то время перед запуском продукта (Ваадину или Нет). Это, с моей личной точки зрения, и недоверие к рамкам в целом всегда во мне в разной степени. Так что просто хотел дать еще один взгляд на этот вопрос для читателя.
Мы продолжили обучение, изучая 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 - JSTestDriver и запустить JSHint, то это довольно мощный язык для работы с и производительность становится лучше, чем Java, как только она изучена. Также пример большинства важных компонентов - OpenLayers написаны на JS, и если вам нужно расширить их или работать оптимально, вам нужно знать JavaScript, или в этом отношении мощные библиотеки, такие как D3.js. Короче говоря, есть много преимуществ При использовании Vaadin и фреймворков, в конечном итоге, возможно, важно использовать JavaScript?
Я использую Vaadin также. Несмотря на то, что приложение невелико, мне очень понравилось то, что API был непротиворечивым, в целом хорошо документированным, и, учитывая то, что я разрабатывал с новым инструментом, я смог получить информацию для очень требовательного клиента. или в некоторых случаях лучшие сроки, чем инструменты, которые я использовал раньше.
Очень мало вопросов. На данный момент единственное, что клиент настаивает на использовании IE 7 (не спрашивайте), и некоторые из самых интересных глазных конфет не работают полностью на 100% в аддонном компоненте (построение графиков).
Кстати, я тоже не работаю на Ваадина:-)
Мы посмотрели на Wicket, где я работаю, но вместо 9 000 файлов мы могли найти более 30 000. У нас есть около 1000 экранов с нашим основным приложением для финансовых услуг, и, хотя Wicket выглядит великолепно, преобразовать наш код Struts 1.3 в Wicket чрезвычайно сложно. Наш архитектор выполнил проект POC, и всего 3 экрана добавили несколько сотен классов (многие для повторного использования). Также сложно создать прототип экрана с помощью Wicket, поскольку ваш html должен соответствовать коду Java и наоборот.
Ваадин выглядит многообещающе, но это будет трудно продать команде.
PS Независимо от того, насколько хорош фреймворк, никто не узнает его, если он не используется в промышленности. Wicket существует уже некоторое время, но очень немногие компании используют его. Большинство разработчиков, с которыми я общаюсь, занимаются изучением новой структуры, которая бесполезна в резюме.
Ключевым моментом является то, что Vaadin использует Swing-подобный дизайн, и это помогает мне начать в Java с использованием Swing.
Я попробовал Wicket и Vaadin, и если вы действительно попробуете оба в течение некоторого времени, то через месяц вы узнаете, что Vaadin - это путь, а не Wicket, точка. - Dheeraj G
Я начал работать с Vaadin всего два дня назад и смог создать небольшое приложение CRUD на OSGi с модульностью, связыванием данных и сервисами OSGi для постоянного использования. Одна очень хорошая вещь заключается в том, что мой полный пользовательский интерфейс содержит всего 118 строк кода и поддерживает полные операции CRUD для простой структуры Java-бина.
Также приятно, что Ваадин прекрасно работает в OSGi. Это уже пакет, и я нашел небольшой мост от Нила Бартлета, который делает vaadin чрезвычайно простым в использовании в OSGi.
Я использовал Vaadin для разработки giftadvisor в компании, в которой я работаю (не Vaadin;).
Vaadin позволяет создавать реальные веб-приложения на основе Swinglike.
Если вы обеспокоены тем, что клиент-сервер выполняет обходные действия для каждого клика, я хочу сказать следующее: я создал кнопку при наведении курсора, которая меняет вид кнопки на да, при наведении курсора. Для этого фреймворк должен перейти на сервер и обратно. И это работает достаточно быстро, IMO. Смотрите http://www.cadeau.nl/sophie чтобы проверить, что я имею в виду.
Мне нравится Vaadin, он отвечает моим потребностям и делает веб-разработку проще простого.
С уважением, Роб.
Я не против использования состояний на стороне сервера. Это служит своей цели. С облачными вычислениями современные хранилища и пропускная способность становятся дешевыми. Но да, я вижу вашу точку зрения с точки зрения хорошего дизайна, особенно если вы хотите RESTify своего приложения. Но я считаю, что в отношении Ваадина и тому подобное есть больше плюсов, чем минусов. Одна важная вещь: вам не нужно много настраивать свои веб-приложения для конкретного браузера, давайте назовем его IE, для сложностей Javascript/CSS - особенно если вы ориентированы на бэкэнд, как я. Все ваши веб-приложения становятся совместимыми в любом браузере, и вам не о чем беспокоиться. Помните, что время разработки обходится дороже, чем хранение и пропускная способность. Это мое мнение. знак равно