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

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

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

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

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

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

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

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

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

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

Слава

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

реальность проверка

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

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

2. Stateful приложения приносят свою долю проблем... и неприятности. Балансировка нагрузки (если вы обеспокоены) для одного сложнее. Концепция транзакции полностью отличается, поскольку сеансы Vaadin охватывают многие запросы и поэтому являются длинными в отличие от Rest based, но относительно короткими с точки зрения UX. Действительно, это не редкость для пользователей, чтобы вернуться к форме они начали часов назад, чтобы закончить свою задачу. Теоретически это могло бы сработать и с Ваадином, но вам придется долго-долго поддерживать сеансы с заблокированной памятью и тщательно думать о том, что это будет масштаб W. r.т. параллельные пользователи.

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

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

вывод

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

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

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

TL; DR: Я думаю, что Ваадин упускает суть того, что такое webapps и, что более важно, как они должны себя вести. Речь идет о времени, когда программисты охватили интернет и как пользователи взаимодействуют с ним (т. е. кнопка Назад, кнопка перезагрузки, вкладки и закладки). Чем ближе веб-приложение придерживается HTTP-запросов и семантики (глаголов), тем более вероятно, что оно соответствует ожиданиям пользователей. И это ключ.

редактировать: Если у вас есть опыт Python, я бы настоятельно рекомендовал попробовать колбу, чтобы получить вкус url-ориентированного веб-приложения на основе REST программирование.

Изменить 2: Если по какой-либо причине вы считаете, что должны использовать полный стек Vaadin-подобный фреймворк, попробуйте Meteor. Это основанная на JavaScript (как frond, так и back end) структура, которая работает на узле.js с асинхронной связью, происходящей через WebSocket (таким образом, меньшая задержка, чем запрос/ответ), и она реактивна по умолчанию. Ряд вещей, которые мне не нравятся в фреймворк Vaadin были рассмотрены в Метеор. Например, логика обновления пользовательского интерфейса выполняется на клиент, который делает его намного более отзывчивым, чем в Vaadin. Люди в сообществах JavaScript и Java не пересекаются, но когда я впервые услышал об этом, параллель с Vaadin поразила меня сразу. В настоящее время он пользуется довольно большим импульсом в сообществе по причинам, сродни тем, которые сделали Vaadin популярным, т. е. возможность создания настольных веб-приложений. Попробуйте, если вы также поняли, что Java не принадлежит к картине будущих веб-приложений или если вы устали от эти длинные циклы развертывания при нажатии refresh-это все, что нужно. Но подумайте дважды, прежде чем привязывать все приложение только к одной библиотеке.

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

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

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

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

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

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

Вадин выглядит очень разработчиком frinedly:) но я немного боюсь "массированной атаки AJAX" на сервер. У меня есть опыт работы в ZK и часто мы сталкивались с проблемами производительности, когда тривиальная операция на UI работает медленно, потому что он требует связи с сервером.

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну мы пошли на обучение Шпрее обучения HTML, CSS, CSS селекторы, замечательный язык JavaScript и JS libs, JQuery и YUI и создали веб-продукт во времени с полным GUI и производительности соответствие; и я лично я счастлив, и команда, а также пользователи.

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