Проблеми TypeScript у світі React-додатків вiд Iллi Климова на React fwdays | 27 березня
×Закрыть

На чем реализуется фронт-энд в современных веб-приложениях на Java?

Здравствуйте, господа программисты!

Хотел бы спросить у джава-дэвов. Пытаюсь вот ознакомиться с возможностями Java для создания веб-приложений, Core Java усвоил достаточно неплохо.

Относительно технологий, фреймворков для серверной части есть кое-какая ясность (что для чего используется и насколько популярно), а вот на чем реализуется в современных веб-приложениях на Java фронт-энд? HTML/CSS/JS или что-то другое, из необъятного мира Java-технологий?

P.S. Не забрасывайте сильно яйцами как нуба, в зоопарке технологий Java порой непросто разобраться без совета опытных дэвов.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Все зависит от системы:
1) старючее legacy, фронт-энд: JSP, JSF, jQuery (если повезет), куча костылей javascript и css для поддержки недо-браузера IE
2) небольшие-средние проекты не сильно древние, фронт-энд: Sprint MVC, Struts 2 (буээээээ), GWT, jQuery, Prototype
3) PET-проекты, либо супер-современные: javascript mvc: Ember.js, Angular.js, Backbone.js,
сервер может быть на Node.js, что не всегда хорошо.

Совет от все еще миддла: главное в любой проекте — подход у команды и процессы со стороны руководства, а не технологии. Если существует подход: про лебедя, рака и щуку или «баги любой ценой, а на требования — положить (потому что их нет)», то жизни девелоперу не будет ни на каких технологиях.

До того, що вже написано я б додав ще Vaadin.

А якщо коротко то:
— Angular JS + Java as API. Тренд
— Spring MVC (MVC frameworks). Стає меньш популяним. В основному використовується в парі з темпліт двіжком.
— GWT(Vaadin). В основному для інтернал тулзи
— JavaFX. Оракл позиціонує, як заміну Swing, тому не дуже Web
— JSF. Проекти де куча бабла на app server або олд скуол архітекти

— Spring MVC (MVC frameworks). Стає меньш популяним. В основному використовується в парі з темпліт двіжком.

З яким? Tiles чи звичайний JSP?

В контексте «Angular JS» очевидно ни то ни другое — отдается json

Так в основному JSON.

Tiles. JSP не темпліт двіжок:)

За різними розповідями у мене склалося не дуже хороше враження від GWT і всього, що з ним пов’язано.
Шарахаюся тепер від GWT, Vaadin, ExtGWT, «як чорт від ладану».

Кожен фреймворк для чогось робився:) GWT і йому подібні робили, для того, щоб уникнути при можливості прямого контакту з JS. І з цього їх призначення. Бізнес аплікації. В них UI не такий важливий і красивий(хоча MVP частково це виправляє), але девелобмент набагато швидший.

Судя по моему опыту, даже на JSF скорость девелопмента быстрее чем на GWT, а уж объем кода и цикл code-compile-deploy уж подавно. Плюс, у меня почему-то не получилось GWT с JRebel синтегригровать, но то в 2011 было.

Джаваскрипт используется и хтмл.

Я думаю, что JSP. JSF можно посмотреть «для общего развития». По моим наблюдениям от них стараются отказаться. На клиенте JavaScript (Angular, например). Для связи с серваком REST,
Websocket. Все вышесказанное %IMHO% конечно же.

Есть три распространенных подхода:
1 Классический Web
Сервер отдает HTML, который генерируется на сервере с помощью JSP/Servlets. Ими же обрабатываются запросы которые присылает бразуер.

2 Google Web Toolkit (GWT)
Клиент предстаяляет собой приложение, которое пишется на Java. Главной фишкой ялвяется то, что это приложение компилируется не в байт-код, а в JavaScript (и HTML).
Используется этот фреймворк, главным образом, Java-разработчиками, которые Java знают лучше, чем JS-фреймворки. Не спасает от необходимости хорошо знать HTML/CSS

3 JSON & API
Клиент, написанный на JavaScript+HTML, общается с сервером по JSON. Сервер предоставляет набор методов, которые можно вызывать с клиента — API (REST API, RPC API,...)
Классический пример сервера — Spring MVC, Клиент — jQuery и/или любой популярный JavaScript-фреймворк.

GWT
настолько неудобная, что я никому не советую его использовать и сам всегда отказываюсь его использовать.
Платформу гугла юзать можно(google storage еще терпимо. в остальном разрабатывать как обычное веб-приложение и все будет ок). Но GWT использовать нельзя. Проще самому html и яваскрипт выучить, чем разобраться в том болоте, которое на самом деле никаких профитов не дает, кроме как «писать на яве яваскрипт».

JSF + Primefaces/Icefaces/Richfaces или какие-либо JS фреймворки вроде Angular.js или Backbone.js

JSF умер и уже давно горит в аду. Не надо его призывать!

я потому за Tapesty5 засел.

Был недавно у друга в офисе, за пивком пообщались.
Стартапчик махонький, тут 5 наших, в Штатах тоже 5 наших, забывающих уже русский язык, в силу многих лет жизни там.
Сервер сайд — чистый REST на джаве.
Фронта два — iOS, и на Angular

сам он до этого немало на JSF ваял.
«Сколько жизни ну хню потратил» примерно такова его реакция.

Для небольших ентерпрайз проектов — самое то. И проблем с кадрами нет, т.к. джависты могут и на фронтенде и на бекэнде работать. В то время как на Angular найти команду не в пример сложнее.

небольшие энтерпрайз ? это как железное дерево или рок против наркотиков

он не умер. он мертворожденный. он никогда не жил.

Относительно технологий, фреймворков для серверной части есть кое-какая ясность (что для чего используется и насколько популярно),
а кстати, поделитесь своей ясностью, интересно услышать мнение

Фронтенд — отдельно, Бекенд — отдельно.

На бекенде только API с помощью Jersey или аналогичной штуки от Спринга.

Фронтенд зависит от размера проекта и наличествующих ресурсов. Для небольших и средних проектов подойдут Backbone (в связке с Marionette или Chaplin) или Angular JS. Для чего-то большого — Ember JS или опять же Angular.

Если что, автор Чаплина живет в Харькове и доступен для консультация, но по американским рейтам.

Крайне желательно, чтобы разработка бекенда и фронтенда шла независимо. Будет лучше, если это будут разные репозитории с разными билд-процессами, чтобы фронтендеры не зависели от Java вообще. Так они смогут работать быстрее и эффективнее. Соответственно, REST API становится естественным водоразделом между проектами. Если договориться о протоколе и формате данных, то команды смогут работать автономно в большинстве случаев и не мешать друг другу.

Остерегайтесь посыла заказчика или других разработчиков использовать Ext JS, Yahoo UI, Kendo UI и прочие. Это библиотеки компонентов, архитектуру диктуют не они, а фреймворки, перечисленные выше. Определяетесь вначале с MVC-фреймворком, а UI компоненты начинаете использовать по мере необходимости.

Все то же самое, что и на других проектах. Если хардкор и тренд — AngularJS.

Все тоже, что и с другими языками и платформами, т.к. фронт работает независимо. Есть конечно разные библиотеки именно под Java, которые помогают работать с фронтом, но суть от этого не меняется. Имхо, фронт делать зависимым от бека — не всегда хорошая практика.

Подписаться на комментарии