Życie po Springu?

0

W ostatnich dniach padło tu zdanie, nie umiem go znaleźć, cytuję z głowy:

"skoro Kotlin się przyjął, to może po Springu też coś się pojawi"

Co by taki produkt miał zawierać, jak by musiał być, aby zastąpić Springa?

Wg mnie Spring nie wprowadza czegoś radykalnie nowego intelektualnie, jest tylko rozległy.
Ja osobiście lubię małe sprytne, ale niekoniecznie pojawiający się mały sprytny produkt by mógł zastąpić Sringa w powiedzmy mocno rzemieślniczej (by nie powiedzieć pańszczyźnianej) powszedniej robocie ...

10

No po Springu pewnie będzie Summer

4

To nie jest kwestia co musi mieć a raczej kwestia że musi się przyjąć. To taka trochę rekurencyjna definicja :D Bo czemu Spring jest popularny? Ano, bo jest popularny! Bo łatwo znaleźć developera który go zna, bo łatwo nowy developer może się odnaleźć w projekcie. Bo jest spora szansa że za 3 czy 5 lat nadal będzie na rynku, nadal będzie aktualizowany itd.

Na fenomen kotlina składa sie kilka aspektów:

  • brak dostępu do nowego JDK na Androidzie
  • dobry support ze strony IntelliJ
  • wsparcie poważnej firmy która raczej nagle nie zniknie

Te rzeczy sprawiły że pisanie w Kotlinie było dość "bezpieczne".

2

Wg mnie Spring nie wprowadza czegoś radykalnie nowego intelektualnie, jest tylko rozległy.
Ja osobiście lubię małe sprytne, ale niekoniecznie pojawiający się mały sprytny produkt by mógł zastąpić Sringa w powiedzmy mocno rzemieślniczej (by nie powiedzieć pańszczyźnianej) powszedniej robocie ...

Mam nadzieję, że następca będzie po prostu napisany z myślą o tym, że szary programista jednak nie wie, co poeta miał na myśli, oraz że popełnia różne błędy. Moje wrażenia odnośnie Springa są takie, że miał być chyba takim idiotoodpornym kombajnem, który paroma "magicznymi" trikami obskoczy wszystko i wszystko zrobi, i nawet największy idiota nie mógłby tego zepsuć.

A jednak potem przychodzą ci źli, niedoskonali programiści, którzy jak jacyś zwykli ludzie popełniają błędy - jak mają odrobinę szczęścia to kontekst się wywali i do widzenia, jak mają pecha to z pozoru wszystko będzie śmigać, a w praktyce niekoniecznie. I weź potem odnajdź się w gąszczu CGlibów, Proxy, Managerów, Contextów i przebrnij przez to całe arcydzieło (java.lang.)Object Oriented Programmingu. Nie jest to technicznie trudne zadanie, nie jest niewykonalne, ale jest najzwyczajniej w świecie uciążliwe przez cały ten narzut związany z przedzieraniem się przez Springową magię, którą zazwyczaj Spring skrzętnie ukrywa przed programistą, by nie zrobił sobie kuku.

0

@superdurszlak z drugiej strony odnalezienie się w martwym hipsterskim frameworku ktory umarł 3 lata temu i słuch po nim zaginął, a który jest wspomniany w internecie tylko w jakimś jednym tutorialu, może być mimo wszystko o wiele trudniejsze ;)

2

Ehhh moim zdaniem jesteście naiwni.

**Świat chce magii!!! **

Świat chce, żeby przyszedł student, szybko się nauczył używać gotowych bloczków i składał z nich produkt i schematycznie kodził używając tego narzędzia (bez wnikania co pod spodem). To dążenie jest widoczne od lat z lepszym lub gorszym skutkiem. Spring się trzyma i będzie. Jak powstanie coś nowego, a powstanie, to nadal będzie narzędzie do szybkiego bezmyslnego kodzenia - bo takie są idee takich narzędzi :)

0

Oprócz tego co napisał @Shalom jest jeszcze jedna istotna rzecz, przejście dla java deva do kotlina jest praktycznie bezbolesne. Prawda jest taka że wystarczy nauczyć się składni żeby i można klepać jak w javie, nie używając nowych rzeczy z Kotlina. I też to będzie działać.

