Веб на чистой Java. Изучаем Vaadin — крутой фреймворк для создания веб-приложений

[AndersonDunai]

У меня в голове засело «DVA-ADIN» и не выходит…

[AndersonDunai]

Moar minuses!

[P0WERMIC]

Да ну его этот Vaadin. Строили на нем front-end для enterprise решения и он реально очень тяжелый на нем все очень долго (считай в 3 раза дороже) делать, если нужно что-то большее, чем стандартные компоненты. В общем, я не рекомендую.

[Dr_XaoS]

Да, это так. Все очень радужно, пока укладываешься в небольшой набор стандартных компонентов. Но шаг в сторону — и надо либо добавлять css/js, чтобы пдоравнивать расползающиеся элементы, либо запиливать свои, да так чтобы вписаться в архитектуру ваадина.
Еще не понравилась система layout'ов — задумка хорошая, но выливается это в сотню вложенных div'ов.

[Calc]

Не знаю как в Vaadin, но в GWT документации четко сказано «Используйте виджет, а GWT сам придумает как его отобразить», и да, это выливается во множество div. «GWT думает за вас» — как основной функционал приподносится.

[Minoru]

сколько бы он ни думал за нас, клиент всегда думает по-другому

[Borz]

клиенту всё равно сколько div/table использованы чтобы показать ему элемент интерфейса — для него главное, чтобы скорость отображения и взаимодействия с этим элементом не выходила за зону его комфорта.

[dea]

Можно позавидовать тем, кто может позволить себе выбирать таких клиентов.

[hardex]

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

[DbLogs]

А на что перешли? Мы вот на Apache Wicket — все тоже самое, но ооочень быстро. Ну и в Wicket можно докапаться до таких глубин, если надо — что Vaadin'у и не снилось.

[P0WERMIC]

перешли на чистый html5 и Angular

[vaniaPooh]

Мне в GWT не нравится то, что получаемый Javascript очень трудно отлаживать и я согласен с POWERMIC, что он действительно очень тяжелый.

[gagoman]

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

[Calc]

На GWT еще хорошо прототипы делать, особенно если ты не WEB программист и не знаком с js напрямую.

[Calc]

Не факт
У меня очень хорошая база по web bakcend программированию на PHP(8 лет) и других интерпретируемых языках.
А когда ты уходишь в проектировани
frontend терпеть не могу, но знаю как работает.
Давно живу на java (desktop, android и т.д.), так что GWT дает хороший и простой инструмент для отработки некоторых элементов + после это можно включать в ТЗ для web программиста, либо использовать в том виде как есть.
И да, я не работаю программистом :)

[TimReset]

А Вы давно на GWT писали? А то тут опции компиляции pretty появились и SuperDevMode с source map. Я сам source map пользовался в 2.6 и 2.7. Отлаживал JS как Java код в IDEA. Т.е. фактически исполнялся JS в Chrome (не как Dev mode с исполнением клиентского Java кода на сервере), а IDEA точки останова переносила в Java код и выглядело как отладка обычного Java кода. Соглашусь, что работает хуже в плане отладки, чем в Dev Mode, но пользоваться можно.

[dea]

Поддержу, в 2.7 отладка с source map доведена до приемлемого качества. По моему, главной проблемой GWT является долгая перекомпиляция, но и тут в 2.7 заметные улучшения в компиляции на лету.

[vit1251]

А есть какой-то простой Framework для Servlet+ORM+Template? А то использовать таких монстриков как Spring и Play! очень уж не хочется.
Все больше думаю о написании костыльного FrontContoller+Templater+собственный частный ORM (частный значит реализует преобразования SQL в POJO), но конечно хотелось бы уже готовые решения посмотреть. Может быть кто-то подскажет?

[Borz]

шаблонизатор: JMTE или SiteMesh
ORM: OrmLite или MyBatis

[AxianLTD]

Мне JSF и компания вполне подходят. И вручную немного писать приходится, и проектировать интерфейс достаточно просто.

[dea]

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

[Acvilon]

Я очень удивлен, что кто-то еще использует таких монстров как: Vaadin, JSF и другие подделки, где люди пытаются жизненный цикл Frontend'а написать на backend'е.

[dea]

Просто не надо на них как на swing писать, тогда все получится.

[rtorsten]

Мне очень не понравился Vaadin, как фреймворк для enterprise приложений. К сожалению сейчас проект на нем написали и приходится поддерживать сам Vaadin и кучу кастылей для него, чтобы он хоть как-то работал.

Фреймворк очень тяжелый и не гибкий. Например, можно сделать generated column, а потом узнать что при открытии страницы на сервере исчезает 100 Мб на каждую, потому что где-то там внутри вызывается некий refresh row cache, который перегенерит каждую ячейку 100500 раз и создаст столько layout-ов и прочего стафа для нее.
Кастомные компоненты — писать тоже очень не удобно.
Очень много дефектов на UI связанных с zooming, scrollbars и resize'нгом для IE бразуеров (которые наиболее часто используются в корпоративном секторе, для которого собственного вроде как и делалася Vaadin).
Очень много проблем так же возникает с интеграцией в корпоративную инфраструктуру. Любые лаги в сети делают Vaadin абсолютно неработоспособным.

Для себя вижу его хорошим фреймворком для создания эмуляторов и админ консолей.

[dax]

Подозреваю, что множества «Ява-Разработчики» и «Профессиональные Верстальщики» практически не пересекаются. Оттого смотрю на Vaadin с большой долей скепсиса.

[alexmay]

Очень. Медленно. Работает.

[Borz]

можно пересекаться. например через чистый Spring WebMVC, ZK Framework (с темой atlantic), JMTE или SiteMesh. А GWT, Vaadin и иже с ними (как и вышеозвученный ZK) это для Rich Internet application, где в первую очередь функциональность, а потом уже «рюшечки».

[tinhol]

Мы используем Vaadin, как механизм создания веб-интерфейса в нашей платформе. По мне, так он неплохо подходит для создания корпоративных приложений, где красота явно не на первом месте. Ведь такие приложения — это в первую очередь очень много функционала, который постоянно меняется. Верстать каждый раз с нуля такое — очень утомительно, на Vaadin гораздо быстрее.
Как мне кажется, для создания публичных приложений лучше использовать что-то другое, Vaadin с его «топорностью» тут проигрывает.

[P0WERMIC]

Это пока их UI не интересует, придет время и они начнут просить сделать все красиво и удобно и придется страдать.

[tinhol]

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

[Borz]

когда заинтересует «сделать красиво», разработают тему и просто её применят. ИМХО, для корп. приложений не требуются футуристические полёты мыслей дизайнера.

[Throwable]

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

[tinhol]

Проблема (на мой взгляд) в том, что интерфейс зачастую подогнан под требования Vaadin, то есть использует VerticalLayout, HorizontalLayout и так далее. Чтобы уйти от этого (например использовать кастомную html верстку), требуется усилий ничуть не меньше, чем верстать html с нуля на каком нибудь client-side фреймворке. То есть приложение вынужденно подгоняется под возможности фреймворка и имеет соответствующий вид. Для корпоративных приложений это приемлемо, для публичных — вряд ли.

[kyberorg]

>Vaadin (кстати, в переводе с финского это слово означает «олениха»…
Если немного подробнее, то Vaadin — это богиня-олениха из финской мифологии.
В Book of Vaadin есть любопытное приложение «Songs of Vaadin»

[squonk]

Всегда интересно было, что сподвигло авторов делать запроы на сервер на каждый «чих» приложения. Что-то подобное видел давно в iceFaces.