Какой web framework для java выбрать?

Question

[alexander007]

Добрый день. Сразу извиняюсь за избитый и провокационный вопрос в заголовке.

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

Для лучшего понимания рассмотрю 3 задачи.

Задача №1. Сайт визитка/интернет магазин. Для построения такого сайта я бы взял django (3 последних года пишу на питоне). Что из java лучше подойдет для решения данной задачи? И вообще имеет ли смысл решать такую задачу на java? Требования к инструменту следующие:
- Наличие адекватного шаблонизатора для генерации html с возможностью структурирования шаблонов (как например в djaongo или Jinja2)
- Возможность быстрого построения админки для сайта
- ORM для CRUD операций
- Валидация форм
- поддержка AJAX

Задача №2. Бекэнд реализующий некий API (REST, SOAP, RPC). Для решения этой задачи на python я бы взял flask и sqlalchemy. Какой инструмент java лучше подойдет в этом случае. Требования к инструменту следующие:
- ORM позволяющий реализовывать боле-менее интересные агрегации
- Поддержка в реализации API (REST, SOAP, RPC)

Задача №3. Веб приложение с насыщенным (толстым) веб-клиентом. Например это может быть какая-то CRM работающая в ЛВС. Для решения этой задачи на python я бы взял flask, sqlalchemy и ExtJS. Правильно ли я понимаю что на java для этого хорошо подойдет GWT? Что еще можно использовать? Примерные требования к инструменту следующие:
- ORM позволяющий реализовывать боле-менее интересные агрегации
- Автоматизация построения веб-клиента
- web сокеты (для обновления и уведомление о событиях с сервера)

Хотелось бы получить развернутые ответы. Как я понимаю в данное время бОльшей популярностью пользуются следующие фреймворки: spring, GWT и Grails - так ли это? На что еще стоит обратить внимание? Какие ограничения есть у этих технологий?

Заранее всех благодарю. Буду благодарен если дадите ссылку на хорошую обзорно-сравнительную статью.

Answer 1

[Николай Павлов]

1. thymeleaf
2. spring mvc
3. GWT нужен для создания тонкого клиента, вы путаете. Толстый клиент это swing или javafx.

Comments

[alexander007]

Возможно я не правильно выразился, в последнем проекте над которым я работал (и не только я один) толстым клиентом называли ту часть которая работала у пользователя в браузере. Она состояла из HTML, CSS и тонны самописного JS, сама выполняла рендеринг html шаблонов, и была оформлена как статика. А бекэнд реализовывал REST API, и отдавал только данные в JSON. Ни какого html в JSON не передавалось, только данные. Вот я и спрашиваю на сколько хорошо подойдет GWT для реализации такого фронэнда.

[Николай Павлов]

alexander007: отлично подойдет, однако это тонкий клиент)

[Toast]

Если использовали Freemarker можете ли сровнить с Thymeleaf, чем лучше почем он, а не марке?

[Николай Павлов]

Toast: How does Thymeleaf compare with other template engines like Velocity or FreeMarker?

Both Velocity and FreeMarker are terrific pieces of software, but they approach the templating problem with a philosophy quite different to that of Thymeleaf.

Thymeleaf makes a strong stress on natural templating —allowing templates to be working prototypes, which the other two do not allow—, and its syntax tries to be (arguably) cleaner and more in tune with the current trends in web development. Also, from an architectural standpoint, both Velocity and FreeMarker work as sequential text processors —which allows them to process many types of content— whereas Thymeleaf is based on XML parsing techniques —which limits it to XML-based formats. This makes Velocity and FreeMarker much more versatile, but on the other side allows Thymeleaf to take advantage of interesting features specific to XML-based environments, especially the web.

[Toast]

Николай Павлов: Читал, тут вопрос о личном опыте и подводных камнях, а с копипастить каждый может... Зубная паста тоже самая отбеливающая и не хуже других.

Answer 2

[Adam_Ether]

Вообще хороший вопрос вы задали.

Задача №1.
Можно ли Java? А почему бы и нет? Я бы для такого просто приложения использовал Play ибо он:
- прост в обучении и вообще действительно все делается "играючи"
- приятный, простой шаблонизатор, можно иметь базовые шаблоны, которые расширяются другими
- hot-reload в dev режиме сэкономит время на отладку
- под капотом netty, поэтому работает быстро
- интегрирован hibernate
- более менее можно протестировать все (не самая сильная сторона)
- есть встроенная in-memory база (h2) данных и фикстуры для тестирования

Стоит заметить это все о Play 1*, на мой взгляд, субъективно второй сложнее.

Задача №2
Опять же, можно использовать Play или Spring (стоит попробовать сразу 4, все через аннотации можно сделать, также можно в методе контроллера сразу возвращать объект -- он будет непрозрачно сериализован (настраивается как))

Насчет Spring, это достаточно громосткая технология, зачастую требует намного больше времени, чтобы решить туже задачу (например в Play), больше читать, больше вникать. Но это окупится большей гибкостью.

Задача №3 Если честно, не совсем понял что здесь нужно.

Comments

[alexander007]

