Забавно, как все происходит последовательно. Недавно, в трех отдельных случаях, я наткнулся на вопросы о том, что люди использовали для интерфейсных технологий. Каждый раз мой ответ был Ваадин . К сожалению, в некоторых местах, например Твиттер, слишком ограничен, чтобы подробно объяснить мой ответ. В этом блоге у меня нет таких ограничений.
В одном предложении Vaadin – это платформа для создания GUI с использованием простой Java или любого языка на основе JVM, если на то пошло. Один разрабатывается на Java, а фреймворк заботится обо всем остальном: это включает в себя генерацию кода на стороне клиента, и связь между кодом на стороне клиента в браузере и внутренним кодом на сервере.
Преимущества использования Vaadin
Эта архитектура обеспечивает следующие преимущества.
Легкая посадка на борт
Первой и главной характеристикой Vaadin является то, что нет необходимости знать другие технологии. Давайте подумаем, какие навыки требуются для “стандартного” приложения, состоящего из REST API и интерфейса JavaScript:
. Java . API Jakarta EE, т.е. Сервлеты и JAX-RS или фреймворк Spring/|. ОТДЫХ принципы . AJAX для взаимодействия между браузером и сервером . HTML . CSS . JavaScript (или машинописный текст) . Интерфейсный фреймворк: в настоящее время наиболее популярными претендентами являются Angular , Vue.js или Реагировать .
Это не менее 8 совершенно не связанных технологий. И я особенно щедр: я опущу любые дополнительные библиотеки JavaScript, а также инструмент сборки, необходимый для создания интерфейсного артефакта. Тем не менее, последнее требуется для перехода с машинописного текста на JavaScript или с последней версии JS на версию, поддерживаемую большинством браузеров. С Vaadin список ограничивается Java… и Vaadin.
Если вы прочитаете это, вы можете подумать, что это не такая уж большая выгода, потому что вас окружают разработчики в 10 раз больше, что бы это ни значило ). Мой опыт совершенно иной: я проработал более 15 лет подрядчиком для множества разных заказчиков. Большинство разработчиков – обычные люди, которые с удовольствием работают с 9 до 5, а затем возвращаются домой, чтобы жить своей жизнью. У них нет ни желания, ни времени изучать еще одну технологию в нерабочее время. Исходя из того, что обучение должно проходить в рабочее время, меньшее количество технологий означает меньшее время обучения и больше времени, посвященного разработке приложения.
Отсутствие фазы интеграции
Простота, которую обеспечивает Vaadin, имеет дополнительное преимущество. Если архитектура одного приложения разделена на интерфейсную и серверную части, которые взаимодействуют через REST API, существует две стратегии организации своей команды:
- Разработка на уровне Эта стратегия основана на двух специализированных командах: интерфейсной и серверной. Они очень хороши в своем собственном стеке. Они оба работают параллельно, в своем соответствующем стеке. После того, как самый медленный из них заканчивает, они объединяют свою соответствующую работу вместе. Мой опыт показал мне, что на параллельной фазе работа выполняется (довольно) быстро. Напротив, этап интеграции занимает много времени. Мой опыт показывает, что это занимает до времени, затраченного на первом этапе, – эффективно удваивая время разработки. Хуже всего то, что этот второй этап недооценивается большинством команд, включая руководителей проектов.
- Разработка для каждого варианта использования Эта стратегия основана на разработчиках с полным стеком. Такой разработчик способен работать на обоих концах, спереди и сзади. Каждому разработчику назначается сценарий использования/история пользователя, затем ему необходимо понять бизнес вокруг него, а затем он может разработать весь поток от графического интерфейса до базы данных. Я лично считаю, что разработчик полного стека – это концепция, которая была изобретена менеджерами, чтобы сделать разработчиков взаимозаменяемыми. Таким образом, планирование задач становится для них намного проще. В любом случае, давайте признаем, что такие единороги действительно существуют. Если кто-то владеет таким количеством технологий, у него должно было быть время, чтобы изучить их. Это возвращает меня к вышесказанному: у большинства разработчиков есть жизнь помимо работы. Конечно, есть вундеркинды, но в таком случае им нужно платить соответственно. К сожалению, у обычных компаний недостаточно бюджета: они могут позволить себе одну, но не полную команду единорогов. В связи с этим Vaadin позволяет разработчикам, не являющимся rockstar, разрабатывать приложение, используя 2-ю стратегию. Это также позволяет им тратить больше времени на деловую сторону вещей и меньше времени на технические вопросы.
Распараллеливание между серверной и интерфейсной разработкой
По умолчанию Vaadin позволяет разработчикам, которые не являются графическими дизайнерами, разрабатывать приемлемые графические интерфейсы. Однако бывает, что у владельца продукта есть требования – а иногда даже бюджет – для настройки дизайна.
При традиционном подходе дизайнеры достигают этого с помощью HTML и CSS. Они будут разрабатывать специальные шаблоны HTML и классы CSS. Затем разработчикам будет предложено их использовать.
Если требования изменятся на полпути, разработчикам придется прекратить свою работу, чтобы интегрировать изменения, требуемые дизайнерами: существует высокая зависимость между рабочим процессом разработчиков и рабочим процессом дизайнеров. Некоторые технологии, такие как JSP, JSF и Thymeleaf, позволяют разработчикам повторно использовать артефакты дизайнеров как есть. В этом случае обоим придется работать с одними и теми же артефактами. Конфликты слияния Git всегда забавны, когда кто-то не полностью понимает изменения в восходящем потоке.
Vaadin представляет две абстракции, которые разделяют работу разработчиков и дизайнеров: темы и компоненты.
- /|Тема представляет собой набор CSS (и Sass ). Поскольку Vaadin генерирует HTML, дизайнеры знают, какую структуру следует ожидать, и могут соответствующим образом спроектировать свой CSS. В Тема Lumo применяется по умолчанию. Другая тема, Материал предоставляется “из коробки”. Экосистема предлагает дополнительные темы, каждая из которых доступна в виде JAR, которую нужно только добавить в путь к классам. Дизайнер также может создать свой собственный. Обратите внимание, что переключение тем возможно с помощью простого вызова метода.
- Компонент имеет как шаблон HTML, так и класс Java, который представляет его на стороне сервера. Такой компонент может размещать другие компоненты в макете. В то время как класс Java управляет ими как атрибутами, шаблон HTML отвечает за макет. Таким образом, работа разработчика над классом Java – или любым другим классом, который его использует, – и работа дизайнера над шаблоном полностью изолированы друг от друга: они могут полностью выполняться параллельно.
Предназначен для “бизнес” приложений
Наконец, Vaadin по своей сути предназначен для разработки бизнес-приложений.
- На стороне пользовательского интерфейса компоненты включают виджеты, часто используемые в таких приложениях например, поля, поля со списком, формы, таблицы и т.д.
- Большинство компонентов отображают данные. Конструкция этих компонентов вводит абстракцию между компонентом и его данными. Существуют различные конкреции:
- Для скалярных значений например электронное письмо, отображаемое в поле
- Для коллекционных ценностей например список стран, отображаемый в поле со списком
- Для двумерных значений например, табличные данные, отображаемые в таблице
Аргументы, которые я слышал против использования Ваадина
За все эти годы я слышал немало аргументов против использования Ваадина. В основном все они сводятся к следующим двум.
“Но масштабируется ли он?”
Возможно, вам будет интересно узнать, что этот вопрос является частью 10 приемов, позволяющих выглядеть умным на собраниях ( #6 ).
Говоря более серьезным тоном, масштабирование определенно заслуживает некоторого углубления. Vaadin хранит состояние компонентов на стороне сервера. При огромном количестве компонентов и с увеличением числа клиентов это приводит к экспоненциальному потреблению памяти. В этом отношении традиционные приложения не сильно отличаются от приложений Vaadin.
Во-первых, нам нужно понять, что подавляющее большинство приложений отслеживают состояние. Однако отличительный фактор между ними заключается в где хранится состояние . Как я уже упоминал, Vaadin хранит его на сервере. Есть только две другие альтернативы:
- Сохраните его в базе данных. Нужно ли мне подробно объяснять, почему это плохая идея?
- Храните его на клиенте. Мне имеет смысл хранить данные, связанные с пользовательским интерфейсом, на клиенте. Однако есть одно не менее важное предостережение: если открыто более одной вкладки, ее необходимо каким-то образом обработать на стороне сервера. Обратите внимание, что Vaadin управляет несколькими вкладками, помещая скрытый маркер при первоначальном отображении страницы. Когда пользователь взаимодействует со страницей, маркер проверяется, а затем в браузер снова отправляется новый.
В то время как за пределами десяти тысяч одновременных пользователей я мог бы начать думать о других альтернативах, кроме Vaadin, все, что ниже этого числа, является честной игрой. Это 99,99 % всех приложений.
Не первый API-интерфейс
Еще один аргумент, который я слышал против Ваадина, заключается в том, что он не является первым API. Хорошие разработчики/архитекторы программного обеспечения всегда разрабатывают API, чтобы позволить использовать различные типы клиентов: браузеры, а также собственные клиенты и другие сервисы – как внутренние, так и сторонние.
К сожалению, я думаю, что это стадный менталитет. API-первый желателен в контексте нескольких клиентов. Большинство бизнес-приложений, над которыми я работал, – это просто CRUD приложения с более или менее бизнес-логикой, применяемой сверху.
Но что, если в будущем возникнет необходимость в дополнительных клиентах? ЯГНИК ! Если вы это сделаете, помните, что Twitter смог полностью переписать свою информационную систему с Ruby on Rails на Java: перенос уровня графического интерфейса приложения находится в пределах возможного.
Скучный
Наконец, хотя я никогда не слышал ничего подобного, я считаю, что одна из причин, по которой Ваадин не так популярен и не распространен, заключается в том, что он такой скучный. Он существует уже более 15 лет, работает, как и ожидалось, и большинство проблем, связанных с ним, уже решены. К сожалению, это не подходит разработчикам, которые практикуют Резюме-/Шумиху-/Разработку, основанную на Эгоизме .
Вывод
Я открыл для себя Ваадин чуть больше 10 лет назад, и это была любовь с первого взгляда. На самом деле, я сразу же начал возиться с ним и попытался интегрировать его с другим моим увлечением, Spring framework .
В версии 10 произошла массовая перепись фреймворка. Управление продуктами направило его в сторону большего количества веб-функций, таких как веб-компоненты, введение маршрутов и т. Д. Я считаю, что этот шаг был сделан для того, чтобы больше понравиться веб-разработчикам. Честно говоря, я не очень доволен этими изменениями.
Однако это не меняет того факта, что я все еще большой поклонник фреймворка. Я признаю, что это не такая шумиха, как фреймворки JavaScript. С другой стороны, это огромный прирост производительности при разработке бизнес-приложений по сравнению с любой другой альтернативой для рекламы.
Первоначально опубликовано на Помешанный на Java 7 июня 2020 года.
Оригинал: “https://dev.to/nfrankel/why-i-still-love-vaadin-1h31”