Comments 21
В 14 версии он также остался прожорливым до ресурсов, поэтому за этим надо следить и уделять внимание
Что на счет прорисовки элементов, то я лично не замечал, чтобы долго прорисовывались элементы
Насколько я знаю они ушли в 14 версии (а точнее в 15, а потом еще и внедрили в 14), от полимерных шаблонов и перешли к lit шаблонам и вроде как это улучшило работу с UI, но с этим особо не разбирался, поэтому точно сказать не могу на что это повлияло
А как в Vaadin реализована верстка под разные разрешения экрана?
Движок Vaadin сам это сделает, т.е. каких то определенных телодвижений не нужно делать, компоненты будут пытаться адаптироваться под экран
Конечно, если вы укажите размер 1000px какому либо блоку, то сам блок уже не адаптируется и внутри него элементы тоже
Также можно использовать компонент FormLayout которая адаптирует элементы находящиеся на форме, а также будет изменять их расположение в зависимости от размера экрана
Vaadin и ему подобные штуки - это не fullstack. Это как раз для бэкендеров, которым надо хоть какой-то UI без необходимости вдаваться в подробности фронта.
И да, это работает ровно до того момента, пока "вот эту иконку надо на 3 пикселя вправо подвинуть, а тут надо сделать динамическую подгрузку данных в таблицу, и чтобы не тормозило". По мере возрастания количества хотелок код начинает обрастать такими костылями, что вообще никто не понимает, как оно работает и почему.
У меня есть опыт создаения фул стек с Java/GWT и Java/React, Vue, Angular. При этом основная специальность именно бек на Java. И по моему опыту, попытка сделать все на Java обычно получаются мучительными, потому что:
Смешивание кода — обычно получается мешанина из бека, фронта, html и css. Вот те getStyle().set("padding-bottom", "7px") это с точки зрения фронта тихий ужас, который никто ни в одном js фреймворке не делает.
Производительность обычно получается фиговой и рано или поздно клиенты начинают страдать и команде все больше штук приходится переписывать на чистом js для ускорения, что ломает идею не нужно учить js.
Обычно как только требуется красивый и сложный UI начинаются проблемы — для UI компонент для основных js фреймворков море на любой вкус, а на java фреймворке все приходится либо делать с нуля, либо обходится тем что есть, либо писать их на js, что опять ломает идея избавиться от js.
В общем, попытка сделать все на Java обычно заказчивается тем, что все равно приходится часть писать на js/ts, что ломает главную идею фреймворка, в результате java разработчики выучивают какой-нибудь js фреймворк достаточно, чтобы перейти на него, а чистые фронты тут ничем помочь не могут.
Отсюда даже если проект не похоронит производительность и ограниченость UI — у него будет хроническая нехватка разработчиков.
Единственно, где это взлетает проекты где пофиг на красоту, UI в целом и скорость работы (что-то вроде внутреннего приложения чисто для использования своими же сотрудниками) при наличие множества беков и отстуствия фронтов.
На мой взгляд Vaadin и подобные ему решения очень хороши для прототипирования, когда нужно в максимально сжатые сроки реализовать функциональный прототип нового программного продукта, который смогут "пощупать" потенциальные пользователи и другие заинтересованные лица, чтобы понять как это все работает и что делать с этим дальше. Зачастую такие прототипы разрабатываются одним или двумя разработчиками (в светлых головах которых скрывается великий замысел и логика работы нового продукта) без возможности привлечения дополнительных специалистов для полноценного проекирования и реализации интерфейса пользователя.
Работал с ним лет 6 назад, в ту пору он был не шибко гибкий в плане стилей и поведения js, ну и тормоза конечно. Часть компонентов были только в платной версии, но можно было написать свое, если сильно надо. Но наши джависты были рады, что стало можно делать себе всякие админ панели не привлекая фронтендеров.
Выглядит как-то не очень. Используется в энтерпрайз?
Использую Vaadin уже 6 лет. Идеальный фреймворк для интранет-приложений!
Есть кнопка-"счетчик". При нажатии кнопки значение переменной увеличивается на 1 и это значение отображается в тексте самой кнопки.
В Vaadin при каждом нажатии кнопки будет вызываться сервер, который будет формировать новую старицу и отправлять в браузер?
С Vaadin не работал, как-то на GWT писал давно уже. В принципе это все норм тема, когда вебморда нужна примитивная, а все самое сложное и интересное крутится на самом сервере, и нет необходимости прикручивать к нему какой-то крутой UI. Тогда реально можно не заморачиваясь всей этой фронтовой темой накидать простенький интерфейс и все будет хорошо. А вот если там надо что-то сложное и с жесткими требованиями по производительности..
Vaadin по этому описанию похож на blazor из c#, всё это игрушки для бакэндеров, чтобы типа не лезть во фронт, хотя всё равно приходится что-то css'ить, что-то javascript'ить и думать о фронте, пока пишешь на фреймворке, с которым "не нужно думать о фронте", просто теперь ты думаешь о том как заставить его генерить именно тот html, который надо именно тебе. А если речь зайдет о том чтобы сделать свою тему на весь фронт, простые фронтэндеры уже не справятся, т.к. им придется вникать во все тонкости управления движком и либо всё будет делать фулстекер или бэкер с фронтером вместе.
Про ресурсы я считаю тут сказано достаточно, чтобы понять, что такой фреймворк это не игра в долгую. Ограничение по ресурсам на пользователя - минус масштабирование и заранее известный итог, всё перепишут на другую платформу. Ещё и мучительно больно придется тем кто не зная этого движка, будет отделять впаянную во внутрь бизнес логику от "фронта на языке бакэнда" и будет копаться в том как же движок реализует фронт.
Главная проблема таких решений это замкнутый круг их малого коммьюнити, апдейты не такие частые как у более крупных движков, меньше юзеров тестят, пишут в поддержку и пишут гайды и соответственно большее багов, дольше развитие движка, больше проблем при разработке, больше порог вхождения, меньше разработчики хотят в это вникать. В то время как веб развивается и фронтентд быстро переходит на новые решения, здесь всё будет одинаковым пока разрабы не поспеют за новыми веяниями, чего ещё пади дождись, и чтобы быть актуальным новые решения придется внедрять либо в обход фреймворка, либо костыля на нём какие-нибудь непопулярные решения. Плюс не забываем про ресурсные ограничения.
Так стоит ли писать на таком фреймворке
с которого всё равно придется переписывать
знания о котором вряд ли пригодятся и будет сложно найти работу
с которым точно будет куча проблем, при следующем обновлении веба или реализации фич связанных с фронтом
для которого понадобятся дополнительные ресурсы железа
Vaadin по этому описанию похож на blazor из c#
теперь ты думаешь о том как заставить его генерить именно тот html, который надо именно тебе.
В Blazor получаете именно ту разметку, которую ожидаете: от HTML его синтаксис ушел не дальше, чем JSX. Вообще, этот фреймворк внешне больше на React смахивает, чем на Vaadin.
что-то javascript'ить
Опять же, в Blazor максимум, что может понадобиться javascript'ить — это обертки для JS-библиотек, если вдруг возникнет желание таковые втаскивать в проект.
пишешь на фреймворке, с которым "не нужно думать о фронте"
Не нужно думать о JS, а про фронт здесь вся статья.
Уж лучше тогда использовать jsf primefaces, там хотя бы бесплатных компонент 100+ штук. А тут очень ограничен набор и лицензия на Энтерпрайз недешевая.
Мы не используем энтерпрайз версию, в бесплатной версии пока не было недостатка компонентов и как я уже упоминал в статье, если чего то не хватает, то можно поискать в сообществе, ну или самому сделать если это какой то сложный компонент, а так кнопки, таблицы, поле для ввода и т.д. все присутствуют в бесплатной версии
Очень много статей на эту тему, я тоже несколько лет назад стоял перед выбором, но к сожалению выбор был не в сторону vaadin. Основная причина это отсутствие возможности масштабирования, то есть если больше одной ноды приложения то надо подумать как синхронизировать сессии, сессия хранит состояние и от этого вытекает много проблем (но есть и плюсы конечно), проблема когда сеть логает и тд
Если коротко - vaadin можно использовать для создания морды которым пользуются мало людей, это может быть какая-то админка или бухгалтерская программа, а вот интернет-магазин не сделаешь.
Чтобы не быть голословным, предлагаю посмотреть доклад на jpoint от Юрий Артамонов — Анатомия и физиология Vaadin Flow
Так а какие там проблемы? Вроде же сессия это проблема сервера а не UI. Vaadin это же просто очередной толстый клиент аля ангуляра. Тут можно развернуть кластер томкатов и сделать стики сешн.
Сессия это не проблема сервера, именно такие сессии добавляют очень много ограничений и проблем которые надо решать, вот несколько из них: многозадачность, балансировкой запросов, очень сильная зависимость от сетевого соединения, большой жор ресурсов. Из этого следует что проблема имеется у бизнеса с точки зрения сложности разработки и дорого оборудования и проблемы разработчика который должен разбираться и бороться с UI фреймворком вместо того чтобы делать бизнес логику.
Кроме этого, Vaadin это на аля Angular, первый это толстый клиент как было подмечено а второй это web фреймворк который после сборки выдает простой html+css+js, который в принципе своей работы ничем не похож на толстый клиент.
Vaadin или как стать full-stack разработчиком