Z wygryzieniem Springa będzie trudniej, bo Spring zazwyczaj ma do wszystkiego wsparcie. Wymaga bardzo mało od developera, a sam bardzo dużo robi za niego.

0

@superdurszlak:
Weź jeszcze pod uwagę że Spring to nie tylko całe to AOP i IoC. Spring ma też dużo usprawnień takich jak jakieś RestTemplety, JdbcTemplaty, ułatwia korzystanie z Java Mail itp.
Można powiedzieć że z jednej strony kobyła, a z drugiej nawet wiele (opcjonalnych) narzędzi ;)

0
scibi92 napisał(a):

@superdurszlak:

Weź jeszcze pod uwagę że Spring to nie tylko całe to AOP i IoC. Spring ma też dużo usprawnień takich jak jakieś RestTemplety, JdbcTemplaty, ułatwia korzystanie z Java Mail itp.
Można powiedzieć że z jednej strony kobyła, a z drugiej nawet wiele (opcjonalnych) narzędzi ;)

Z tą "opcjonalnością" to bym nie przesadzał. Kilka lat temu użyłem JdbcTemplate w desktopie (nie było / nie znałem innych lib do nazwanych parametrów JDBC). Dependecnji 50 MB (aż po aspektowe, których nie było powodu używać), czas wstawania wydłużył się o wiele sekund,
Dependency hell, to jest to

0
AnyKtokolwiek napisał(a):

Z tą "opcjonalnością" to bym nie przesadzał. Kilka lat temu użyłem JdbcTemplate w desktopie (nie było / nie znałem innych lib do nazwanych parametrów JDBC). Dependecnji 50 MB (aż po aspektowe, których nie było powodu używać), czas wstawania wydłużył się o wiele sekund,
Dependency hell, to jest to

Nie chcę wyrokować, ale... jakiś czas temu widziałem materiał o tym skąd Spring Boot wie jakie zależności ma dołączyć. Konkretnie ten:

Z tego co pamiętam, generalnie sami możemy przypadkowo wymusić na boocie pobranie dependencji która nas kompletnie nie interesuje. Poza tym zawsze można sterować, albo ręcznie dołączając paczki albo jakieś exclusions. Lub nawet kompletnie zrezygnować z boota i sterować wszystkim samodzielnie.
Ale generalnie masz rację, Spring zaciąga sporą ilość zależności.

3
Korges napisał(a):

Z tego co pamiętam, generalnie sami możemy przypadkowo wymusić na boocie pobranie dependencji która nas kompletnie nie interesuje. Poza tym zawsze można sterować, albo ręcznie dołączając paczki albo jakieś exclusions. Lub nawet kompletnie zrezygnować z boota i sterować wszystkim samodzielnie.
Ale generalnie masz rację, Spring zaciąga sporą ilość zależności.

Z drugiej strony to chyba nie na tym miało polegać, że Spring / Spring Boot niby ułatwia życie dając paczki do wszystkiego, a jak przyjdzie co do czego to trzeba się użerać żeby zależności nie wywaliło w kosmos.

Druga sprawa, to podbijanie wersji w Springu - mam teoretycznie wszystko skonfigurowane (mniej lub bardziej zgodnie ze sztuką - nie mnie oceniać co jest zgodne ze sztuką), aplikacja działa, wstaje, testy zielone, wszystko cacy.

A potem zmieniam wersję dowolnej Springowej dependencji z dajmy na to 2.1.x na 2.4.y (numery zmyślone). I bęc, wszystko leci w kosmos

  • W dependencjach plątaniec, bo którejś paczce zmieniły się zależności
  • Jak już plątaniec wydaje się być rozplątany to kontekst nie wstaje, bo okazuje się że masz teraz dwa KasztanBeany i Spring nie się co robić - a Ty nie wiesz skąd ten drugi bean
  • Jak już ustalisz skąd to zamieszanie i wydaje się, że problem jest rozwiązany to okazuje się, że teraz masz 0 KasztanBeanów i kontekst znów nie wstaje
  • Jak już rozwiążesz problem z KasztanBeanem odkrywasz, że przestały działać np. konfiguracje sekórity i można mieć wjazd na admina bez admina
  • Wymyśl sobie jeszcze 0..* takich problemów

