Web на Java: вспоминать основы или лучше сразу Spring+Vue?

Чистые сервлеты практически не используются. Бери spring

Спринг — однозначно. А что там на фронтенде — это уже по обстоятельствам.

Я скорее в плане насколько стоит лезть в механизмы работы спринга внутренне? Или все настолько бесполезно и проще не париться?

Почему вопрос возник: вот используются там бины, а пошли они с сервлет-страниц для передачи данных и вызовов функций. Сейчас в том же спринге они несколько для другого, но сам принцип джава-бинов остался. Вот и задумался стоит ли вспоминать причинно-следственные связи

Конечно, спринг.

JSP

Говно мамонта, в живой природе встречается только в виде легаси.

а пошли они с сервлет-страниц для передачи данных и вызовов функций

Там общего только название, фактически. По смыслу спринговые бины ближе к EJB. IoC, контейнерные транзакции и вот это вот всё.

Бины отдельно, сервлеты отдельно. В современном спринге вообще есть WebFlux, который не основан на сервлетах, а использует асинхронные движки, netty, например.

Для простых проектов достаточно сервлетов и JSP.

Врёшь. WebFlux прекрасно работает на сервлетах.

Я как java-кодер спрошу, почему не go? Платформа относительно новая, многие вещи пишутся не так как на java, там меньше легаси.

Вот например сервлеты у java предполагают что приложение будет запускаться через сервет контейнер, т.е. через jetty или tomcat/jboss которые реализуют Servlet API и могут выступать в роли веб сервера, в это же самое время за пределами java мира все работает self-hosted, т.е. само запускается и конфигурируется, это облегчает деплой в контейнерах. И что же сделал Spring? Как ответил на вызов времени? Появился Spring-Boot со встроенным сервлет контейнером, т.е. легаси хвост.

ИМХО тебе будет тяжело разобраться во всем этом ворохе, а это путь к карго культу, т.е. следованию рекомендуемым практикам без понимая что происходит за ними, наверное заработать сможешь, но хорошим разработчиком так не стать. Я бы начинал расти вместе с комьюнити, т.е. выбрал бы более молодую технологию, где нету 10 разных путей, 10 авторитетных мнений, 10 темплейт энжинов... такая свобода только помешает процессу обучения.

Я java уже_знаю, так что это не про выбор технологии. И да, у Вас странное в логике:

нужен сервлет контейнер для старых проектов
это неудобно и другие проекты могут и без этого
спринг сделал это удобным
но почему-то не спринг, потому что легаси-хвост, в чем проблемы особо не видно, ибо работает и работает

Ну и да, на го насколько я знаю не один веб-фреймоврк, я лично о двух наслышан

На Go есть веб-фреймфорки потому что их написали, а не потому что они нужны

стоит ли мне тратить время и делать проекты как практику на сервлетах или же забить и лучше делать приложения сразу на Spring+Vue?

делать на Spring + любой фронтенд фреймворк.

а сервлеты это модель исполнения кода да и только, что там особо изучать хз.

спринг сделал это удобным

Нет, он сделал это чтоб работало, чтоб можно в быстро свичнуть с сервелт-контейнеров в self-hosted. Servlet API это еще один фреймворк, потому WebMVC это фрейворк над фреймворком и многие вещи без Servlet API не работают, например spring security завязан на фильтры из Servet API, убираешь Servlet API получаешь проблемы с spring security, с жизненными циклами сессии (т.к. сессией управляет сервлет контейнер), и т.д. Так что если выбросить Servlet API станет проще но все поломается и многие старые вещи перестанут работать, поэтому Spring это сложно, путано и проблемы решать затратно по времени. Ну а начинающим разрабам эти сложности и слои абстракций только помешают, зато они легко загонят в стан карго культа.

P.S. не связано с темой, но просто пример как раньше было просто начать кодить на ассемблере. Сейчас даже vim намного сложнее, чем встроенный в Apple ][ ассемблер.

Я не говорю что java плоха, даже сам язык не плох, есть популярные нынче языки которые на мили позади. Но вот spring, не знаю... я бы посмотрел в сторону vert.x, ktor если kotlin и т.д. Хотя я понимаю, что на рынке будет легче себя продать если в резюме будет строчка про spring. Не представляю как эту штуку изучить, а я кодю с ним 10 лет.

При том, что во многом построение страницы нынче делается на клиенте при помощи JS,

Да, сейчас все данные отдают REST'ами на фронт, а там динамически формируется содержимое страницы. Очень редко когда используют template engine, и тогда выбирают либо Thymeleaf, либо FreeMarker, и никогда JSP.

а сервер лишь ассинхронно передает JSON-ы из базы через Hibernate (если я правильно уловил суть нынешнего мейнстрима в вебе).

SpringMVC работает синхронно, Webflux работает асинхронно но его никто не использует, можешь загуглить по объявлениям. В нем асинхронность реализована фреймворком projectreactor, на java асинхронный код тяжело читать и дебажить, не хватает встроенных в язык async/await/suspend.

Hibernet/JPA никаким боком с асинхронностью не работает, у них нет асинхронных api. Если писать асинхронно, то будешь сильно огранчиен абстракциями по работе с базой, например в случае Spring, ReactiveRepository работают только с Mongo, может еще с чем-то но точно не с Redis, для асинхронной работы с Redis нужно использовать низкоуровневую библиотеку. Асинхронность + Spring = проблемы.

на сервлетах или же забить

забить, изучай Hibernet/JPA, реляционные базы данных (postgres популярен) и можно еще добавить не реляционную Mongo (на собеседованиях о ней часто спрашивают).

в противопоставление спрингу еще микронафт какой-то есть, но я его не тыкал.

спринг ftw! :)

