W tym w logu opowiadam o technologiach, których nie warto się już uczyć. Są to technologie, które mimo wszystko cieszą się całkiem sporą popularnością i wielu zwłaszcza początkujących programistów często po nie sięga. Dlatego postanowiłem się zając tym tematem i trochę rozjaśnić kwestię czego warto, a czego nie warto się uczyć.
Poniżej znajdziesz link do playlisty z vlogiem:
Zapraszam także do moich warsztatów o architekturze warstwowej i architekturze heksagonalnej
I do kursu Hibernate i JPA
Vlog w wersji Audio:
Inne platformy podcastowe:
https://open.spotify.com/show/5HQFAJg0N4o9mDEze8WVvi?si=cc72277bbd834760
https://podcasts.apple.com/us/podcast/vlog-programistyczny/id1606703834
https://podcastsmanager.google.com/show?hl=pl&show=show:f0FRKrpSJZuEP1UQgm73vw
https://castbox.fm/channel/Vlog-Programistyczny-id4743197?country=us
https://podcastaddict.com/podcast/3783474
Transkrypcja
W pewnym momencie zacząłem usuwać z mojego CV pewne technologie, które znałem i z którymi pracowałem.
Dlaczego?
Bo nie chciało mi się tłumaczyć paniom z HRuów, że znam te technologie, ale nie chcę już z nimi pracować.
I czasem jest lepiej czegoś nie wiedzieć, bo omijają Cię sytuacje typu: Ty znasz technologię X? Bo właśnie mamy jakiś fackup, na produkcji i trzeba to na szybko poprawić.
Cześć witam Cię w kolejnym vlogu na moim kanale. Ja nazywam się Mateusz Dąbrowski. A dzisiaj porozmawiamy sobie o technologiach, które już powoli odchodzą,
albo takich, które nigdy nie były specjalnie popularne, a mogą wydawać się całkiem nowoczesne całkiem przydatne. I będą to oczywiście technologie związane z ekosystemem Java.
I jeśli masz w planach naukę Javy lub już poznałeś Javę i zastanawiasz się jakich technologii związanych z Java mógłbyś się nauczyć, to dzisiaj opowiem o rzeczach, których nie warto się uczyć, albo nawet trzeba ich unikać.
[Java EE, JSP, JSF]
I pierwszą z takich technologi, czy też specyfikacji związanych z Javą jest Java EE. Która kilka lat temu przeszła rebranding i teraz nazywa się Jakarta EE i od tam tego momentu właściwe słuch o niej zaginą.
Nikt nie mówi o Jakarta EE o tym jak jest fajna i w ogóle, mam wrażenie, że nastała trochę tak grobowa czisza jeśli chodzi o tę specyfikację.
Co prawda czasem jeszcze ktoś wspomina o Java EE i nawet początkujący programiści mówią o tej specyfikacji Java EE, mimo, że od rebrandingu minęło już prawie 3 lata.
Ale czym ta specyfikacja jest?
Java EE czy też Jakarta EE to specyfikacja, która zawiera zbiór standardów, które niegdyś służyły jako podstawa do budowania serwerów aplikacji.
I takimi serwerami są np. Jboss, który też przeszedł rebranding i stał się WaildFlayem, inne to np. Weblogic Oracla, czy WebSphere IBMa.
I jeśli taki serwer był zgodny z daną wersją specyfikacji, czy też standardu Java EE to znaczyło, że mógł obsługiwać technologi, które były zawarte w tym standardzie.
Wszystko byłoby fajnie, bo wszystkie serwery spełniały ten sam standard i teoretycznie aplikacje można było uruchamiać na dowolnych serwerze, kóry spełniał tę specyfikacje.
Ale niestety takie podejście ma bardzo dużą wadę. Rozwój takiego standardu jest bardzo powolny, a rozwój serwerów, opart o wolno rozwijające się standardy jeszcze wolniejszy.
Poza tym taka kompleksowa specyfikacja nie jest potrzebna w większości aplikacji, wiec używanie taki serwerów zbudowanych w oparciu o Javę EE nie wszędzie jest uzasadnione, zwłaszcza że są one bardzo rozbudowane i zwykle bardzo zasobożerne…
A świat it poszedł znacznie do przodu, rzeczy dzieją się bardzo szybko i standard Java EE przestał być używany, a został zastąpiony przez lżejsze i przede wszystkim szybko rozwijające się technologie, które nadążą za potrzebami rynku. I głównie mam tu na myśli Spring i cały ekosystem, który dookoła niego powstał. Więc szybki rozwój technologi pozostawił standard Java EE daleko w tyle.
Ale jakie konkretnie rzeczy są zawarte w tym standardzie?
Są to:
JSP (Java Serwer Pages), to technologia szablonów htmlowych dla Javy, która pozwala w budować aplikacje internetowe. I o ile w roku 2000 ta technologia była przełomowa dla Javy, to obecnie jest to bardzo słaba i nieefektywna technologi, Jeśli chodzi o budowanie frontendów. I generalnie nie wiele się zmieniła od czasów powstania.
I od tamtego czasu, budowanie frontendu aplikacji znacznie się zmieniło, bo dzisiaj głównie używa się do tego frameworeków Angular i React, czyli frontend robi się najczęściej w Javascripcie, czy też Typescripcie. Ewentualnie można użyć Thymeleafa ze Springiem.
Kolejna rzecz zawarta w JavaEE to JSF (Java Server Faces) – to kolejna technologia, która pomaga budować aplikacje webowe i to jest technologia, która oparta była o komponety.
W JSFach mamy komponenty, których możemy po prostu wklejać do naszego kodu i generalnie powinno to działać. Problem w tym, że nie do końca to działało poprawnie. Komponenty było bardzo trudno dostosować do swoich potrzeb.
i była to bardzo słaba technologia, bo zawierała dużo błędów. Generalnie pomysł był dobry tylko w praktyce się nie sprawdził i wykonanie było trochę słabe.
I tutaj taka ciekawostka jeśli chodzi o JSF. Autorem tego rozwiązania, była osoba, która nigdy nie robiła aplikacji webowych i niestety jak się zagłębimy w tę technologię to widać ten brak doświadczenia autora JSFów. Np. przetwarzania requesta HTTP w JSF ma aż 6 faz. Gdzie w rzeczywistości zapytanie http ma tylko dwie fazy, czyli zapytanie i odpowiedź.
Kolejna rzeczy zawarta w tym standardzie to EJB (Enterprice Java Bean), i tę technologię można porównać do beanów springowych, które służą do pobierania i utrwalania danych w bazie danych.
Ogólnie nie jest to, w sumie zła technologia. Wszystko w EJB robi się w dosyć prosty sposób przy pomocy adnotacji, też można te beany swobodnie wstrzykiwać do innych beanów, ale żeby urchuchomić EJB potrzebujemy serwera aplikacji. W springu te beany są o wiele prostsze, są o wiele prościej zrobione
I Springa możemy odpalić na serwerze typu Tomcat, które jest tylko kontenerem serwletów, a nie serwerem aplikacji, więc potrzebuje o wiele mniej zasobów, niż klasyczny serwer aplikacji. A jak używamy Spring Boota to mamy takiego Tomcata zintegrowanego z aplikacją. Więc wszystko jest małe i lekkie.
Ale nie wszystkie rzeczy zawarte w standardzie Java EE są kiepskie, bo np. bardzo powszechni używane jest JPA, czyli Java czy też Jakarta Persistence Api. I jest to api do utrwalania danych w bazach danych. JPA też dzięki popularności Hibernate’a jest powszechnie stosowane przy pobieraniu danych z bazy. Więc Jpa akurat warto znać.
I nie będę tu omawiał wszystkich elementów Java EE, bo dzisiaj większość rzeczy zastępuje Spring, wiec zamiast Javy EE po prostu lepiej jest uczyć się Springa.
Kolejna technologia to Swing, który służy do tworzenia aplikacji desktopowych w Javie. I jest on częścią Javy. I nie warto się go uczyć z kilku powodów.
Po pierwsze dzisiaj praktycznie, nie tworzy się aplikacji Desktopowych i jest to naprawdę bardzo mocny argument.
A jeśli się je tworzy takie aplikacje, to są to aplikacje hybrydowe, czyli takie, gdzie okno aplikacji jest zrobione w jakiejś natywnej technologii, a wewnątrz tego okna osadzona jest przeglądarka internetowa, w której wyświetlana jest aplikacja webowa zwykle stworzona w jakiejś technologi Javascriptowej.
I taką biblioteką, która pozwala tworzyć takie aplikacje desktopowe jest ElectronJs.
Kolejna rzecz jeśli chodzi o Swinga, to tworzenie aplikacji desktopowych w Springu jest dosyć toporne. Technologia ta powstała wiele lat temu i już przez wiele lat nie jest rozwijana,
a jest częścią Javy tylko ze wzglęu na kompatybilność wsteczną. Niestety jest jeszcze wiele aplikacji, które zostały stworzone w tej technologii i muszą być utrzymywane.
Wiec tworzenie aplikacji w tej technologi nie jest wygodne, nie jest też szybkie. Ogólnie Swing nie jest developer friendly.
I ta technologia przede wszystkim nie jest nowoczesna, więc ciężko dzisiaj budować aplikacje w nie nowoczesnej technologii, bo nikt nie chce tego kupować, i też nikt nie chce używać technologii, które nie pozwalają tworzyć nowoczesnych i nowocześnie wyglądających aplikacji.
Wiec, zamiast uczyć się Swinga, lepiej jest uczyć się budowania aplikacji webowych w Angularze i Springu.
Kolejna technologia, która jest już trochę bardziej nowoczesna to JavaFX
i biblioteka ta podobnie jak Swing też służy do budowania aplikacji Desktopowych. I miała ona być następcą Swinga,
miała ona być jego nowocześniejszą wersja i pozwalać na budowanie nowoczesnych aplikacji.
Kiedyś była częścią Javy, ale została wydzielona z niej i teraz funkcjonuje jako osobna biblioteka.
I faktycznie jest to nowocześniejsza wersja Swinga. Ale nadal problemem jest tutaj to, że w obecnych czasach powstaje niewiele aplikacji Desktopowych. I JavaFx tak naprawdę, jako technologia nie została nigdy zaadaptowana w firmach, i nie mowie tutaj o adaptacji na dużą skalę.
W ogóle ta technologia nie została zaadaptowana. Prawdopodobnie z tego względu, że bardzo długo była w fazie beta, i nikt nie chciał jej używać, bo miała dużo błędów,
Później została wydzielona z Javy co trochę oznaczało, że nie jest kluczowa dla twórców Javy.
I w trudno powiedzieć, czy ktoś tego używa produkcyjnie, bo nie słyszałem za bardzo o tym, żeby gdziekolwiek była używana produkcyjnie. Więc JavaFX to bardzo niszowa technologia, i ogólnie tworzenie aplikacje Desktowych, to już trochę niszowe zajęcie.
Więc tak samo jak poprzednio warto uczyć się, najnowszych technologii webowych.
Kolejna i chyba już ostatnia technologia którą wymienię, czy też biblioteka to Vaadin. Często na wielu grupach facebookowych, na których jestem, na pytanie czego użyć do frontendu pada odpowiedź Vaadin
i to nie jest dobra odpowiedź.
Co prawda Vaadina używa się w firmach, ale Vaadin jako framework frontowy, też nigdy nie był super popularny i teraz tym bardziej nie jest to popularne narzędzie.
Ale zacznijmy od tego dlaczego Vaadina poleca tak wiele początkujących osób.
Vaadin przy pierwszym zetknięciu może wydać się bardzo atrakcyjną technologią, bo pozwala stworzyć widok aplikacji, piszą tylko czystą Javę. Więc nie musisz uczyć się html i Cssa, żeby stworzyć dobrze wyglądającą aplikacje.
I to na pierwszy rzut oka wydaje się bardzo atrakcyjną opcją. I to tworzy takie efekt wow, bo wystarczy, że nauczysz się trochę Javy i już możesz tworzyć aplikacje webowe, które działając i dobrze wygląda.
I takie są pierwsze wrażenia przy zetknięciu Vaadinem. Ale skoro to wygląda tak fajnie przy pierwszym spojrzenie to dlaczego wszyscy nie używają Vaadina?
Problem jest taki, że to podejście działa w małej skali, w projektach demo i tutorialach. Przy średnich i większych aplikacjach, takie podejście staje się problematyczne.
Pisanie skomplikowanych widoku w Javie, jest dużo bardziej uciążliwe, niż pisanie samego html, zwłaszcza gdy widoki te są bardzo rozbudowane, wtedy rozbudowany html, nadal jest czytelny, a rozbudowany kod Javy już nie bardzo.
Największą zaleta html, to jego prostota. Znaczniki możemy zagnieżdżać, jeśli odpowiednio sformatujemy kod, to wszystko jest proste i czytelne. W Javie, żeby wszystko było proste i czytelne, trzeba kod dzielić na klasy i metody w tych klasach. I jeśli podzielimy sobie szablon pisany w javie na klasy i metody, to wtedy tracimy trochę z oczu kontekst, to jaki ten kod będzie generował, szablon. A w Htmlu wszystko jest dobrze widoczne.
Kolejny problem Vaadina, to może być trudno dostosować komponenty do swoich potrzeb, z racji tego, że są predefiniowalne i generowane. I to jest wadą wszystkich technologi, które dają nam predefiniowane komponenty.
I kolejna wada, która się z tym wiąże, to ciężko jest optymalizować takie komponentu. Więc jeśli chcemy używać Vaadina bez ingerencji w to jak działa i jak wygląda, to da się go używać, ale jak chcemy coś dostosować, to już jest gorzej.
Wieć development dużej aplikacji w Vaadinie, może nie być wcale taki prosty i szybki.
Vaadin powstał na bazie frameworka GWT, czyli Google Web Toolkit, stworzonego przez firmę Google. I framework ten pozwalał na tworzenie widoków aplikacji, przy użyciu czystej Javy, czyli jest corem Vaadina.
Ale GWT został porzucony przez firmę Google, a zamiast niego Google stworzyło Angulara.
Najpierw był to AngularJS, a później Angular, który jest teraz jednym z popularniejszych frameworków Webowy.
Więc skoro Google porzuciło GWT i stworzyła Angulara to dla mnie jest to jasny sygnał, że ta technologia na dłuższą metę się nie sprawdza i w dłuższej perspektywie spowalnia rozwój aplikacji, zamiast go przyspieszać.
Czego warto się uczyć?
Skoro wymieniłem już technologie, których nie warto się uczyć, i też już wspominałem trochę o tym czego warto, to teraz jeszcze tak szybko podsumuję, czego warto się uczyć zamiast wymienionych wyżej technologii.
Pierwsza rzecz jeśli chodzi o Javę to oczywiście Spring, bo jest to najpopularniejszy framework w Javie i jest wiele dostępnych materiałów na jego temat. Trzeba go koniecznie znać.
Jeśli nie jesteś Javowvcem to warto uczyć się najpopularniejszego frameworka w danym języku. Bo popularne narzedzia, oznaczając zwykle dużą dostęność nateriałów i łątwość uczenia się oraz używania danego narzędzia.
Kolejna rzecz w Javie to Hibernate, który załatwia wiele spraw związanych z zapisem i odczytem danych do bazy.
Następna rzecz to tworzenie REST APi, bo dzisiaj większość aplikacji buduje się na Rest api. Zapraszam oczywiście do mojego materiału “Wszystko o Rest Api” gdzie znajdziesz wiele informacji na temat budowania api, link umieszczę tutaj na karcie.
A jeśli chcecie robić i frontend i backend to warto zainteresować się Angularem lub Reactem. Bo to są najczęściej używane frameworki frontendowe do budowania nowoczesnych aplikacji.
A jak za bardzo frontend Cię nie interesuje, ale potrzebujesz stworzyć dla swojej aplikacji jakieś widoki, albo chcesz chociaż trochę poznać frontend, żeby cokolwiek wiedzieć, to możesz także skorzystać ze Spring i z Thymeleafa, czyli systemu szablonów dla Spring. Thymeleafa co prawda nie jest już za bardzo popularny, ale można go jeszcze wykorzystać do celów edukacyjnych.
I to już wszystko w dzisiejszym odcinku, mam nadzieję, że Ci się spodobał jak zwykle zachęcam do zasubskrybowania mojego kanału jeśli jeszcze tego nie robisz, zostawienia łapki w górę i podzielenia się swoją opinią w komentarzu. Dzięki i do zobaczenia w następnym materiale.