Nie mówiąc o tym, że prawie pusty serwis ze śladową ilością (jawnych) dependencji potrafi sobie wstawać np 20s albo 30s :]

0

@superdurszlak: to może masz HDD i3 i 1GB bo u mnie wstaje kilkanaście sekund apka z kilkoma tabelami i z jakimś grafem obiektów, do tego flyway na start :D

2

@superdurszlak: w ogóle propo tego problemu z zależnościami, to miałam jeden projekt, który używał bazela zamiast mavena czy gradle'a. Oczywiście psioczyłam na teog bazela niemozliwie :D Aczkolwiek w bazelu nie jest tak, że dodajesz spring-boot i działa (szok!), ten system budowania nie zaciąga pośrednich zależności. Na początku to było mega irytujące, trzeba było definiować wszystkie zalezności ale potem wspominając inne projekty pomyślałam, że to fajne. Wtedy wiadomo, że w całymprojekcie masz wersję x danego modułu springa czy biblioteki nie musisz excludować itp. Masz kontrolę bardziej oczywistą. Ideą springa jest żeby dodać tego startera i wzystko śmigało, ale to drugie podejscie jest fajne, w kontekście wielu różnych zależności.

3

Wtedy wiadomo, że w całymprojekcie masz wersję x danego modułu springa

maven i dependencyManagement też to załatwia ;)

superdurszlak

Jedyny problem z migracją jaką widziałem to kiedy Spring Boot zmienił format jara, nigdy wcześniej ani później. Podbijam wersje i działa od ręki ;)

1
Shalom napisał(a):

Jedyny problem z migracją jaką widziałem to kiedy Spring Boot zmienił format jara, nigdy wcześniej ani później. Podbijam wersje i działa od ręki ;)

A podbijałeś kiedyś wersję Spring Boota z 1.5 do 2.2 w projekcie z OAuth2? xd Nie polecam.

1
AnyKtokolwiek napisał(a):

Co by taki produkt miał zawierać, jak by musiał być, aby zastąpić Springa?

Spring będzie zastąpiony w przeciągu paru lat, jeżeli nic nie zrobią ze wstrzykiwaniem zależności na etapie kompilacji oraz kompilowania kodu aplikacji do kodu natywnego systemu operacyjnego. Spring był pisany kiedyś jak jeszcze nieznane były mikroserwisy i ciągnie za sobą dług w tej postaci. Nie będę tutaj się rozwodzić. Są frameworki, które są już pisane w tzw. cloud-native np. Quarkus pod flagą RedHata, stąd noo... Jeżeli wciąż chmura będzie tak forsowana jak teraz i tzw. serverless to nie widzę Springa w przyszłych 10 latach jako wiodącego frameworka. Jedynym plusem jaki jest teraz, jest to, że masa ekosystemów jest postawiona na Springu i będzie podobnie jak z Javą EE, że nie będzie sensu tego przepisywać. Choć mogę się mylić.

1

Byl moment ze wszyscy dużo osób mysleli ze groovy on grails go zastapi, no ale jednak nie wyszło

0

oraz kompilowania kodu aplikacji do kodu natywnego systemu operacyjnego

Że co? Jak ma się to do Springs I czemu miałaby to być zaletą?

0
scibi92 napisał(a):

oraz kompilowania kodu aplikacji do kodu natywnego systemu operacyjnego

Że co? Jak ma się to do Springs I czemu miałaby to być zaletą?

*Przede wszystkim jest to wstrzykiwanie zależności na etapie kompilacji, co znacząco skraca czas uruchamiania aplikacji. Drugą ważną zaletą jest możliwość skompilowania kodu aplikacji napisanej przy pomocy Micronauta i Quarkusa to kodu natywnego systemu operacyjnego, co znacząco podnosi wydajność takiej aplikacji i zmniejsza jej zapotrzebowanie na pamięć. *

Tutaj o tym kiedyś czytałem, daję cytat.
https://bulldogjob.pl/news/901-spring-micronaut-czy-quarkus

1 użytkowników online, w tym zalogowanych: 0, gości: 1