Посмотри ещё в сторону Vaadin, чтобы писать и фронт на нормальном ЯП, а не Js.

Я бы сказал, что лучше всего REST.

На транспортном уровне — JSON или XML поверх HTTP. API сервера описывается языконезависимым образом через WADL (это такой XML) или Swagger (YAML или JSON).

Соответственно, «морду» на этот REST натянуть легко любую — хоть произвольный «веб» хоть на голом jQuery, хоть толстый клиент на JavaFx или даже на Tcl с привлечением Tk, ибо от языка ты не зависишь. В принципе, Web UI можно даже развернуть на отдельном сервере — тебя ничто не ограничивает.

Смотри реализации спецификации JAX-RS 2.0 (Jersey 2, Apache CXF,..) и Swagger.

Вот +1 голос за FreeMarker, ибо он никак не привязан к Servlet-контейнеру.

Вот например сервлеты у java предполагают что приложение будет запускаться через сервет контейнер, т.е. через jetty или tomcat/jboss которые реализуют Servlet API и могут выступать в роли веб сервера

Не предполагают. Встроить полноценный веб-сервер и запустить его очень просто и ничем не отличается от того же Go. Servlet это просто описание API. То, что в Go называется import «net/http», в Java называется сервлет. Кстати если ты пишешь на GCP, насколько я помню, там точно такая же концепция и в Go, никаких self hosted. Это так, для просветления, что всё бывает в разных вариантах.

Кстати в Java есть встроенный веб-сервер и без всяких сервлетов и зависимостей.

А зачем тебе целый spring если у тебя на backend-е только rest-сервисы и hibernate? А зачем тебе асинхронно если hibernate работает поверх jdbc, которое имеет синхронный api? Тот же micronaut, что сверху советовали, для асинхронки лучше подойдёт так как у него под капотом rxjava поверх netty и DI статический. С ним ты сможешь ещё в компиляцию в нативный код с помощью GraalVM поиграться, например. Можешь ещё поиграться с реализациями микропрофайла если вдруг так исторически сложилось, что EE-шное тебе ближе. Свежий микропрофайл с CDI-ками сейчас неплох относительно spring и других фреймворков если тебе только rest-ы и реляционные базы надо. А если ты хочешь spring ради spring, а не какой-то специфической «плюшки» из спринговой экосистемы, то смотри в сторону project reactor и webflux-ов.

По рукам себе линейкой постучи за такие советы и в угол иди на горох.

И останется только работу найти...

https://hh.ru/search/vacancy?clusters=true&enable_snippets=true&text=...

лучше делать приложения сразу на Spring+Vue?

Вопрос риторический.

Только фреймворки.

GWT+GXT или Vaadin на выбор.

JAX-RS, GWT, Vaadin... сразу видно что хэллоуин на носу! Чтоб такое мне достать... хм.. ооОО WSDL, SOAP, JSF.

стоит ли мне тратить время и делать проекты как практику на сервлетах

Знать чего такое сервлеты/jsp и уметь с ними работать понятное дело нужно и полезно. Сейчас они применяются уже не столь широко, но у них есть своя ниша. Так что потратить сколько нить времени на них стоит, тем более они простые как палка.

Тем не менее JSP и прочие HTTPRequest лежат в основе любого Java фреймворка.

Это давным давно не так.

суть нынешнего мейнстрима в вебе

Java прежде всего это бизнес приложения и они не вебе. Они ентерпрайз. А в ентерпрайзе мейнстрим в разных направления очень и очень разный, так и платформы очень и очень разные.

Не представляю как эту штуку изучить, а я кодю с ним 10 лет.

+1. И это очень сильный аргумент за то, чтобы вообще с ним не связываться.

Встроить полноценный веб-сервер и запустить его очень просто

+1. Embedded Jetty — конфетка.

Сразу спринг.

Голосую за spring + reactjs

Не представляю как эту штуку изучить, а я кодю с ним 10 лет.

да вроде все проще сейчас https://otus.ru/lessons/javaspring/

Знать спринг это как знать лес :)

Курс о разработке веб-приложений на Spring

Общая стоимость 60 000 ₽ 

Необходимые знания

    Java Basics
    Multithreading (позже)
    Основы HTML/HTTP/JS
    Основы SQL
    Maven или Gradle

