Witam wszystkich od kilku miesięcy uczę się Javy. Jak z tym nie było problemu to teraz zaczynają się schody. Chcę uczyć się web-devu. Mam problem z wyborem technologii do dalszej nauki. Czytałem wpis o technologiach zombie na forum, ale i tak mam mętlik. Jeśli chodzi o bazy danych uczę się Hibernate i nie widzę w tym większego problemu. Zacząłem uczyć się spring-boota i architektury REST i wygląda to całkiem fajnie. Mógłby ktoś pokierować czego warto się uczyć a co omijać z daleka? Nwm czy warto uczyć się też SpringMVC czy uczyć się REST.
0
5
SpringMVC i html generowany po stronie serwera jest raczej w odwrocie. Przynajmniej w świecie Javy. W tej chwili w większości nowych technologii robota programistów Javy kończy się na wystawienia rest Api i swaggera. Resztę robią frontendowcy
0
@Krystian C. Bardziej szukasz rozwoju, czy szybkiego przełożenia na komerchę?
Do linii samorozwoju mogą zaciekawić cię frameworki / biblioteki niezależne od standardu "servlet", np Ratpack. Etatów na to jest raczej mało, ale jest bardzo ciekawy.
@Kamil mi ciągle brak "full stackowych" bibliotek. Nie będę wynajmował frontowca do każdej pierdoły (np zmiana walidacji pola - to chore)
Uprawiam Apache Wicket (nie ewangelizuję n/t, ale bardzo szanuje ten framework, do pewnej grupy celów bardzo pasuje, chętnym poszerzę, co myślę).
A w czasie bardziej wolnym poromansuję z Java EE 8 MVC (na springa mam uczulenie - a ten wydaje się bardziej "ortogonalny", a nowoczesne EE nie jest tak złe, jak je malują)
EDIT: nie przeraźcie się skrótowcem jsp, to nie jest tak, jak pozornie wygląda.
0
AnyKtokolwiek napisał(a):
@Kamil mi ciągle brak "full stackowych" bibliotek. Nie będę wynajmował frontowca do każdej pierdoły (np zmiana walidacji pola - to chore)
Uprawiam Apache Wicket (nie ewangelizuję n/t, ale bardzo szanuje ten framework, do pewnej grupy celów bardzo pasuje, chętnym poszerzę, co myślę).
Nie mówię że nowe podejście jest zawsze lepsze
BTW może rozwiązaniem by tu było kompilowanie języków backendowych do JSa?
- Java ma JSweet, ale nie jest to zbyt popularne
- Scala ma Scala.js i udało się nawet jakieś community zbudować w ogół tego. Jest parę frameworków ułatwiających integrację z Scalą na backendzie i jest sporo bindingów dla bibliotek używanych na frontendzie
- Dla Clojure jest ClojureScript. Nie wiem na ile to jest używane, ale twórcy Clojure jakoś bardzo chcą zaznaczyć że ten język nie jest związany tylko z platformą JVM
1
AnyKtokolwiek napisał(a):
A w czasie bardziej wolnym poromansuję z Java EE 8 MVC (na springa mam uczulenie - a ten wydaje się bardziej "ortogonalny", a nowoczesne EE nie jest tak złe, jak je malują)
Jako, że mam to wszystko za sobą to porada: nie idź tą drogą. Springa miłośnikiem nie jestem. ale
Java EE to Spring tylko jeszcze gorszy:
- application servery, które nawet jak są osadzone to wstają 15 sekund (a czasem więcej),
- beznadziejne testowanie nawet w porównaniu do Springa
- no i totalny rak w postaci ludzi - architektów EE.
Samo community to przeważnie dośc fajni ludzie, ale to tyle. Staram się ich przesadnie nie obrażać, ale mi nie wychodzi.
Jak będziesz dużo czytał lub robił małe projekciki to bedzie Ci to całe java EE działalo, nawet JSF wtedy działa (masakra), ale jak tylko wejdziesz w projekty zespołowe to zobaczysz jakie to pokłady bagna generuje. Zupełnie niepotrzebnie. Praktycznie każdy projekt JavaEE (EJB, JSF) zawiera fragmenty (np. kombinacje adnotacji) które NIE POWINNy działać (z definicji), ale niestety przypadkiem działają na produkcji i wszyscy boimy się tego ruszać :-(
Jak zaczniesz drążyć kod od Adama Biena to zobaczysz kwiatki typu field based injections itp. Takich rzeczy w Springu juz się nie robi.
IMO nie ma wyjścia:
Renderowanie po stronie servera (renderowanie danych) praktycznie zawsze kończy się jakim rakiem. W dobie AJAX to jest po prostu niezgodność warstw architektury z protokołem (http
- rich client). Jak byśmy robili stronki totalnie bez JS to miało by to sens.
Do tego robienie Single Page applications jest całkiem fajne, nawet jak nie kochamy JS (wcale JS nie trzeba używać - KotlinJS, ScalaJS, typescript są OK).
Btw. zupełna ciekawostka: JSP wykorzystane jako jezyk templatów (podobnie jak Thymeleaf czy inne) i w połączeniu z architekturą SPA (np. angular, react, vue) jest całkiem OK. Jedyna wada JSP to taka to.. że "za łatwo zrobić skrót" i niestety w zasadzie wymaga istnienia application serwera.
0
jarekr000000 napisał(a):
Renderowanie po stronie servera (renderowanie danych) praktycznie zawsze kończy się jakim rakiem. W dobie AJAX to jest po prostu niezgodność warstw architektury z protokołem (http + rich client). Jak byśmy robili stronki totalnie bez JS to miało by to sens.
Do tego robienie Single Page applications jest całkiem fajne, nawet jak nie kochamy JS (wcale JS nie trzeba używać - KotlinJS, ScalaJS, typescript są OK).
Ciągle czekam, aż ktoś mnie przekona do dwuwarstwowych aplikacji. Kryterium, kiedy mi to spasuje, już pojawiało się w tym wątku: konzystentne metadane na froncie i backendzie, np reguły walidacji pól. Po jakiejś gównianej zmianie (rozmiar kołnierzyka z niewymaganego stał się wymagany, czy "aż" dodanie pola) żeby front z mocy ustawy robił się aktualny do reguł biznesowych.
1
AnyKtokolwiek napisał(a):
Ciągle czekam, aż ktoś mnie przekona do dwuwarstwowych aplikacji. Kryterium, kiedy mi to spasuje, już pojawiało się w tym wątku: konzystentne metadane na froncie i backendzie, np reguły walidacji pól. Po jakiejś gównianej zmianie (rozmiar kołnierzyka z niewymaganego stał się wymagany, czy "aż" dodanie pola) żeby front z mocy ustawy robił się aktualny do reguł biznesowych.
No i na to odpowiedź to: ScalaJS lub KotlinJS.
https://www.scala-js.org/doc/project/cross-build.html
Masz wtedy projekt złożony z 3 części:
shared - struktury danych, interfejsy, walidacje
client - to wyżej plus react (opakowany w Scalę) lub Angular lub cokolwiek
server - klasyka (również korzystający z shared). (normalna Scala na JVM)
To całkiem fajnie działa. Problem jest taki, że jak potrzebujesz zrobić naprawdę ładny i funkcjonalny frontend to znalezienie do tego profesjonalisty i do tego Scalowca może być wyzwaniem :-)
(co prawda można całkiem sprawnie mieszać TS, ScaleJS i JS wprojekcie, ale wtedy to już nie to samo).
Wada - jak nie jesteś Scalowcem - to ciężko Ci to bedzie w to wejść.
KotlinJS - będzie wejśc łatwo, ale do tego IMO jest mniej materiałów i gotowców (ale działa).
0
Wesprzecie ten wątek jakąś mądrą myślą?
REST API + Thymelaf - Architektura aplikacji webowej