Задача №3. Здесь я имел ввиду некое приложение работающее в ЛВС, а не в паблике. Например это какая-то система документо-оборота, или CRM система (система в которой работают менеджеры и проводят проект по его жизненному циклу). Т.е. там где от GUI не требуется рюшечки, а есть много кнопок, таблиц, диаграм, календарей и прочее. И в идеале бы это GUI рисовать подобно тому как это делается в QT (Возможно не совсем хорошая аналогия).

Answer 3

[Владимир Смирнов]

Не ответ, а комментарий ко всем ответам - достали уже с этим Spring. По сути, Spring - это контейнер, в котором разворачивается приложение, и которому Spring предоставляет различные сервисы, в основном: управление транзакциями, развертывание веб-сервисов, Depedency Injection. При этом, сам Spring обычно работает под управлением внешнего контейнера - сервера приложений. Проблема в том, что современные сервера приложений (бесплатные - JBoss/WildFly, TomEE) предоставляют ТЕ ЖЕ САМЫЕ сервисы из коробки. Получается контейнер в контейнере, и попробуй разберись из какого из них ты получаешь тот или иной сервис. Во многих случаях ресурсы просто дублируются - те же бины JBoss находит в jar-ах сам и без каких-либо указаний сразу их деплоит. Плюс вы в Spring-е их же конфигурируете и деплоите второй раз. А если вы в аннотациях указали @Singleton, как себя поведет ваша Система?

Spring - отличная штука, была, лет 5 назад, когда была спецификация J2EE. Сейчас все самое нужное, из того что он давал, уже есть в спецификациях JEE 6, и в серверах приложений, реализующих эти спецификации. Опытные люди говорят так: если у вас есть проект на Spring, работайте и дальше на Spring, если вы создаете проект с нуля - берите JEE 6, про Spring забудьте. Да, у Spring все еще появляются уникальные обертки над различными сервисами, за счет которых они еще пытаются доказать свою востребованность. Но, во-первых, то же, что дает Spring, практически всегда можно сделать другими способами. Во-вторых, в большинстве реальных проектов используется 3-5% сервисов Spring-а, и как я уже сказал, эти сервисы уже есть в серверах приложений.

Если что, погуглите "Spring vs JEE 6" прежде чем холиварить...

Comments

[alexander007]

Отлично что подняли тему EE. Как уже писал "C java платформой я только начинаю работать". C Java SE все более менее понятно. Но вот не как не могу составить для себя целостную картину того, что из себя представляет Java EE.
Если Java EE это полный набор средств для разработки приложений любого уровня сложности от откуда взялось такое количество других фремворков?!
Если не трудно - посоветуйте что можно почитать о Java EE? С чего начать? А то сейчас полная каша в голове относительно Java EE.

[Владимир Смирнов]

alexander007: Java EE - это не набор средств, а спецификация, набор абстрактных API, которые должны реализовывать фреймворки и сервера приложений. Прикладной разработчик использует API Java EE в своем коде, но работать оно не будет до тех пор, пока к проекту не будет подключен фреймворк(-и) или проект не будет развернут под управлением сервера приложений. При этом сервер приложений, по сути, просто набор тех же фреймворков, развернутых и настроенных на веб-сервере.

Пример. Указываю классу аннотацию @WebService. Согласно спецификациям Java EE обычный Java-класс после добавления этой аннотации должен стать веб-сервисом. Но если вы запустите Java-приложение, содержащее этот класс под управлением "голой" Java-машины, то ничего не произойдет, веб-сервис не появится. Если же развернуть приложение под управлением сервера приложений, реализующего спецификации Java EE, то он, с помощью фреймворков развернет класс как веб-сервис.

По поводу почитать, ничего не подскажу, т.к. сам полноценных книжек, увы, не читал, все что знаю почерпнул исключительно из практики...

Answer 4

[anyd3v]

Смотрите в сторону spring (mvc, data, rest), вам хватит точно. В качестве шаблонизатора thymeleaf.

Не советую GWT, Grails.

Comments

[Moxa]

а чем grails не угодил?

[anyd3v]

Тем что на более менее серьезных проектов ему хип нужен больше 1Gb, в то время как решение на спринге умещается в 512. Я конечно не спец в grails, но еще вызывают сомнения примеры https://github.com/grails-samples/grails-petclinic... везде стоят конструкции типа if (request.method == 'GET') и if (!request.post) { return
}

[alexander007]

anyd3v: Кроме 1Gb RAM есть еще косяки у GWT?

[anyd3v]

При чем тут GWT? я писал про grails. GWT ушел вообще в другую сторону и имеет свои идеологии. Если вам интересен ext js то можете посмотреть на www.sencha.com/products/gxt/, который построен на gwt

[alexander007]

anyd3v: Да. не заметил что не про GWT. И все же что можете сказать про GWT? Что в нем не так? С первого взгляда он выглядит как хороший инструмент для создания приложений, которым нужен интерфейс подобный тому что у десктоп приложений.

[Kipriz]

"везде стоят конструкции типа if (request.method == 'GET') и if (!request.post) { return...} "
Это легко можно настроить через UrlMapping. Никаких if не будет, только нормальный маппинг. REST поддерживается из коробки.
Grails даёт очень хорошую скорость разработки, что важно, например, для прототипов. Вообще с Grails тяжело вернутся обратно на Spring или Java EE, потому что скорость и лёгкость разработки на порядок выше.