По-моему это бред какой-то, я может отстал от жизни, но блин, с такими знаниями не проще ли пойти работать за 500-1000 баксов java девелопером? А там уже в спринге разбираться по месту, тем более попасть на проект без сприга это как выиграть в лотерею, т.е. маловероятно.

В 2005-2010 годах помню фирмы набирали выпускников на свои курсы, не то что бесплатно, а платили за учебу стипендию (немного конечно - 100-200 баксов), потом оставляли себе лучших. В 10-15 году я работал в фирме которая себе набирала студентов, потом некоторые пришли в штат, никого не гнали, многие находили другие места.

ИМХО тебе будет тяжело разобраться во всем этом ворохе, а это путь к карго культу, т.е. следованию рекомендуемым практикам без понимая что происходит за ними, наверное заработать сможешь, но хорошим разработчиком так не стать.

Странная логика. Если тебе нужно сделать что-то, то ты берёшь инструмент и делаешь. Задача решена. Если поставить себе задачу заглянуть под капот, ничто не мешает тебе в свободное от решения первой задачи время изучать внутренности и копать глубже.

По-моему это бред какой-то, я может отстал от жизни, но блин, с такими знаниями не проще ли пойти работать за 500-1000 баксов java девелопером?

ну а зачем париться?) самому это надо разбираться, силы прикладывать, а тут пережевывают и в рот кладут как птенцу. Хотя не знаю, хорошо это или нет для отрасли в целом.

Странная логика. Если тебе нужно сделать что-то, то ты берёшь инструмент и делаешь. Задача решена

ну с таким подходом ты никогда не поставишь вторую задачу в твоем списке - зачем разбираться то под капотом, если задача уже решена?)

не проще ли пойти работать за 500-1000 баксов java девелопером

Куда, интересно? На любой джуниорской вакансии обязательные требования Spring + Hibernate.

В 2005-2010 годах помню фирмы набирали выпускников на свои курсы, не то что бесплатно, а платили за учебу стипендию (немного конечно - 100-200 баксов), потом оставляли себе лучших.

А в 2001 брали со знанием Паскаля. Только какое это отношение имеет к современному IT?

например в случае Spring, ReactiveRepository работают только с Mongo

Вроде есть там Spring Data R2DBC какой-то, появился не так давно.

Но в целом, я полностью поддерживаю твою точку зрения насчёт Spring. Медленная разработка, карго-культы с чёрными коробками и магическими аннотациями, огромный пласт инфы которую нужно знать чтобы делать всё правильно, а время – это очень ценный ресурс.

// Да как же надоели некропостеры на ЛОРе. Сорри за каст, думал актуальная тема с живым обсуждением пока не наткнулся на свой пост.

Ну раз подняли со дна, то пусть JAkutenshi расскажет что решил и к чему пришел :)

Пришел к тому, что если надо быстро и не париться – Spring Boot + ThymLeaf. JS-а по-минимому, а логика работает (да, медленно). А если хочет кто-то серьезно заниматься веб-разработкой, то само-собой разумеется нужно знать Servlets и как все устроено внутри. Про карго культ не согласен. Просто бОльший уровень абстракции ,он естественен. Каждый раз писать заного абстракции доступа к СУБД? Каждый раз переизобретать велосипед ради чего? Спринг просто работает. Да, чтобы мастерски владеть инструментом – надо изучать вглубь. Это со всем так. Но всегда надо с чего-то начинать и со сприга начать просто. Дальше возникает много вопросов и как нормальный джун – ищутся ответы, читаются документации и книжки (и не смотрится ютуб, а то там понасоветуют).

Кваркус, микропрофиль. Мегакомбайны не нужны.

Да, чтобы мастерски владеть инструментом – надо изучать вглубь

а можно наоборот из глубин:

• поднимаешь всё на чистой SE и обычном tcp порту
• меняешь сокеты на sun.httpserver, понимания что тебе это дало и что а) теперь не надо делать руками б) про что ты был вообще не в курсе когда делал это руками
• меняешь httpserver на httpsserver, вникаешь в азы работы с ssl на явке
• делаешь то-же на ЕЕ, меняешь вкряченный sun.* на внешний сервер контейнеров, пытаешься понять как работает ЕЕ и что это даёт
• далее абстракция при желании (спринг и вот это вот всё)

на выходе ты:

• понимаешь азы http и можешь более-менее контролировать правильность абстракции
• понимаешь что контейнеры это хорошо когда один сервер решает много задач, почему и как
• понимаешь в чем реальная разница между ванилькой и спрингом
• если возникает обратная нужда в решении малозадач но максимальнохорошо ты не привязан к одному абстрактному уровню а можешь спокойно взять и решить это на чистой SE с Netty например

имхо, не навязываю.

плюсую, приятная вещица, особенно когда точно знаешь что хочешь получит в итоге

Ну ок, если тебя не пугают сложности то почему нет.

ThymeLeaf

+1, самый годный темплей энджин.

У спринга и жабы есть одно важное преимущество, всегда доступна навигация по исходникам в ide. В исходники сприга придется довольно часто заглядывать чтоб разбираться что да как работает. Код там годный, по нему можно чему-то хорошему научится.