Ż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".

1

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.

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