Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 12
Я немного знаю html, и этих знаний явно недостаточно для построения полноценного интерфейса пользователя. С помощью Vaadin-а я могу реализовывать некоторые задумки.
С помощью Vaadin-а можно реализовать… но зачем?
Надеюсь, вы пообещали себе в этом году выучить HTML, CSS и JavaScript. На самом деле это будет наилучшим решением.
А Вы знаете, что сейчас процесс изучения «HTML, CSS и JavaScript» происходит сам собой, во время изучения данного FrameWork-а.
Ну так так каждый выбирает по себе.
Просто мне кажется, что лучше изучить основы сразу, а потом уже «надстройку». Нежели сперва учить нечто, чтобы от него перейти к основам. ИМХО.
Просто мне кажется, что лучше изучить основы сразу, а потом уже «надстройку». Нежели сперва учить нечто, чтобы от него перейти к основам. ИМХО.
HTML, CSS и JavaScript — это отдельное огромное направление. В статье я хотел показать Vaadin как отдельный инструмент, а не сравнивать его возможности. Для многих он прекрасно подойдет для работы, при этом это только часть статьи, обратите на это внимание.
Чистый GWT и так уже достаточный слой абстракции над JS, который иногда тоже сильно мешает. Но вполне позволяет быстро начать работу над корпоративными веб приложениями java разработчикам. А Vaadin — слишком толстая абстракция которая зачем-то навязывает и server side часть приложения.
Вот смотрите, касательно GWT в первой статье, на которую я привожу ссылку, указывается на особенности GWT.
Концепция GWT почти такая же, как у Vaadin: вы пишите код только на Java. Только GWT транслирует ваш Java-код в JavaScript. Сложности начинаются тогда, когда надо обработать событие, приходящее из браузера (например, обработка нажатий кнопки или сабмита формы). Чтобы из сгенерированного JavaScript-кода вызвать код на серверной стороне, надо сделать несколько магических пассов: создать абстрактный класс-фабрику, его реализацию и т.п.
Vaadin избавляет вас от этих проблем. Кстати, Vaadin на самом деле использует GWT, так что его можно даже считать надстройкой над GWT, которая решает проблемы общения с сервером. Вы просто пишете Listener
Это не будет наилучшим решением. Поверх HTML/CSS/Js вы все-равно используете какую-нибудь библиотеку стилей типа bootstrap или polymer, которые вместо каши тегов вводят концепт виджетов и добавляют к ним поведение. Для логики используете какой-нибудь JQuery или Angular. Для каждого запроса приходится отдельно разрабатывать интерфейс с сервером и мепить (ручками или полуавтоматически) получаемые структуры данных на виджеты. Так что на одном HTML/CSS/JS далеко не уедешь.
Vaadin позволяет быстро разработать вебприложение типа админки, фактически программируя только серверную часть. Взаимодействие с браузером полностью прозрачно. Плюс в том, что многие нюансы UI уже учтены и идут из коробки. Плюс мепить данные на сервере в typesafe java-объекты на порядок проще, нежели заморочки с Json. Фреймворк будет близок тем, кто разрабатывал приложения на Swing и подобных библиотеках виджетов.
Vaadin позволяет быстро разработать вебприложение типа админки, фактически программируя только серверную часть. Взаимодействие с браузером полностью прозрачно. Плюс в том, что многие нюансы UI уже учтены и идут из коробки. Плюс мепить данные на сервере в typesafe java-объекты на порядок проще, нежели заморочки с Json. Фреймворк будет близок тем, кто разрабатывал приложения на Swing и подобных библиотеках виджетов.
Vaadin, конечно, прекрасный фреймворк, но Вы не упомянули о том, что логика по отображению страницы формируется на серверной стороне. Так, например, если на клиенте при нажатии на кнопку нужно открыть pop-up, это вызовет запрос на сервер (тонкий клиент).
За удобство приходится платить. Поэтому vaadin не подходит для нагруженных решений (слишком много лишних запросов от клиента). Можно, конечно, разделить Java код на клиент и сервер, как в классическом GWT, сделать толстый клиент, но тогда его придётся разрабатывать отдельно и взаимодействовать с сервером через RPC.
Что касается liquidbase, мне больше нравится Flyway. В SQL миграциях проще разобраться на взгляд, чем в xml. А совместимость с несколькими СУБД редко бывает необходима.
За удобство приходится платить. Поэтому vaadin не подходит для нагруженных решений (слишком много лишних запросов от клиента). Можно, конечно, разделить Java код на клиент и сервер, как в классическом GWT, сделать толстый клиент, но тогда его придётся разрабатывать отдельно и взаимодействовать с сервером через RPC.
Что касается liquidbase, мне больше нравится Flyway. В SQL миграциях проще разобраться на взгляд, чем в xml. А совместимость с несколькими СУБД редко бывает необходима.
Vaadin, конечно, прекрасный фреймворк, но Вы не упомянули о том, что логика по отображению страницы формируется на серверной стороне
Да, и это не беда.
За удобство приходится платить. Поэтому vaadin не подходит для нагруженных решений
Спорный момент, нужно смотреть.
Flyway
Не встречал Flyway в работе, попробую посмотреть.
Vaadin, конечно, прекрасный фреймворк, но Вы не упомянули о том, что логика по отображению страницы формируется на серверной стороне.
В этой статье мне важно не описать Vaadin и Liquidbase(для этого я оставил ссылки на видео и сайты), а сделать так, что бы читатели увидели разные способы создания приложений и посмотрели один из вариантов. Сравнили со своим подходом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пример создания веб-приложения с помощью библиотек Vaadin