To jest 230. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o tym, co słychać na frontendzie i jak zmieni to AI. 

Notatkę, linki oraz transkrypcję do dzisiejszego odcinka znajdziesz pod adresem porozmawiajmyoit.pl/230. 

Zastanawiasz się nad zmianą pracy, ale gdy przeglądasz oferty na popularnych stronach, to nie jesteś przekonany czy młody, dynamiczny zespół oraz owocowe środy są dla Ciebie? Na szczęście jest SolidJobs, portal z ofertami pracy dla ludzi, którzy chcą wiedzieć, ile będą zarabiać, z jakimi technologiami i nad jakim projektem będą pracować. Solidne oferty pracy znajdziesz na Solid.Jobs. 

Podcast Porozmawiajmy o IT jest dostępny zupełnie za darmo. Obowiązuje tylko jedna zasada: jeśli jesteś tu przynajmniej po raz drugi, to po pierwsze rozgość się, a po drugie odwdzięcz za te treści, wystawiając ocenę w Twojej aplikacji podcastowej lub polecając odcinek w social mediach. Dziękuję. 

Ja się nazywam Krzysztof Kempiński. Moją misją jest poszerzanie horyzontów ludzi z branży IT, co realizuję m.in. poprzez ten podcast. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! 

Dzisiaj moimi gośćmi są znani i lubiani Przeprogramowani, czyli Przemek Smyrdek i Marcin Czarkowski, którzy od ponad czterech lat dzielą się wiedzą o branży nowych technologii i zachęcają do szerszego spojrzenia na świat programowania w ramach swojej platformy przeprogramowani.pl. 

Zdobywali doświadczenie w globalnych firmach produktowych, na stanowiskach Engineering Managerów i Liderów Technicznych. W ich szkoleniach brały udział setki zadowolonych studentów i pasjonatów programowania. Przemek, Marcin, bardzo miło mi po raz kolejny gościć Was tutaj w podcaście. 

 

Marcin Czarkowski: Cześć. 

 

Przemek Smyrdek: Cześć. 

 

Kiedy odezwał się do mnie Przemek z tym tematem, o którym dzisiaj będziemy mówić, odezwał, to stwierdziłem, że to jest bardzo fajny moment, żeby do tematu frontendu wrócić, bo dosyć dawno w ramach Porozmawiajmy o IT frontendu nie było, a dzisiaj taką wisienką na torcie jeszcze będzie tutaj dodanie AI i porozmawiamy o tym, jak AI na frontend jako taki wpłynie, ale również myślę na samo tworzenie frontendu, co też jest, myślę, istotnym wkładem tej technologii. 

U mnie właściwie od naszego ostatniego spotkania, co prawda nagrywaliśmy tutaj osobno i z Przemkiem i z Marcinem odcinki, które oczywiście w notatkach będą podlinkowane, tak że też zapraszam, ale jeśli chodzi o samą procedurę, to nic się nie zmieniło. A oprócz tego, Panowie, że tworzycie już właściwie dwa swoje podcasty, to też z tego co wiem, czerpiecie wiedzę, czerpiecie informacje z innych podcastów, więc jestem bardzo ciekaw, co Przeprogramowani słuchają sobie w swoich podcastodbiornikach. 

 

MC: To może ja zacznę. Ostatnio u mnie takim regularnym podcastem, do którego wracam co weekend i tutaj pewnie kradnę również jedną z propozycji Przemka, jest podcast All In, w których czterech inwestorów z Doliny Krzemowej dzieli się swoją wiedzą na temat nie tylko startupów, ale również ekonomii, technologii. Tak więc jest to świetny sposób, żeby dostawać informacje prosto ze źródła, prosto od osób, które współpracują z największymi biznesami, które inwestowały we wczesnych latach w Ubera, Twittera. Więc to jest świetna informacja. Np. dzięki nim dużo szybciej dowiedziałem się o nadchodzącym kryzysie na rynku technologicznym. Tam już na początku 2020 roku były sygnały właśnie od tych twórców, że będzie ciężko. Do nas to przyszło z lekkim opóźnieniem, więc fajnie było wiedzieć po prostu z wyprzedzeniem. Taka moja rekomendacja. 

 

PS: Jeśli chodzi o mnie, to na pewno Joe Rogan i Lex Fridman, czyli takie bezpieczne typy nadal są grane na platformach streamingowych, ale ostatnio zacząłem też eksplorować świat polskich podcastów, czego dawniej nie robiłem i takie podcasty jak chociażby Dział zagraniczny albo Podcastex, czyli tytuły, które z jednej strony dają wiedzę o świecie, ale też pozwalają się zrelaksować, są tym, co włączam na słuchawkach coraz częściej. 

Podobnie jak Marcin, też jeśli chodzi o amerykańskie, zagraniczne podcasty, to staram się być na bieżąco z Doliną Krzemową, ze światem biznesu, bo zazwyczaj to z pewnym opóźnieniem, ale jednak przychodzi do Europy, ma jakiś wpływ na to, co my robimy i w tym ekosystemie programistycznym w ten czy inny sposób się roznosi. Więc podcasty Dział zagraniczny, Joe Rogan, Lex Friedman, też Modern Wisdom, takie tematy, które w tym ekosystemie IT rozwoju dość często się pojawiają. 

 

Świetnie, bardzo dziękuję za te rekomendacje. Myślę, że każdy ze słuchaczy, kto miał z Wami do czynienia z Waszymi treściami płatnymi lub też bezpłatnymi, wie, że macie dużo doświadczenia nie tylko we frontendzie, ale to jest jak gdyby taka nadal jeszcze główna działka Waszej działalności. Ci wszyscy, którzy mieli okazję się z tymi materiałami zetknąć, wiedzą, że tworzycie jakościową treść i że wiecie, o czym mówicie. Ale chciałbym Was poprosić, żebyście dla tych, którzy tutaj może po raz pierwszy się na Was w tym podcaście natknęli, żebyście powiedzieli, jaki jest Wasz background zawodowy, żeby dać taki trochę social proof tego, że pytam właściwe osoby o stan frontendu na ten rok. 

 

PS: To tutaj może pozwolę sobie zacząć. Te nasze ścieżki przecinają się od jakiegoś czasu, kiedyś były różne, teraz są bardziej tożsame, więc myślę, że każdy tutaj opowie co nieco o sobie. W moim przypadku ta przygoda z programowaniem i z frontendem to już jest około 10 lat doświadczenia komercyjnego. Zaczynałem w jednym z największych polskich software house’ów. gdzie miałem okazję pracować jako Fullstack Web Developer i łączyłem swoją pracę pomiędzy światy .NET i JavaScriptu i konsekwentnie w kolejnych latach przesuwałem się bliżej tej warstwy interfejsu użytkownika, przechodząc przez różne firmy. 

Pracowałem w mniejszych, większych firmach, chciałem cały czas zaspokoić tę moją wewnętrzną ciekawość, która po prostu mnie motywuje, to jest taki mój driver. Chcę rozumieć, czym tak naprawdę jest programowanie niezależnie od skali. Więc miałem okazję budować frontend w małych startupach, miałem okazję budować frontend w scaleupach krakowskich, m.in. takich, gdzie przecinaliśmy się razem z Marcinem, w zależności od timeline’u, czy w dużych korporacjach, gdzie świat programowania był już poukładany, no ale z kolei ja próbowałem na niego spojrzeć bardziej od takiej strony menadżerskiej. 

Myślę, że akurat w moim przypadku to przekrojowe doświadczenie pozwoliło mi chociażby nabrać takiego dystansu do tego, czym tak naprawdę ten frontend jest, bo czasami zauważam taką tendencję wśród programistów, że oni mają tą swoją jedną wyuczoną wersję frontendu, tę definicję tego ekosystemu frontendowego i niekoniecznie chcą eksplorować czy to inne frameworki, czy to inne technologie. Wydaje mi się, że ja bardzo szybko nabrałem tego dystansu i to właśnie było dzięki temu podróżowaniu pomiędzy różnymi firmami. Oddaję głos Marcinowi. 

 

MC: U mnie również podobnie, 10 lat doświadczenia. Ja początek swojej kariery spędziłem głównie w startupach. Tutaj dominowała chęć sprawczości, nauki, rozwijania się pod wieloma różnymi względami. Ja zawsze taką osobą byłem i nadal nią jestem. 

Następnie ostatnia praca na etacie, którą miałem tutaj przyjemność wykonywać, to był Smart Recruiters, gdzie byłem liderem technicznym platformy frontendowej. To było bardzo ciekawe doświadczenie dla mnie, bo miałem okazję zejść poziom niżej, jeżeli chodzi o aspekty techniczne, czyli tworzyć tooling, narzędzia i wszelkiego rodzaju rozwiązania, które wspierały i przyspieszały pracę moich kolegów z pracy i innych frontend inżynierów. 

To było dla mnie bardzo ciekawe nie tylko od tej strony technicznej, ale również od tej strony produktowej kontaktu z ludźmi, rozumienia ich potrzeb, wyszukiwania ich oczekiwań, które nie zawsze są jasne i trzeba się nauczyć z ludźmi rozmawiać, wyciągać z nich tę wiedzę, bo to właśnie użytkownicy najlepiej wiedzą, czego potrzebują, ale nie zawsze są w stanie to sformułować, a my nie zawsze jesteśmy w stanie ich zrozumieć, więc tego mnie bardzo ta praca w tym zespole dużo nauczyła. I wydaje mi się, że to jest istotne również, aby programiści takie nastawienie gdzieś tam budowali, niezależnie czy tworzymy rozwiązania wewnątrz firmy, czy na zewnątrz, zawsze musimy pamiętać, że użytkownik jest najważniejszy i to on lepiej rozumie swoje problemy niż my, mimo że czasami wydaje nam się, że jest na odwrót. 

 

Super, dzięki za to przedstawienie Waszego doświadczenia. Powiedzcie natomiast, gdzie tutaj znalazło się dzielenie wiedzą? Skąd to się wzięło? Jaką ścieżkę musieliście przejść, żeby to się mogło przerodzić w jakiś rodzaj biznesu? 

 

PS: Ja tutaj wspominałem, że te nasze ścieżki związane z dzieleniem się wiedzą przecinały się, były mniej lub bardziej rozłączne w tych ostatnich latach, a to wszystko za sprawą na początku naszych prywatnych inicjatyw, każdy z nas, zarówno ja, Marcin, jak i Adam Gospodarczyk, z którym współpracowaliśmy na początku Przeprogramowanych, starał się w internecie działać. W przypadku Marcina to było algosmart.pl, w moim przypadku to było Poznaj programowanie, i na początku działał jeszcze z nami Adam, czyli Overment. 

Przez to, że działaliśmy w sieci, dość szybko zaczęliśmy się gdzieś przecinać w tych komentarzach, na meetupach, wtedy też wszyscy mieszkaliśmy dość blisko, w Krakowie, więc zaczęliśmy myśleć o jakiejś wspólnej inicjatywie. I na jednym z takich wypadów na miasto narodził się pomysł rozkręcenia Przeprogramowanych. Wtedy nie wiedzieliśmy jeszcze, czym ci przeprogramowani tak naprawdę mają być, ale wiedzieliśmy, że chcemy o programowaniu mówić troszkę inaczej, niż mówiło się, powiedzmy, w takiej powszechnej świadomości. 

To, o czym wspomniał Marcin, czyli taki mindset produktowy, mindset skupiony na użytkowniku, to było coś, czego zbyt często nie widzieliśmy w takiej przestrzeni publicznej, w tym świecie programowania, bo tam przewijały się takie tematy jak właśnie frameworki, języki programowania, biblioteki, czyli taki bardzo mocny techniczny mindset. A my chcieliśmy pokazać, jak programowanie można połączyć np. ze światem biznesu, ze światem zarządzania produktem, ze światem zbierania jakiegoś feedbacku, ze skuteczną komunikacją. 

Na początku ten pomysł był dość typowy, bo postawiliśmy na artykuły, czyli blogi, to tak naprawdę co robiliśmy, tylko tym razem już nie solo, tylko właśnie wspólnie. I zaczęliśmy po jakimś czasie eksperymentować z YouTubem, chociaż tutaj Marcin pewnie też zgodzi się ze mną, te nasze początki YouTuba to nie były najbardziej naturalne doświadczenia. Było tam sporo stresu, nagrywania telefonem gdzieś tam z samochodu, z różnych dziwnych miejsc. Bardzo dużo krępowania się, przynajmniej w moim przypadku, żeby gdzieś tam włączyć kamerę i wyjść przed szerszą publiczność. Ale tak naprawdę to się zaczęło kręcić i po pięciu latach jesteśmy w tym miejscu. 

Myślę, że Przeprogramowani są też o tyle ciekawym projektem, że każdy z nas trochę inaczej na ten projekt patrzy. Każdy tam sobie troszkę inny aspekt tej działalności znajduje, lubi robić nieco inne rzeczy i cały czas na dzisiaj jest na to miejsce. Przynajmniej z mojej perspektywy to jest świetne. 

 

Później natomiast, czy właściwie równolegle, pojawia się jakaś idea, żeby być może zmonetyzować trochę tę działalność, żeby przekazać trochę tej wartości odbiorcom, osobom, które na takiej fali rosnącej popularności frontendu, jakby nie było, być może chcą do branży IT wskoczyć. Tutaj Wasz pomysł na Opanuj JavaScript jako kurs. Może zdradzicie trochę, jak to wyglądało, skąd ten pomysł, czy to jest taka idea, którą możecie odznaczyć jako sukces na Waszym koncie? 

 

MC: Myślę, że jak najbardziej. Inspiracją dla nas były sukcesy pierwszych twórców, którzy również dzieli się wiedzą za pieniądze. Maciej Aniserowicz pokazał, że można robić naprawdę fajne rzeczy biznesowo w tej sferze. Za granicą John Sonmez, który gdzieś tam mnie osobiście inspirował swoimi kursami. 

Tego robiło się coraz więcej, my tę działalność prowadziliśmy za darmo, sprawiało nam to dużo przyjemności i też pochłaniało dużo naszego czasu, więc stwierdziliśmy, że jeżeli mamy to robić na dłuższą metę i cały czas podnosić jakość, to musimy gdzieś tam tę działalność monetyzować. 

I tak też zresztą zrobiliśmy za pośrednictwem tego pierwszego kursu Opanuj JavaScript, tutaj również było bardzo dużo stresu i jakieś niepewności, jak to wszystko zrobić, pierwszy raz zawsze jest najtrudniejszy, ale ten stres okazał się, myślę, czymś pozytywnym dla tego produktu, bo myślę, że zrobiliśmy naprawdę fajną rzecz i wiele kursantów powiedziało nam, że to było doświadczenie, które ciężko było znaleźć w jakimkolwiek innym miejscu, w jakimkolwiek innym kursie, bo ten stopień interakcji z nami był na naprawdę wysokim poziomie, z perspektywy czasu chyba na zbyt wysokim, zwłaszcza w tak moim zdaniem atrakcyjnej cenie, bo robiliśmy code review do ponad 60 zadań, 9 projektów, cokolwiek ktoś tam po prostu w tym kursie napisał, to my byliśmy gotowi, żeby to sprawdzić, ocenić, i myślę, że to nie jednej osobie naprawdę pomogło w przyspieszeniu rozwoju tej kariery i po prostu wbiciu się do tej branży IT. 

Więc ja ten projekt wspominam bardzo, bardzo miło i, mimo że poświęciliśmy na niego tak dużo czasu i tak dużo pracy. Pewnie niedługo przyjdzie odświeżona wersja tego kursu, ale w międzyczasie mamy też inne projekty, pewnie o nich pogadamy. 

 

Tak, z pewnością. Właśnie, mówimy dzisiaj, czy będziemy chcieli mówić o frontendzie, o tym, gdzie on jest, jakie perspektywy może mieć przed sobą, jak te pojawiające się trendy technologiczne mają szansę odcisnąć swoje piętno na frontendzie. I oczywiście można byłoby rozpocząć tutaj od technikaliów, to jest to, co tygryski lubią najbardziej, z pewnością, wielu słuchaczy właśnie na Wasze przewidywania, Waszą wyrocznię czeka. 

Oczywiście spokojnie, dojdziemy do tego, ale myślę sobie, że takiego pełnego obrazu frontendu nie byłoby, jeśli nie poruszylibyśmy tematu rynku pracy, tematu, który z bardzo oczywistej rzeczy, że po prostu praca leży, wystarczy się po nią tak gdzieś tam schylić, że każdemu się należy, przeszedł w coś, co być może nie jest już taką oczywistą oczywistością, coś co ostatni rok zwłaszcza gdzieś tam lekko podważył i od strony technologicznej, i od strony takiej gospodarczo-ekonomicznej. 

Jestem ciekaw Waszej opinii na temat tego, gdzie obecnie rynek pracy w tym 2024 roku jest i jak on ma szansę wpłynąć na branżę frontendu aplikacji webowych głównie. 

 

PS: Może ja pozwolę sobie zacząć. Ja myślę, że żyjemy w szalenie interesujących i ciekawych czasach, niekoniecznie łatwych, ale w czasach, kiedy naprawdę sporo się dzieje na świecie, i myślę, że tutaj warto porozmawiać najpierw o takim big picture, czyli porozmawiać o tym, gdzie my się właściwie znajdujemy, jeśli chodzi o świat, jeśli chodzi o gospodarkę, jeśli chodzi o sytuację na świecie. Bo to wszystko właśnie potem przekłada się na biznes, przekłada się na to, jak wygląda prowadzenie firm, przekłada się na kolejne rundy inwestycyjne, a na końcu przekłada się na to, ilu programistów np. te firmy chcą zatrudniać. 

Myślę, że nie muszę tutaj nikomu przypominać, że tak naprawdę spore kryzysy, spore czarne łabędzie za nami, tzn. najpierw COVID, potem wybuch wojny na Ukrainie, rosnąca inflacja, gdzieś tam wzrost stóp procentowych, to wszystko sprawia, że po prostu cały ten rynek i ekonomia po prostu przeszły przez taki solidny wstrząs i to w pewnym sensie musiało się jakoś odbić na modelu zatrudnienia w firmach, na tym, kim jest oczekiwany profil pracownika w tych dzisiejszych czasach, ilu tych pracowników te firmy potrzebują, ile pieniędzy będą chciały wykładać. 

Wydaje mi się, że przynajmniej w tej naszej 10-,12-letniej przygodzie z programowaniem to jest chyba taki najmocniejszy moment, kiedy programiści zaczęli interesować się tym, co dzieje się właściwie za oknem. Bo ja przyznam, że w pierwszych latach mojej kariery to było w zasadzie zbędne, bo pieniądze się zgadzały, pensja przychodziła na czas, pensja rosła rok do roku tak naprawdę, awanse również były w zasięgu ręki. 

A dzisiaj żyjemy w takich czasach, że co jakiś czas na dużym portalu internetowym pojawia się informacja, że zwalnia Google, zwalnia Discord, zwalnia Amazon, zwalnia Intel i inne firmy. I to na pewno przekłada się tak naprawdę na podejście do programowania, na rozumienie tego kim jest właśnie dobry programista, co on właściwie powinien potrafić, czy warto się specjalizować, czy tym razem wchodzimy w taki okres, gdzie być może jakaś szersza dynamika tego naszego rynku jest bardziej preferowana. 

Wydaje mi się, że to jest taki background, bez którego trudno mówić o zmianach, jeśli chodzi o programowanie, jeśli chodzi o frontend. Frontend to jest w pewnym sensie konsekwencja tego, co się działo. Tutaj bym też pewnie może oddał głos Marcinowi, żeby już uszczegółowił to, co ja mówię. Ale myślę, że żyjemy w takich czasach, kiedy programiści też właśnie zaczęli liczyć stan swojego konta, kiedy zaczęli patrzeć, czym tak naprawdę jest zarządzanie karierą, kiedy opłaca się zmieniać firmę, kiedy nie opłaca się zmieniać firmy. 

I też wiele z nich na pewno zderzyło się ze ścianą, co wcześniej mogło się nie zdarzać, bo firmy naprawdę zatrudniały na potęgę, zatrudniały na zapas, bo były po dużych rundach inwestycyjnych. No i myślę, że jesteśmy w zupełnie innym miejscu. Teraz tutaj pewnie też Marcin, Tobie bym taką piłkę wypuścił, bo sporo o tym rozmawiamy, gdzie tak naprawdę dzisiaj ten nasz frontend i programowanie jest. 

 

MC: Dzięki za ten big picture. Nie mam tutaj wiele do dodania. Myślę, że możemy przejść do tego naszego frontendu, na którym jest o dziwo całkiem spokojnie, jeżeli porównamy sobie z tym, co się dzieje na zewnątrz. Frontend zawsze gdzieś tam był takim dzikim zachodem, miejscem, gdzie bardzo dużo się dzieje, codziennie był nowy framework podobno i w ogóle nie dało się nad tym wszystkim nadążyć, a wygląda na to, że te ostatnie lata takie chaotyczne właśnie na frontend przyniosły stabilizację. 

Mamy tę wielką trójkę pod postacią Reacta, Angulara i Vue. React zdominował rynek, ma około połowę, reszta dzieli się tym, co zostało, i widać też dominację frameworka Next.js, który również tego Reacta samego poukładał, sprawił, że można szybko, produktywnie i w miarę w podobny sposób w wielu zespołach funkcjonować i to w ramach jednej firmy, czy też w ramach ogólnie całej branży. 

I widać to też po ofertach pracy. Tego Reacta jest zdecydowanie najwięcej, potem jest gdzieś ten Angular, Vue, a cała reszta to są póki co fajne ciekawostki z blogów, bo jeżeli chodzi o rynek pracy w ścisłym tego słowa znaczeniu, to te trzy frameworki tak naprawdę się liczą. 

Myślę, że to jest jak najbardziej pozytywne, bo wreszcie mamy jakiś spokój. Można też się skupić na rozwijaniu w jednej technologii bez obawiania się, że zanim my się tej technologii nauczymy, to ona już gdzieś tam przejdzie do lamusa. Więc to jest bardzo, bardzo fajne. 

W samym Reactie jest bardzo stabilnie, spokojnie. Mamy tego Nexta, który przynosi nam nowości, ale takim frameworkiem, gdzie się dzieje ciekawie i warto go obserwować, mimo że wiele osób mogło o nim trochę zapomnieć, jest Angular, który od kilku wersji naprawdę przyspieszył, goni Reacta, goni Vue. Tutaj duże zasługi najprawdopodobniej pani menadżer Sary Drasner, która się zaopiekowała Angularem. Widać, że od momentu jej dołączenia do Google’a ok. 2 lata temu, półtora roku temu, bardzo ten framework przyspieszył, odświeżył się, wygląda nowocześnie i myślę, że już nikt w 2024 roku nie będzie uważał, że praca z Angularem to jest coś takiego, czego trzeba się wstydzić albo trzeba się z tego tłumaczyć. To jest technologia, która wraca po prostu i pewnie będzie temu Reactowi trochę gdzieś tam tej popularności podbierała. 

Osobiście, jeżeli ktoś tu szuka rekomendacji, czego się uczyć, to ja bym tego Angulara polecał, bo ofert nadal jest naprawdę dużo, a konkurencja wydaje mi się, że jest znacznie mniejsza niż w przypadku Reacta, więc jeżeli ktoś szuka hintów, czego się uczyć, to wydaje mi się, że Angular naprawdę jest niezłym pomysłem. Oczywiście React również, ale trzeba się liczyć z dużą konkurencją, z dużą liczbą aplikacji, zwłaszcza na te stanowiska zdalne. 

Mamy tę wielką trójkę pod postacią Reacta, Angulara i Vue. React zdominował rynek, ma około połowę, reszta dzieli się tym, co zostało, i widać też dominację frameworka Next.js, który również tego Reacta samego poukładał, sprawił, że można szybko, produktywnie i w miarę w podobny sposób w wielu zespołach funkcjonować i to w ramach jednej firmy, czy też w ramach ogólnie całej branży.

 

Super, dzięki za to. Tutaj Przemek wspomniał, że te osoby, które już są w branży, które mają kilka lat doświadczenia, może nawet kilkanaście, być może powinny nieco rozważyć swoją dalszą karierę, czy też zaplanować ją bardziej rozsądnie, zastanowić się, czy to jest dobry rok na zmiany, być może przemyśleć nieco właśnie stabilizację swojej pozycji. Natomiast myśląc tutaj o rynku pracy, zastanawiam się też nad juniorami, też ogólnie osobami, które dopiero planują swoją tutaj karierę, których jest, jakby nie było, z roku na rok coraz więcej i też coraz mocniej ten próg wejścia się podnosi, nie jest tak łatwo wejść do branży. 

Oczywiście Jest to seria różnych czynników, które na to wpływają od ekonomicznych poprzez techniczne. Ja natomiast w kontekście frontendu tak sobie myślę, że od jakiegoś czasu było tak, że testowanie i frontend to były takie pierwsze wybory, jeśli chodzi o właśnie te furtki otwierające IT dla osób, które chcą tam wejść. 

Czy według Was nadal tak będzie, czy nadal tak jest, że frontend jest chętnie wybierany z racji na to, że po prostu tych ofert jest stosunkowo dużo, że materiału do nauki jest bardzo dużo? Czy to nadal jest słuszna, dobra, właściwa droga wejścia do IT? 

 

PS: Ja bym powiedział, że z tym frontendem można zauważyć taki paradoks, że z jednej strony on bywa właśnie marginalizowany i gdzieś tam jego rola jest umniejszana, jeśli chodzi o kontekst całych produktów i dużych aplikacji fullstackowych, a z drugiej strony, jeśli ktoś wchodzi w ten świat frontendu, to widzi, że to jest naprawdę trudna domena, że naprawdę nie jest łatwo zostać dobrym Frontend Developerem, pomimo tego, że gdzieś tam, tak jak właśnie mówię, panują te skojarzenia, że frontend bywa właśnie pisaniem przycisków, bywa dodawaniem jakichś cieni do elementów na stronie, przesuwaniem boxów, wydaje mi się, że rola frontendu z każdym rokiem rośnie i tutaj chyba ten trend tak naprawdę idzie w jedną i tę samą stronę. 

Frontend ma tę przewagę, że ta warstwa interfejsu użytkownika bezpośrednio przekłada się na jakiś performance produktu. Użytkownik klika potem w frontendzie, wchodzi w interakcję z frontendem i firmy też rozumieją, że dobry interfejs, taki, który konwertuje, będzie się koniec końców przekładał na wartość, które te firmy po prostu z pracy programistów wyciągają. 

Jeśli chodzi o sytuacje początkujących na frontendzie, to przynajmniej z mojej perspektywy, z tego feedbacku, który ja zauważam pod naszymi filmami na naszej platformie, to sytuacja faktycznie stała się nieco trudniejsza niż jeszcze jakiś czas temu. Szczególnie jeśli chodzi o chyba to najgorsze teraz podejście do rekrutacji, czyli wrzucenie CV do jakiegoś losowego formularza na job boardzie, gdzie obok Ciebie tych CV ląduje 100, 200, czasami 300, w zależności od pozycji. Słyszymy feedback od osób, które po prostu próbują tak dostać pracę, feedbacku od firm nie ma albo jest to feedback opóźniony, to jest feedback, który tak naprawdę jest jakimś generycznym responsem z danego formularza. 

To, co przynajmniej ja zawsze tutaj polecam, to jest albo wyróżnienie się poprzez swoje inicjatywy, swoje projekty poboczne, portfolio, taką działalność właśnie Indie Hackera, albo skupienie się na networku. 

I oczywiście też zdaję sobie sprawę, że w przypadku junior developerów początkujących kontakt z innymi, budowanie tego networku to jest trudna sprawa, bo te osoby nie mają jeszcze takiej sieci kontaktów, na których mogłyby polegać, ale pojawia się coraz więcej miejsc takich jak chociażby ta właśnie nasza platforma Przeprogramowanych, gdzie przecinają się starsi programiści i architekci z tymi mniej doświadczonymi. Mamy LinkedIna, który jest jaki jest, ale również tam można się złapać z bardziej doświadczonymi programistami. 

Mamy EXA, gdzie również jest sporo dyskusji programistycznych. Więc wydaje mi się, że troszkę trzeba przejść na taki model growth hackera, jeśli chodzi o tę swoją karierę i poszukać takich mniej standardowych miejsc szukania tej pracy niż właśnie wrzucenie tej swojej CV-ki. Przynajmniej to jest taka moja perspektywa. 

 

MC: Jak najbardziej się zgadzam z tym, co powiedział Przemek. To, co mogę dodać, zresztą sugerowałem w jednym z ostatnich filmów na YouTubie, że warto się dzielić tą wiedzą, warto też się dzielić, dokumentować proces swojej nauki, pokazywać, że się rozwijamy, że poznajemy nowe technologie, że to jest element naszej codzienności. To już sprawia, że nie jesteśmy jednym ze stu, dwustu, tylko jesteśmy jednym z dziesięciu, dwudziestu. To już jest znacznie mniejsza bardziej konkurencja niż ta, którą mamy, jeżeli korzystamy tylko z tego typowego narzędzia, jakim jest CV. 

Warto też śledzić te technologie, które są kluczowe obecnie, na przykład TypeScript, którego popularność rośnie z roku na rok i obecnie już jest, wydaje mi się, standardem i każdy junior powinien chociaż jego podstawy znać. Tutaj widzimy, że raczej ten trend się nie odwróci. Na początku 2020 roku TypeScript był 11. najpopularniejszym językiem na GitHubie, obecnie jest 4. i widzimy ciągły wzrost popularności tego języka, więc tutaj również polecam poznanie tej technologii, i oczywiście udokumentowanie procesu jej nauki właśnie na jakimś blogu, kanale, podcaście, co kto woli. 

 

Wspomniałeś, Marcin o technologiach, na pewno będę chciał za chwilkę ten temat poruszyć. Natomiast teraz może takie pytanie z gatunku tego, czym właściwie frontend jest. Pamiętam, jeszcze jakiś czas temu były takie dyskusje, czy też nie powinno się rozdzielić Frontend Developera od Javascript Developera. Jedni wręcz preferowali, żeby ich nazywać właśnie Javascript Developer, wskazując na może tę główną technologię, może to, że są bardziej programistami niż koderami, w każdym razie chciałbym tutaj Was zapytać, czy nadal frontend to jest głównie JavaScript/ TypeScript, czy to są te główne wiodące technologie, bez których się obecnie nie da nic zrobić na frontendzie? 

 

PS: Może ja tutaj pozwolę sobie zacząć. Wydaje mi się, że odpowiedź bardzo mocno jest powiązana z tą sytuacją na rynku i z rosnącymi oczekiwaniami względem programistów. Moim zdaniem trudno w dzisiejszych czasach tak bardzo selektywnie podchodzić do tego, co będziemy w tym świecie programowania robić i wyciągać sobie ten kawałek tortu i mówić, że np. w tym będę chciał się specjalizować. 

Myślę, że mogą sobie na to pozwolić osoby, które już od dłuższego czasu budowały taką rolę architektów, ekspertów, liderów technicznych. One po prostu będą na tej ścieżce. Natomiast jeśli chodzi o mniej doświadczone osoby, to przynajmniej z mojej perspektywy wygląda na to, że tych oczekiwań będzie się jednak pojawiać coraz więcej. I to wręcz nie będą oczekiwania tylko na poziomie frontendu, ale też oczekiwania związane z tym, żeby wyjść poza tę warstwę, żeby dotknąć serwera, żeby popracować z API. 

Widać to też po samych frameworkach, o których jeszcze zaraz możemy pogadać, widać takie trendy, które po prostu sprawiają, że te frameworki, z którymi pracujemy, po prostu będą na to zezwalać, ale przynajmniej z mojej perspektywy bardziej opłacalne na dzisiaj byłoby budowanie takich asetów związanych z innymi warstwami tej aplikacji webowej niż wybieranie sobie tego właśnie fragmentu ogródka, którym chcesz się zajmować. Myślę, że specjalizacja to jest jakiś pomysł na swoją karierę, ale myślę, że tutaj ryzyko gdzieś tam porażki jest zdecydowanie większe niż bycie takim one man army, takim komandosem, którego można po prostu wrzucić do projektu i on sobie z tym zadaniem poradzi. 

Oczywiście tutaj też byśmy mogli jeszcze porozmawiać o innych zmiennych typu rozmiar firmy, typu sytuacja ekonomiczna, typu produkt, który dana firma rozwiązuje. Ale myślę, że na dzisiaj to jest chyba bardziej bezpieczny bet, żeby nie być właśnie takim, no powiedzmy sobie wybrednym, jeśli chodzi o to, co chcesz robić, ale jednak próbować dotykać różnych aspektów programowania, może przeczekać ten troszkę trudniejszy okres na rynku pracy i za jakiś czas podjąć tę decyzję. To przynajmniej tak z mojej perspektywy to wygląda. 

 

MC: Osobiście uważam, że cały czas ten JavaScript i TypeScript są istotne, ale to już jest takie tak naprawdę oczywiste. W sensie wszyscy wiedzą, że Frontend Developer musi mieć te języki w małym palcu i teraz coraz częściej pojawia się pytanie, co dalej. Co my musimy jeszcze umieć? I wydaje mi się, że jest powrót właśnie do podstaw bardzo często, czyli do dogłębnej znajomości HTML-a, CSS-a, właśnie z uwagi na dostępność, na UX, który często, kiedy tego JavaScriptu jest za dużo w naszej aplikacji, ta właśnie dostępność i użyteczność aplikacji często traci, bo nie korzystamy z tego, co oferuje nam przeglądarka, tylko próbujemy wynajdywać koło na nowo. Wydaje mi się, że właśnie w ostatnich latach wielu frontendów sobie zdało z tego sprawę i jest taki powrót do tego, żeby ten HTML dobrze znać, żeby testować dostępność i dbać o to, aby ta aplikacja właśnie była jak najbardziej przystępna dla każdego użytkownika, nie tylko tego, który korzysta z aplikacji tak samo jak my, developerzy. 

Osobiście uważam, że cały czas ten JavaScript i TypeScript są istotne, ale to już jest takie tak naprawdę oczywiste. W sensie wszyscy wiedzą, że Frontend Developer musi mieć te języki w małym palcu i teraz coraz częściej pojawia się pytanie, co dalej. Co my musimy jeszcze umieć? I wydaje mi się, że jest powrót właśnie do podstaw bardzo często, czyli do dogłębnej znajomości HTML-a, CSS-a, właśnie z uwagi na dostępność, na UX, który często, kiedy tego JavaScriptu jest za dużo w naszej aplikacji, ta właśnie dostępność i użyteczność aplikacji często traci, bo nie korzystamy z tego, co oferuje nam przeglądarka, tylko próbujemy wynajdywać koło na nowo.

 

Słuchajcie, tutaj idąc dalej tym tropem, jak się przegląda na LinkedIn profile osób, które się specjalizują we frontendzie, bardzo często widać tam taki headline React Developer, Angular Developer, Vue Developer, a wręcz jeszcze głębsza tutaj specjalizacja. Czy to nadal ma sens? Czy ten układ sił już się na tyle ukształtował, że ma sens i warto jest mieć tę specjalizację związaną z jedną biblioteką czy też frameworkiem? Czy też może, tak jak tutaj wspomnieliście, frameworki nadal powstają, nadal jest płynna sytuacja na rynku? 

 

PS: Ja oczywiście nie wiem, jaka jest motywacja tych osób, które ustawiają tego typu headline, ale chciałbym wierzyć, że to jest tylko i wyłącznie optymalizacja pod keywordy, pod wyszukiwanie na takich portalach jak chociażby LinkedIn i chciałbym też wierzyć, że gdzieś w czasie offline albo w czasie pracy po prostu nad rzeczywistymi projektami te osoby jednak przebijają tę bańkę, bo życie jest za krótkie, że tak powiem, żeby na tym jednym frameworku się skupiać i my też to widzimy, pracując nad materiałami na Przeprogramowanych, że naprawdę w każdym kawałku frontendu znajdziesz coś, co może się w jakiś sposób rozwinąć. 

Wydaje mi się, że często pojawia się chociażby takie bardzo nie fair spojrzenie czy też taka opinia na Angular, że to jest ciężki framework, że to jest framework dla enterprise, że to jest framework, który ma duży próg wejścia. Natomiast to jest też framework, który ma sporo dobrych wzorców, który się dobrze skaluje, który pozwala ci się nauczyć chociażby dependency injection. Jeśli jesteś reactowcem, to możesz nigdy nie mieć do czynienia np. z wstrzykiwaniem zależności w taki sposób, jak robi się to w Angularze. gdzie tak naprawdę masz łatwe testowanie serwisów, które wstrzykujesz, gdzie masz różne tokeny, których możesz używać, po prostu zupełnie inny pattern. 

I tak naprawdę nie chodzi o konkretną pozycję, o którą którą ja tutaj wymienię, ale chodzi o to, że tak naprawdę gdzie nie zajrzysz, to widzisz jakieś inne podejście i szczególnie też w tej nowej fali frameworków mamy takie pomysły, które wcześniej się nie pojawiały albo które dopiero adoptują się powoli, jak chociażby sygnały, inne podejście do reaktywności, to, że VirtualDom nie jest już np. standardem takim, jak był za czasów pierwszego oryginalnego Reacta, kiedy wszyscy tym VirtualDomem byli zachwyceni, a dzisiaj okazuje się, że inne frameworki robią to inaczej i również ma to sens. 

Więc wracając do Twojego pytania, nie mam nic przeciwko ustawieniu headera React Developer, ale oby to było tylko na cele rekrutacji. Fajnie, jakbyś zaglądał do innego ekosystemu, fajnie, żebyś tam próbował wyciągnąć nowe informacje, których w tym Twoim frameworku po prostu nie znajdziesz. 

 

Może bardziej do Ciebie też pytanie, jak ten stan frameworkowo-bibliotekowy obecnie wygląda, kto dominuje? Trochę o tym powiedziałeś już, ale fajnie byłoby tutaj zebrać te wiadomości w jednym miejscu. 

 

MC: Zdecydowanie dominuje React. To jest gdzieś tam połowa rynku. Tutaj widzimy taki rozkład, jaki jest w ogóle w wielu branżach. Np. mamy taki podobny rozkład, jeżeli chodzi o napoje gazowane, gdzie Coca-Cola jest takim zdecydowanym liderem, mają połowę rynku, a całą resztę ma duży gracz Pepsi, a potem jest dużo jakichś tam mniejszych, Mirinda 7up. Bardzo podobnie to wygląda w programowaniu i zresztą w wielu innych branżach. Jest to opisane gdzieś tam w książkach o marketingu, dość gdzieś tam zaobserwowany już wzorzec, więc tutaj też go widzimy, że React tę wojnę o serca developerów frontendowych wygrał. 

Ja to starcie gdzieś tam oglądałem od 2015 do 2018 roku. Była duża rywalizacja pomiędzy Reactem, Angliarem i Vue. Nikt do końca nie wiedział, jak to się skończy, ale widać, że głównie za pośrednictwem, moim zdaniem, marketingu, który miał miejsce na Twitterze, to React gdzieś tam sobie właśnie tę dominację wywalczył, bo jeżeli poznamy te technologie, takie właśnie jak React, Angular i Vue bliżej, Przemek mówił bardzo słusznie, że te frameworki mają różne podejście do niektórych aspektów, ale prawda jest taka, że też mają wiele części wspólnych i jakby nie patrzeć, to są frameworki frontendowe, powiedzmy, tej starej generacji, bo jeszcze mamy nową, o której możemy za chwilę powiedzieć, które mają wiele podobnych założeń, wiele podobnych podstaw i tak naprawdę wydaje mi się, że mimo wszystko więcej je łączy, niż dzieli. 

Bo jeżeli spojrzymy np. na podejście, jakie mamy w tych nowszych frameworkach, takich jak Svelte albo Quick, to tutaj widzimy już dużo inne podejście do tego, jak ten frontend powinno się tworzyć, co jest najbardziej istotne. Może właśnie, żeby tego Javascriptu było trochę mniej w tej przeglądarce, a nie więcej jak w przypadku Reacta czy Angulara. Tak więc rynek zdecydowanie póki co nastawił się na Reacta i na Nexta. Nic się nie zapowiada, żeby miało się to w tym roku zmienić. Wydaje mi się, że Angular dostanie trochę wiatru skrzydła, więc tak jak mówiłem, jeżeli ktoś szuka frameworka do nauki, to ja bym mimo wszystko stawiał na Angulara, bo tam mamy nie dość, że fajną dokumentację, jedno stabilne podejście do tworzenia projektów, to również bardzo dobrą sytuację w samym frameworku, fajne relisy, dużo ofert pracy. Wydaje mi się, że warto tam próbować. 

 

PS: Tutaj jeszcze można dodać to, co też Marcin zauważył w trakcie jednego z ostatnich webinarów, czyli konkurencję na rynku. Jeśli decydujemy się na pracę w tej najbardziej popularnej technologii, czyli w React’cie, który tak naprawdę przejął większość tego rynku frontendowego, to naturalnie poziom trudności idzie w górę. Naprawdę musi być znacznie lepszy od innych React Developerów, żeby gdzieś tam być zauważonym przez rekruterów, co w przypadku Angulara może być jakąś przewagą pozytywnie wpływającą na to, że szybciej znajdziesz tę pracę po prostu. Skoro firmy pracujące z Angulerem nie publikują tak często i gęsto tych swoich ofert, to może warto po prostu tam zgłaszać się w kierunku szukania pierwszej pracy i niekoniecznie kierować się jakimiś swoimi ambicjami albo konkretną tabelką frameworka. 

To jest właśnie dość zniuansowany temat. Z jednej strony te statystyki, o których wspomniał Marcin, z drugiej strony bardziej takie można powiedzieć wyrachowane albo zaprojektowane podejście do swojej kariery. Tutaj każdy już tę decyzję musi podjąć samemu. Ja się zgadzam z tym, co powiedział Marcin. Jak zdecydujecie się na jeden wybór z tej trójki, to raczej to nie będzie zły wybór. Pracę znajdziecie, a ten rozkład możecie chociażby na NPM Trendsach zobaczyć. 

Jeśli decydujemy się na pracę w tej najbardziej popularnej technologii, czyli w React’cie, który tak naprawdę przejął większość tego rynku frontendowego, to naturalnie poziom trudności idzie w górę. Naprawdę musi być znacznie lepszy od innych React Developerów, żeby gdzieś tam być zauważonym przez rekruterów, co w przypadku Angulara może być jakąś przewagą pozytywnie wpływającą na to, że szybciej znajdziesz tę pracę po prostu.

 

Tak, to jest na pewno dobra wskazówka dla tych osób, które myślą, w którym kierunku pierwsze kroki wykonać, a dla tych osób, które już troszkę może są w temacie i właśnie w tym duchu niezamykania się na obecnie panujące i królujące rozwiązania, jakie jeszcze rozwiązania byście polecili, żeby przynajmniej się zainteresować, żeby ciągle być tutaj w obiegu? 

 

MC: Myślę, że będą dwie rekomendacje. Ja przytulę jedną, drugą oddam Przemkowi. Ja polecę Svelte, który jest takim najbardziej popularnym frameworkiem nowej generacji. Jego autorem jest dość znany prelegent Rich Harris, który również robi świetną robotę, jeżeli chodzi o marketing tego rozwiązania. Tam właśnie mamy podejście, żeby tego JavaScriptu było jak najmniej, żeby wydajność była jak najlepsza i żeby to po prostu było łatwe w nauce, łatwe w wykorzystywaniu. 

Dużo rzeczy, które mamy właśnie skomplikowane w React’cie, skomplikowane w Angularze, na które ludzie narzekali, to widać, że Rich Harris te wszystkie opinie przeczytał, zrozumiał, co ludziom nie odpowiadało, czego im brakowało, co było za trudne i widać, że w tym Svelte po prostu zadbał, żeby te koncepcje były prostsze, żeby bardziej były przystępne. 

Bo nie da się ukryć, że czasami, kiedy piszemy kod w React’cie albo w Angularze, widzimy, że coś jest trochę trudniejsze, niż by tak naprawdę mogło. Nie do końca też wiadomo dlaczego. Zresztą ostatnio dość kontrowersyjną rzeczą w React’cie są te server components, które analizowane przez jednego z twórców samego rozwiązania, czyli Dana Abramova, który również doszedł do wniosku, że to wcale takie proste nie jest, żeby to zrozumieć, w Svelte takich gdzieś tam sytuacji jest znacznie mniej. 

Więc tutaj moja rekomendacja, ale oczywiście to nie jest technologia, której bym się uczył jako pierwszej. To jest bardzo fajne rozwiązanie do projektów pobożnych obecnie. Myślę, że w ciągu najbliższych kilku lat coraz bardziej będzie przenikało na produkcję, do firm, ale nie stawiałbym na to obecnie gdzieś tam wszystkich swoich kart, mimo, że we własnych projektach, które realizujemy w ramach Przeprogramowanych, to właśnie Svelte jest takim naszym go to programem frameworkiem frontendowym, ale to przez to, że nie tworzymy tutaj projektów, który ma utrzymywać 200 developerów i dbamy o to, żeby jak najwięcej osób tę technologię znało, tylko jesteśmy tutaj we dwójkę, więc możemy sobie pozwolić na taką awangardę. 

 

PS: To ja tutaj może pociągnę te rekomendacje Marcina i zacznę od takiego pytania, w co to Svelte opakować tak naprawdę, bo do budowania aplikacji potrzebujemy frameworka, który da nam właśnie interaktywność na stronie, ale potrzebujemy też jakiegoś opakowania w postaci stron, routingu, w postaci obsługi jakichś parametrów zewnętrznych, w postaci zapytań np. do API. 

I tutaj tak naprawdę dwie ścieżki, takie dwie rekomendacje. Albo SvelteKit, czyli taki odpowiednik Nexta dla Reacta właśnie dla Svelte. SvelteKit to jest taki metaframework, który właśnie opakowuje Svelte i dodaje te brakujące elementy aplikacji end-to-endowej, webowej właśnie w tym ekosystemie. Albo taka rekomendacja, której nam jest zdecydowanie bliżej, czyli Astro. Kolejny framework, który jakby pozwala opakować te komponenty i aplikacje pisane w Svelte, tyle że daje jeszcze inne korzyści, mianowicie zamiast Svelte w Astro możecie wykorzystywać Reacta, możecie wykorzystywać Quicka, możecie wykorzystywać Vue. 

Czym właściwie jest Astro? Astro to również jest framework, ale osobiście dość trudno się mi o nim mówi, bo trudno jakby wydzielić jasne granice odpowiedzialności Astro, bo Astro jest bardzo zachłanne i ona chce rządzić całą aplikacją, zarówno jeśli chodzi o te elementy po stronie serwera, strony statyczne, routing, zarządzanie treściami i te elementy client-side. Ale to jest właśnie korzyść, że w tym Astro naprawdę można sporo zrobić, można przeglądarkę odciążyć, bo sporo roboty w Astro wykonuje się w build time albo po stronie serwera. 

Jeśli brakuje nam tej interaktywności, to można się tutaj powołać na te rekomendacje, o których mówiliśmy wcześniej. Można sobie fragment aplikacji Astro rozszerzyć np. przez komponent napisany w Reakcie, przez komponent napisany w Svelte. 

My to testujemy od dobrych kilkunastu miesięcy różne podejścia do tej strony client-side w Astro i cały czas chcemy ten kierunek kontynuować. Zarówno takie projekty jak Opanuj AI, Opanuj Frontend, Advent of Frontend właśnie powstawały w oparciu na Astro i też nie ukrywam, czujemy się takimi drobnymi ewangelizatorami tej technologii w tym polskim ekosystemie. Zobaczymy. 

W naszym przypadku się sprawdza, nie było tak z alternatywami, kiedy sparzyliśmy się na Gatsbym, zobaczymy, jak długo uda się pracować właśnie z Astro, ale to taka rekomendacja ode mnie. 

 

Fajnie, dzięki za te rekomendacje. Słuchajcie, tak sobie myślę, że dużo się mówiło o TypeScript jako języku, jako nakładce, która de facto zdominuje JavaScript i niedługo nie będzie już wręcz potrzeby, żeby patrzeć na, czy też rozwijać projekty JavaScriptowe. Oczywiście można tam troszkę z przymrużeniem oka na to patrzeć, natomiast takie serio, zupełnie pytanie jest takie, jak obecnie ten TypeScript się odnajduje na frontendzie? Czy faktycznie jest dominujący, jeśli chodzi o języki i czy nadal zainteresowanie się podstawami w postaci JavaScriptu, może jako punkt startowy, ma sens? 

 

MC: Zaczynając od końca, jak najbardziej gdzieś tam dogłębne poznanie JavaScriptu jest cały czas niezbędne, bo TypeScript nie jest niczym więcej jak rozszerzenie JavaScriptu. Tam mamy cały JavaScript plus trochę więcej, więc jeżeli my tego JavaScriptu nie znamy, to nie będziemy w stanie z TypeScriptu korzystać, zresztą tak samo jak z samego JavaScriptu. 

A jeżeli chodzi o popularność tej technologii, to ona rośnie. Osobiście, kiedy miałbym wrócić do pracy na etacie w jakimś większym projekcie, to nie wyobrażam sobie pracować już z czystym JavaScriptem na szerszą skalę. Zdecydowanie wolałbym, żeby to był TypeScript. Do tego języka już się przyczaiłem. Kiedy myślę o pisaniu kodu frontendowego, to myślę o kodzie TypeScriptowym, a nie JavaScriptowym. Jednak te statyczne typy i wszystkie inne usprawnienia, które TypeScript wnosi do projektu, są bardzo znaczące. Ja się nie zgadzam, że to są znaczące zalety tylko z punktu widzenia dużych projektów enterprise’owych, również w małych projektach TypeScript wnosi dużą wartość. Ten kod jest bardziej opisowy, jest bardziej zrozumiały, łatwiej do niego wrócić też po dłuższym czasie niż do kodu w czystym JavaScript’cie. 

Tak więc ta technologia jest istotna, fajnie się rozwija i jej popularność, jak już zresztą wspominałem, rośnie w rankingach GitHub’a, w rankingach Stack Overflow Developer Survey widzimy z roku na rok wysoki, rosnący poziom popularności, i też wysoki poziom satysfakcji, bo co ciekawe właśnie w tej ankiecie Stack Overflow Developer Survey zeszłorocznej TypeScript był na trzecim miejscu, jeżeli chodzi o satysfakcję developerów. Przegonił go tylko Elixir i Rust, więc to jest technologia, która nie dość, że jest szeroko adoptowana, to jeszcze po prostu programiści ją lubią. 

Więc moim zdaniem warto się uczyć. Wydaje mi się, że naprawdę niewiele osób stwierdzi, że ten TypeScript to nie bardzo, wracam do czystego JS-a, bo to mi się nie podoba. Słyszałem kilka takich opinii, ale to naprawdę są raczej wyjątki niż reguła. 

 

Mówimy tutaj o bibliotekach, mówimy o frameworkach, mówimy o językach, natomiast to nie zamyka oczywiście nam całego spektrum różnych technologii używanych na frontendzie. Chciałbym wrócić, ponieważ mam wrażenie, że co roku jest ten temat wspominany jako trend, do PWA – Progressive Web Apps. Czy jest to technologia, która jeszcze ma szansę gdzieś szerzej wypłynąć, a może już gdzieś po prostu trzeba ją pogrzebać? 

 

PS: Trudno o jednoznaczną odpowiedź na takie pytanie. Ja na pewno nie byłbym na tyle odważny, żeby tutaj mówić, że PWA warto grzebać, warto się nie interesować tym tematem. PWA są na pewno intrygujące, powiem tak, są interesujące, są ciekawe. To jest znowu taki obszar, który może poszerzyć tę bazę wiedzy dla Frontend Developera. Dla dodania kilku słów kontekstu, PWA to są bardziej zaawansowane aplikacje webowe, które zachowują się poniekąd jak natywne aplikacje, które możemy zainstalować, dodać na pulpit, możemy w ich obrębie korzystać z API, urządzenia, na którym z tej aplikacji korzystamy. To jest taka obietnica. 

PWA na pewno są bardzo zależne od tego, co dzieje się w API przeglądarek, bo to są cały czas aplikacje uruchamiane w przeglądarkach, więc jeśli wsparcia dla poszczególnych API nie ma, to samych PWA nie będziemy wykorzystywać tak szeroko jak chociażby aplikacji natywnych. Ale tutaj przygotowując się do tej rozmowy, zauważyliśmy, że w Safari są bardzo obiecujące postępy jeśli chodzi o wsparcie dla PWA. Safari bardzo mocno zaczęło się w ostatnich miesiącach rozwijać właśnie w kontekście web developmentu. Microsoft to też jest firma, która pushuje PWA jako rozwiązanie w wielu swoich projektach. Wydaje też rozwiązania takie jak PWA Builder czy PWA Studio w tym swoim ekosystemie dla programistów. 

Mamy również duży selling point, mianowicie możliwość dystrybucji PWA w App Store, w Google Play Store. To też nie było od samego początku oczywistością, natomiast przy zachowaniu konkretnych wymagań, przy opisaniu naszego manifestu, te aplikacje mogą się pojawiać w sklepie. I tak naprawdę mamy taką iluzję tej aplikacji natywnej. Chyba jeden z takich najgłośniejszych przypadków, o których ja ostatnio słyszałem, to był Campfire, czyli nowy projekt od 37signals, gdzie właśnie w Campfire klient mobilny dla czatu firmowego są właśnie oparte o PWA. Ta firma zdecydowała, że dla szybkiego dowożenia pierwszej wersji projektu nie będą budować aplikacji natywnych, zbudują PWA i to teraz w tych ich release notesach da się zauważyć. 

Z mojej perspektywy, szczerze mówiąc, natywne aplikacje nadal te PWA jednak biją na głowę, szczególnie w momencie, kiedy spędzi się troszkę czasu w nowszych ekosystemach, np. w ekosystemie Swifta, SwiftUI, tam po prostu jest więcej możliwości budowania tych aplikacji, one zachowują się lepiej. Przynajmniej to jest moja subiektywna opinia, jestem dużym fanem Weba, ale wydaje mi się, że jeśli chodzi o aplikacje mobilne, to natywne rozwiązania dalej górują. Natomiast trzeba oddać, że przez PWA frontendowcy zainteresowali się service workerami, web workerami, zainteresowali się tymi właśnie niestandardowymi API, o których też mówiliśmy w OpenJavaScript i tam też było sporo komentarzy, gdzie programiści mówili, że są zaskoczeni, że właściwie przeglądarka potrafi robić takie rzeczy, że mogę wywołać aparat, że mogę pobrać geolokalizację, mogę z powiadomień push skorzystać, więc trzeba to zbalansować. 

Ja tutaj, tak jak mówię, Nie wydam takiego jednoznacznego osądu, nie powiem, że trzeba to pogrzebać. Pewnie są use cases, są firmy, które nadal tym PWA się interesują. Ja jestem dużym fanem Swifta i SwiftUI, więc tutaj też polecam sprawdzić natywne aplikacje mobilne. 

 

I analogiczne pytanie o mikrofrontendy. Czy ta obietnica w postaci tworzenia fragmentów strony ze wykorzystaniem różnych rozwiązań jest w praktyce rozwijana, używana?

 

MC: Jak najbardziej są firmy, które korzystają z tych rozwiązań. Zresztą Smart Recruiters, z których pracowałem, było jedną z takich firm. Jeżeli chodzi o mikrofrontend, również szybki background, to jest podział aplikacji albo na strony całe, które są rozwijane przez niezależne zespoły, albo na komponenty, które potem są integrowane w ramach jednej większej strony. Takie podejście np. jest stosowane w Allegro, z tego co wiem, gdzie właśnie mamy mikrofrontend jakiegoś koszyka, wyszukiwarki i one są rozwijane przez niezależne zespoły, które specjalizują się właśnie w tej części interfejsu. Jest jeszcze to prostsze podejście, czyli po prostu mamy całą stronę, którą zajmuje się jeden zespół i za pomocą takich stron jest skomponowany cały system. Takie podejście mieliśmy właśnie w Smart Recruiters. 

Tak więc to jest podejście, podobnie jak mikroserwisy, które wnosi wiele wartości, ale również ma swoje problemy. Jeżeli chodzi o wartość, to mamy do czynienia z tym, że właśnie zespoły mogą pracować niezależnie, czyli nie mamy sytuacji, w której robimy deployment i czekamy w kolejce, bo inne zespoły też chcą wyjść na produkcję. Tu mamy własny kontener dla naszego komponentu, dla naszego page’a, dzięki czemu zespół po prostu nie ma dependencji na zewnątrz i nie jest blokowany, może jak taka mała firma wewnątrz większej firmy funkcjonować. I w Smart Recruiters to naprawdę fajnie się sprawdzało, bo to przyspiesza pracę, pozwala też zespołom tworzyć własne procesy, dzięki czemu nie jesteśmy po prostu tylko częścią jakiejś wielkiej maszyny, do której musimy się dostosować, mamy dużo więcej niezależności. 

Ale oczywiście, jeżeli chodzi o minusy, to się wiąże z tym, że musimy zapewnić właściwą infrastrukturę, która w ogóle pozwoli nam na stosowanie tych mikrofrontendów to jest dodatkowa złożoność. Musimy też ludziom to tłumaczyć, którzy nowi przychodzą do firmy, bo wiele osób z mikrofrontendami nie pracowało, więc to nam wydłuża onboarding. 

Tak więc są plusy i minusy, bardzo podobne jak w przypadku mikroserwisów właśnie. Wydaje mi się, że kluczowe co do mikrofrontendów jest to, że musimy wiedzieć, czy firma jest we właściwym momencie, że to faktycznie wniesie nam wartość, że my tej niezależności potrzebujemy, że my już faktycznie gdzieś tam pomiędzy zespołami zbyt często sobie wchodzimy na stopy i są z tego powodu jakieś konflikty, czy też po prostu spadek produktywności. 

Jeżeli tego nie ma, to ja gdzieś tam w nowym firmie, w nowym startupie bym mikrofrontendów nie proponował, no bo weźmiemy na siebie cały ten koszt właśnie infrastruktury, dodatkowej złożoności, a tak naprawdę nie będziemy mieli zbyt wielu korzyści, no bo 1, 2, 3 zespoły nad jedną aplikacją spokojnie mogą pracować. Jeżeli jest tych zespołów 15, 20, 100, no to wtedy już sytuacja wygląda trochę inaczej. Więc wydaje mi się, że jeżeli firma jest gotowa na mikrofon trendy, to dobrze będzie o tym wiedziała. Jeżeli musi się zastanawiać, to znaczy, że najpewniej nie jest. 

 

Właśnie, tutaj, Marcin, zaznaczyłeś ten komponent ludzi i to jest też istotna perspektywa, którą trzeba wziąć pod uwagę, jeśli patrzy się na obraz frontendu i każdej pewnie innej technologii czy specjalizacji. 

Powiedzieliście trochę o technologiach, porozmawialiśmy sobie na temat rynku pracy. Myślę, że warto by było spojrzeć właśnie na profil Frontend Developera, jakie nowe wyzwania stoją przed taką osobą w 2024 roku, jak może się rozwijać, w czym powinien się specjalizować? Może zacznijmy od rynku pracy. Czy obecnie od Frontend Developera wymaga się więcej niż jakiś czas temu? Czy te oczekiwania poszły do góry? 

 

PS: Będąc tutaj zupełnie szczerym, my obecnie pełnoetatowo rozwijamy Przeprogramowanych, więc ja nie mogę tutaj mówić o swoim personalnym doświadczeniu pracy na etacie pracy Frontend Developera, ale przez to, że jesteśmy w kontakcie ze społecznością, to gdzieś możemy jakieś wnioski wyciągać z tych rozmów. I tak jak już wspominałem wcześniej, widać, że te wymagania rosną. 

Z jednej strony jest stabilizacja, firmy specjalizują się i kontynuują tę podróż w kierunku tych frameworków, które wcześniej wybrały, ale też wokół frameworków dzieje się naprawdę sporo, w jaki sposób trzeba utrzymać produkcję 24/7, trzeba sobie poradzić z infrastrukturą, trzeba sobie poradzić ze zbieraniem feedbacku od użytkownika. Frontendowiec, myślę, że jest cały czas tą osobą, od której rozpoczynają się często te konwersacje, może nie jeśli chodzi o infrastrukturę, ale jeśli chodzi o taki pierwszy punkt konwersacji, pierwszy punkt kontaktu, którego można zapytać, słuchaj, jak np. można wstrzyknąć jakąś bibliotekę do monitoringu aplikacji na ten UI, czy możemy jakiś alerting tutaj zrobić, czy możemy się dowiadywać, kiedy użytkownicy klikną w jakiś przycisk. Mamy też cały temat analityki, jakiś A-B testów, zarządzania feature’ami. 

Więc na pewno w 2024 roku Frontend Developer to nie jest taka osoba, która np. będzie się zajmować implementowaniem przycisków i kolorowaniem tekstu na stronie. Tzn. to są wymagania, które być może nigdy nie były w ogóle na tym rynku, ale funkcjonują cały czas w powszechnej świadomości. 

Myślę, że Frontend Developer to jest teraz naprawdę komandos, który bierze sporo na siebie. Ze strony twórców frameworków też pojawia się ta presja, żeby właśnie wchodzić na serwer, żeby optymalizować aplikację, żeby nie wszystko robić w przeglądarce, żeby poznawać tego Node’a i tak naprawdę trzeba dużej elastyczności, dużej zwinności, żeby na rynku frontendu pozostać. Nie mówiąc już o jakiejś takiej presji zewnętrznej, to też możemy o tym porozmawiać, jeśli chodzi o np. automatyzację i o to, czy ten frontend to jest tak naprawdę długofalowa ścieżka kariery, czy jest szansa na to, że ten UI będą za nas tworzyć roboty. 

Nie mówię, że tak albo nie, ale mówię, że gdzieś z tyłu głowy u wielu frontendów to się pojawia i też pod naszymi filmami często pojawiają się pytania, czy w ten frontend w ogóle warto wchodzić w 2024 roku, skoro „ChatGPT napisze tutaj za nas cały ten interfejs użytkownika”. Niezależnie od tego, czy to jest prawda, czy nie, to takie opinie zaczynają funkcjonować w tej świadomości i ci frontendowcy muszą się z tym jakoś zmagać. Więc może to tak na początek, że po prostu to jest trudny zawód moim zdaniem w tym roku. 

 

Jakie są te najczęstsze obawy albo czego się osoby zajmujące frontendem obawiają? Jakie poletka technologiczne są dla nich trochę odstraszające? 

 

MC: Wydaje mi się, że wszystko, co wykracza poza ten framework, który ta dana osoba poznała, bo zwykle właśnie uczymy się Reacta, uczymy się Nexta, mamy takie poczucie, że coś już tam potrafimy, jesteśmy w stanie stworzyć aplikację w przeglądarce, jakoś to wygląda, ale potem idziemy do pracy i nagle się okazuje, że to jest 30% naszej pracy, bo musimy jeszcze ten kod właściwie otestować, musimy zadbać o jakąś dostępność tego kodu, musimy oczywiście z tym kodem wyjść na produkcję, zazwyczaj za pośrednictwem jakiegoś tam githuba, gdzie trzeba stworzyć PR, więc jakby tego jest znacznie więcej, niż nam się wydaje na początku, kiedy po prostu uczymy się jednej technologii, która pozwoli nam zbudować interfejs.

Bo żeby ten interfejs dotarł do użytkownika i żeby on działał i nie tylko dzisiaj, ale również za tydzień i za miesiąc, mamy wiele więcej gdzieś tam aktywności do wykonania i to często ludzi przeraża, bo to jest coś nowego i coś, czego ciężko się nauczyć zwykle, bo ani dużo osób o tym nie mówi, bo dużo łatwiej mówić o React’cie, o Next’cie, to się lepiej klika, łatwiej też się na taki temat tworzy materiały, a gdzieś tam jest ta wiedza taka inżynierska, powiedzmy, którą często po prostu zdobywamy na przestrzeni powiedzmy pierwszych 5, 6 lat doświadczenia w różnych firmach, w których są różne rozwiązania, różne podejście i dopiero wtedy tak naprawdę czujemy się w pełni komfortowo z tymi aspektami pracy programisty.

I wydaje mi się, że one teraz trochę wychodzą właśnie na pierwszy plan, bo to, że Ty umiesz w React’cie i w Next’cie, no to każdy już prawie umie, każdy zrobił kurs na Udemy, każdy przyrobił dokumentację, ale czy Ty jesteś inżynierem, czy Ty będziesz w stanie dowodzić wartość na przestrzeni kilku tygodni bądź miesięcy, to są teraz te pytania, na które trzeba odpowiedzieć w przekonujący sposób podczas rekrutacji, żeby pracę dostać, żeby sobie dobrze w tej pracy radzić.

Wydaje mi się, że wszystko, co wykracza poza ten framework, który ta dana osoba poznała, bo zwykle właśnie uczymy się Reacta, uczymy się Nexta, mamy takie poczucie, że coś już tam potrafimy, jesteśmy w stanie stworzyć aplikację w przeglądarce, jakoś to wygląda, ale potem idziemy do pracy i nagle się okazuje, że to jest 30% naszej pracy, bo musimy jeszcze ten kod właściwie otestować, musimy zadbać o jakąś dostępność tego kodu, musimy oczywiście z tym kodem wyjść na produkcję, zazwyczaj za pośrednictwem jakiegoś tam githuba, gdzie trzeba stworzyć PR, więc jakby tego jest znacznie więcej, niż nam się wydaje na początku, kiedy po prostu uczymy się jednej technologii, która pozwoli nam zbudować interfejs.

 

Właśnie ten efekt pracy Frontend Developera jest często, można powiedzieć, takim pierwszym punktem styku użytkownika z aplikacją, stroną, jakkolwiek. W związku z tym zastanawiam się, czy w tym obrazie Frontend Developera UX, czy też dostępność, accessibility, to nie są właśnie te czynniki, które będą coraz bardziej na znaczeniu gdzieś dostrzegane?

 

PS: Moim zdaniem tak, na pewno to będą ważne, o ile już nie są bardzo ważne, jeśli nie krytyczne aspekty pracy Frontend Developera, który właśnie jest Product Engineerem, taką osobą, o której mówił Marcin, czyli nie tylko osobą, która zna API danego frameworka, ale wie, jak ta jego praca przekłada się na użytkownika, na sposób gdzieś tam pozyskiwania wartości z tego produktu.

Jeśli chodzi o journey użytkownika, o taką empatię względem osób, które korzystają z naszej aplikacji, to naprawdę trzeba znać paterny, wzorce związane z dostępnością, z UX-em, z budowaniem interfejsów użytkownika, żeby po prostu te doświadczenia były optymalne. I tutaj niezależnie od tego, czy mamy takie czysto etyczne pobudki i nie chcemy nikogo wykluczać, czy mamy takie czysto kapitalistyczne pobudki, czyli po prostu chcemy robić jak najwięcej kasy z tego produktu, który budujemy, to te umiejętności po prostu się przydają.

Marcin też ma sporo doświadczenia w kontekście pracy w zespole platformowym, bo to też bardzo często się po prostu sprowadza do komunikacji z innymi osobami w firmie. Być może nie musisz zostawać ekspertem, ale musisz z tymi ekspertami w jakiś sposób się porozumieć, więc to na pewno pozostaje w tym toolbelcie umiejętności programisty.

 

MC: Dokładnie tak, właśnie o tym chciałem wspomnieć, że może nieistotne jest, żeby być turbo ekspertem od UX-u, ale na pewno warto umieć rozmawiać z designerami, warto umieć z nimi współpracować, bo to zwykle oni są tymi ekspertami i od nich można tę wiedzę wyciągnąć.

Wydaje mi się, że często naszą rolą jako Frontend Developerów, to jest może moje doświadczenie, które jest jakieś skrzywione, jest dbanie o tą dostępność, bo to są często aspekty, o których designerzy tak dobrze gdzieś tam nie rozumują. Oni często się skupiają na tej warstwie wizualnej, chcą, żeby aplikacja wyglądała jak najlepiej, a często trzeba powiedzieć: hola hola, tu mamy taką specyfikację WCAG i musimy po prostu podwyższyć kontrast. Wiem, że to nie będzie wyglądało tak dobrze, ale mamy te normy związane z dostępnością, o których musimy pamiętać.

Z mojego doświadczenia często to właśnie Frontend Developer jest takim strażnikiem accessibility w firmie i on właśnie równoważy te aspekty UX-owe. Bo nie da się ukryć, że dość często dostępność i UX trochę są w opozycji względem siebie. Może nawet nie UX, a UI bardziej. Więc tutaj powinniśmy tę wiedzę pogłębiać, bo ona jest doceniana. Coraz więcej się o tej dostępności mówi. Pojawiają się też regulacje w Stanach, w Europie również. Więc obecnie to jeszcze jest, powiedzmy, coś takiego, co nie wszystkie firmy gdzieś tam respektują w pełni, ale na przestrzeni lat będą się pewnie pojawiały kary i też z punktu widzenia samego PR-u to już teraz po prostu wypada, żeby aplikacja była dostępna.

 

Ten wspomniany tutaj narzędziownik warto też – bo myślę sobie, że jeszcze nie trzeba, ale warto – rozbudować o rozwiązania AI. Po tym roku, powiedziałbym, z hakiem, wiemy już, że niekoniecznie będziemy wyparci jako programiści przez właśnie AI, natomiast jest to doskonałe uzupełnienie naszych narzędzi, których praktycznie na co dzień używamy.

Od pewnego czasu bardzo dużo mówicie o tym temacie, tworzycie różnego typu materiały związane z AI, z takim pragmatycznym podejściem do wykorzystania AI przez programistów głównie. Chciałbym Was zapytać, ile faktycznie według Was obecnie jest wartości w tych rozwiązaniach, w tych narzędziach takiego szeregowego programisty?

 

PS: Ja tutaj może skomentuję tę Twoją wypowiedź, Krzysztof, bo Ty z bardzo spokojnym głosem powiedziałeś o tym, że AI trzeba dodać do tego narzędziownika programisty. Z naszej perspektywy, z mojej perspektywy to wcale dzisiaj nie jest takie oczywiste, jak się rozmawia z programistami. Wręcz bym powiedział, że programiści nadal są najtrudniejszą do przekonania grupą, z którą pracujemy np. na naszych warsztatach. Są grupą osób, które naprawdę Chcą to AI prześwietlić z każdej strony, oczekują bardzo wysokiej niezawodności, wręcz stuprocentowej niezawodności.

To są też osoby, które są wrażliwe po prostu na bugi, na błędy, na złe zachowanie aplikacji, więc od razu złe zachowanie sztucznej inteligencji też rzuca im się w oczy. I ja nie byłbym taki pewny, że to jest dzisiaj taka oczywistość. Tzn. Microsoft mówi np., że Copilot jest adoptowany w coraz większej liczbie firm. Open AI mówi, że Chat GPT wchodzi pod strzechy naprawdę dużych przedsiębiorstw, ale wydaje mi się, że jest sporo niepewności albo takiego podejścia, gdzie jednak challenge’ujemy te narzędzia, niezależnie od tego, jakie są powody takiego akurat podejścia do tej technologii.

Być może one wynikają właśnie z tego błędnego wyobrażenia, że to są narzędzia, które jedynie mają na celu zastąpienie programistów albo, że zrobią to za dwa miesiące albo pojutrze. Kiedy podchodzimy do tych narzędzi, nie jak do kolejnego frameworka czy do biblioteki, ale właśnie do czegoś, co ma nas potencjalnie zastąpić, pozbawić nas pensji, wynagrodzenia, możliwości spłaty kredytu, to pojawia się dużo takiego resentymentu, z którym będziemy się musieli po prostu zmagać.

I ja o tym mówię, bo bardzo często to są takie wątpliwości, z którymi najpierw trzeba się rozprawić, zanim w ogóle zaczniemy mówić o czymś takim jak prompt engineering, praca z modelami, komunikacja z API, np. Open AI, bo zdarza nam się zauważyć, że niektóre osoby po prostu mają podejście nie, bo nie.

Natomiast jeśli już po prostu przepracujemy to podejście nie, bo nie, no to tutaj jest cała masa ciekawych pól do eksploracji tego, czym ta sztuczna inteligencja tak naprawdę jest i niezależnie od tego, czy mówimy tutaj o generowaniu kodu, o byciu takim asystentem programisty, wspomaganiu takiej codziennej pracy (myślę, że też to możemy uszczegółowić jeszcze za chwilę), jeśli tylko pokonamy te nasze wewnętrzne wątpliwości, to okazuje się, że w tych narzędziach naprawdę jest sporo wartości, my o nich też jest mowa w trakcie naszych szkoleń.

I widzimy, co ostatnio też wspominaliśmy na naszym shorcie, że na końcu takiego dnia szkoleniowego jest sporo satysfakcji, sporo zaskoczenia i wręcz pytania o to, czy możemy pociągnąć te nasze szkolenia, czy możemy 2–3 dni posiedzieć, popracować z tą sztuczną inteligencją, a przecież to miała być, no sorry za takie stwierdzenie, to miała być przecież ściema, przecież to nie działa, przecież ten kod, który ta sztuczna inteligencja generuje, nie działa, a okazuje się, że jeśli przysiądziemy i przejdziemy przez konkretne ćwiczenia, nad którymi my też spędziliśmy sporo czasu, to tam pojawia się jakaś wartość.

Może tutaj, Marcin, też mógłbyś ze swojej perspektywy powiedzieć, jak ta przygoda z AI wygląda.

 

MC: Na pewno jest dużo takich mitów i oczekiwań, które nie do końca są obecnie przez tę technologię adresowane, ale to samo w sobie nie jest problemem, tylko właśnie to jest kwestia zmiany tego podejścia i może przyjęcie postawy, że to, że kod nie działa od razu, a będę potrzebował 5 minut, żeby go poprawić, zamiast poświęcić 20 minut, żeby napisać go od zera, to to już jest duża wartość dla mnie. To gdzieś tam wykazują różne badania, że tak właśnie jest, więc musimy się pogodzić, że ta praca z AI póki co jest pracą ramię w ramię, właśnie z asystentem, a nie z osobą, która nas z tych zadań wyręcza. To jest bardzo istotne.

Musimy też pamiętać, że są takie obawy racjonalne, przyziemne i są obawy takie bardziej gdzieś tam oparte o science fiction, wyobrażenia, założenia. Jeżeli chodzi o obawy racjonalne, to mamy prywatność i bezpieczeństwo. To naprawdę jest temat, który trzeba zgłębić, żeby w odpowiedzialny sposób, zwłaszcza w kontekście firmy, z takich rozwiązań korzystać. My popełniliśmy darmowy e-book na ten temat, więc jeżeli ktoś chce się dokształcić, to zapraszam na opanuj.ai/ebook i tam można się doszkolić z tego, jak właśnie z takich narzędzi korzystać w sposób bezpieczny, bez naruszania własnej prywatności i prywatności naszej firmy.

Ale mamy też te obawy nieracjonalne, czyli to wszystko związane z nadchodzącą apokalipsą, zagładą, To też są tematy, które są często poruszane w mediach obecnie i też na YouTubie. Bardzo dużo tego typu wywiadów, już nie będę może wprost mówił nazwiskami, bo znowu wywołam niepotrzebne kontrowersje. Tak więc te obawy często rzutują niepotrzebnie na te narzędzia, które mamy do dyspozycji i gdzieś tam właśnie takie obawy długoterminowe, które nie są bezzasadne, aczkolwiek to są rozważania bardziej filozoficzne i po prostu czas pokaże, jak to będzie, niepotrzebnie mają wpływ na to, jak my na co dzień korzystamy z narzędzi, które po prostu mogą nam umilić, przyspieszyć i podnieść jakość naszej pracy – bo myślę, co do tego nie ma większych wątpliwości.

Oczywiście, jeżeli korzystamy z GPT-4, trzeba GPT+, bo tutaj ten przeskok jest bardzo duży, o tym nie wspominaliśmy, ale też wiele osób ocenia możliwości AI na podstawie tych darmowych rozwiązań, a tak naprawdę musimy te 20 dolarów zapłacić, żeby zobaczyć, co to AI obecnie oferuje, bo to właśnie GPT-4 jest takim modelem, który zdecydowanie się wyróżnia na tle reszty.

 

PS: Ja bym właśnie dodał coś jeszcze do tego ostatniego wątku, który Ty, Marcin, poruszyłeś, bo tych alternatyw do chata GPT jest jeszcze kilka, mamy chociażby Barda, mamy ten darmowy czat GPT w Stanach Zjednoczonych, mamy model Cloud, natomiast to nie jest jakby taki progres, to nie jest wybór taki do końca fair, to nie jest tak, że mamy albo wersję plus, albo wersję darmową, to nie jest do kupowania abonamentu, gdzie zyskujemy dodatkowe feature’y, de facto pracujemy z innym narzędziem, kiedy wejdziemy na tę płatną subskrypcję. Więc naprawdę zachęcamy, żeby poeksperymentować.

My też nie mamy żadnej afiliacji z tego, że te narzędzia polecamy, po prostu my z nich korzystamy. I mówię, że to jest zupełnie inny experience, to nie jest do końca porównywanie jabłek do jabłek, ale raczej właśnie jabłek do pomarańczy. Jeśli popracowałeś z Bardem, my też o tym na blogu piszemy i ten Bard Cię zawiódł, to nas to nie dziwi, bo my wiemy, że to jest model, który po prostu potrafi troszkę mniej. Więc GPT-4, tak jak Marcin powiedział, ta płatna subskrypcja, niestety trzeba te 20 dolarów dać, myślę, że w kontekście pensji programisty to jest taki wydatek, na który można sobie pozwolić, ale tam jest tak naprawdę taki state of the art, który też warto przypomnieć jest state of the art tak naprawdę zeszłorocznym, a przed nami relisy kolejnych modeli, które tak naprawdę już wydaje się, że jest za progiem.

 

No tak, są te obawy, o których powiedzieliście. Jest też nieświadomość z tego faktu wypływająca, że nie wiemy, jak korzystać z tych narzędzi. Wydaje nam się, bo właśnie przy takim traktowaniu tych rozwiązań jako maszynki do generowania kodu, jako narzędzia, które ma zdefiniowany interfejs i jedną słuszną metodę korzystania z tego narzędzia, to oczywiście tego typu obawy nieracjonalne mogą się pojawić. Tutaj bardzo dużo zależy od osoby, która wykorzystuje AI, w jaki sposób ją wykorzystuje i tych możliwości otwiera nam się z każdą edycją, z każdym wydaniem coraz więcej.

Wy postanowiliście te dwa światy połączyć, frontend i AI. Na bazie doświadczeń z jednego i drugiego obszaru postanowiliście uczyć innych, jak można wykorzystać te narzędzia AI do tego, żeby tworzyć lepszy kod, żeby tworzyć lepszą dokumentację, żeby pracować nad uczeniem się tych technologii.

Tutaj pojawia nam się temat Waszego szkolenia Opanuj Frontend, z taką szczególną edycją AI-ową. Powiedzcie więcej na ten temat.

 

MC: Opanuj Frontend jest naszą odpowiedzią tak naprawdę na te ogólnorynkowe trendy, ale też właśnie na problemy i oczekiwania Frontend Developerów, które nam zgłosili za pośrednictwem ankiet. Cały zeszły rok tak naprawdę poświęciliśmy, żeby dobrze zrozumieć potrzeby naszej społeczności, właśnie z czym się mierzą Frontend Developerzy, czego nie potrafią, co im przychodzi łatwo. W tych tematach im nie będziemy pomagali, bo skoro sobie radzą, to po co tracić na to czas. Ale są tematy, które właśnie sprawiają im trudność.

To jest to, o czym już mówiliśmy. Czyli to wszystko, co poza tym frameworkiem. I plus to AI, które tak wszystkich fascynuje i przeraża. Chcieliśmy również ten temat oswoić. Opanuj frontend to jest tak naprawdę oswój pracę Frontend Inżyniera, bądź spokojny, że sobie po prostu poradzisz w firmie, że wszystko będzie okej i nie tylko jesteś gotowy, żeby napisać coś w Next’cie, ale również jesteś gotowy, żeby z tym wyjść na produkcję w dużej firmie, w ramach zespołu i wykorzystać do tego narzędzia AI, żeby to zrobić po prostu szybciej, w sposób bardziej komfortowy, w sposób bardziej jakościowy.

Bo te narzędzia AI są świetne, żeby do nich delegować często te zadania, na które nie mamy ochoty, czyli właśnie dokumentacja, też często jakieś generowanie pomysłów, może generowanie argumentów do dyskusji, może przygotowanie feedbacku dla kolegi, skoro sami się nie czujemy komfortowo z tym, jak komuś przekazać słowa krytyki w sposób taki, którego nie urażą, to również AI fajnie sobie radzi z tego typu zadaniami, fajnie również sobie radzi z rozumieniem produktu, użytkownika, więc możemy sobie poszerzać perspektywę, możemy z takim, powiedzmy, kosmicznym stażystą, który jest niby podobny do człowieka, ale nie do końca, rozmawiać, poszerzać swoje horyzonty.

I wydaje mi się, że to jest bardzo ciekawe właśnie z punktu widzenia Frontend Developera, który musi mieć takie szerokie horyzonty, bo to nie jest człowiek, który tylko zajmuje się pisaniem kodu dla kompilatora, ale tak naprawdę wytwarzaniem oprogramowania, które trafia bezpośrednio do użytkownika, użytkownik ma z nim bezpośredni kontakt, więc takie szerokie horyzonty są tutaj bardzo ważne.

 

PS: Może doprecyzujmy jeszcze, dla kogo właściwie przygotowaliśmy ten materiał, bo to też często pojawia się w pytaniach od naszej społeczności. My zbudowaliśmy sobie taki profil uczestnika, Frontend Developera, który ma gdzieś pomiędzy 0 a 4 lata doświadczenia komercyjnego, przy czym to 0 to jest takie 0 z gwiazdką, bo my mówimy o tym, że Opanuj Frontend to nie jest kurs programowania. Tzn. my mamy pewne oczekiwania względem uczestników, chcemy, żeby oni mieli pierwszy kontakt z HTML-em, żeby potrafili poruszać się w świecie JavaScriptu w taki podstawowy, komfortowy sposób. Natomiast w pewnym momencie przychodzi moment weryfikowania siebie na rynku pracy, przychodzi moment sprawdzania Twoich umiejętności przez firmę. Możesz mieć zero doświadczenia komercyjnego, ale możesz być dobrym kandydatem do tego naszego kursu.

Więc tutaj mamy takie dwie postawy. Z jednej strony chcesz uzyskać przewagę na rynku, chcesz wyróżnić się spośród innych kandydatów, którzy np. właśnie zamknęli się na jeden framework, nie interesuje ich infrastruktura, nie interesuje ich utrzymanie aplikacji na produkcji, a ciebie powinno to interesować. Takie jest to nasze stanowisko. Albo jesteś osobą, która ma 3–4 lata doświadczenia z tym midem, który gdzieś powoli zaczyna zaglądać na stanowisko seniora i chce po prostu ten szklany sufit w jakiś sposób przebić, ale nie wie, jak to zrobić, bo np. pracuje w mniejszej firmie, w firmie, gdzie nie realizuje się dużych projektów, chciałby na przykład aplikować w dużych firm produktowych, ale też nie wie, jak te umiejętności zdobyć. I tutaj przychodzimy my, tak nieskromnie powiem.

Przychodzimy z naszym doświadczeniem w pracy w rozmaitych firmach, w pracy, gdzie utrzymywano aplikacje na produkcji 24/7, niejednokrotnie zdarzało nam się reagować na incydenty o 2, 3 w nocy, systemy działały, monitoring był wdrożony, ale nauczyliśmy się budować tego typu aplikacje. I właśnie tym Opanuj Frontend ma być.

I też z naszej perspektywy, tak jak właśnie Marcin powiedział, my bardzo długo się zastanawialiśmy, o czym właściwie powinien być ten kurs, czy to powinien być TypeScript, czy to powinno być może Astro, czy to powinno być Opanuj JavaScript 2, bo tych pomysłów jest sporo, ale chyba wybraliśmy taki najbardziej ambitny z tych projektów, który mogliśmy wybrać. Też nie ukrywam, że sporo wysiłku wkładamy w zdefiniowanie całej agendy, w zbudowanie całego materiału, ale mam nadzieję, że to się przełoży na ostateczną jakość tego, co wydamy.

19 lutego, bo to może warto dodać, nasz kurs startuje, mamy już 85 przynajmniej na dzisiaj, na 23 stycznia, czyli moment nagrania tej rozmowy programistów na pokładzie, a od 19 lutego otwieramy bramy i startujemy tak naprawdę i czekamy na feedback.

 

Czego zatem będzie się można nauczyć i gdzie możemy słuchaczy odesłać, żeby się z agendą zapoznali?

 

MC: Mamy pięć modułów. Pierwszym z nich są wzorce i dobre praktyki. Następnie mamy inżynierię jakości, czyli wszelkiego rodzaju testy, jak dbać, żeby ta aplikacja w czasie nie traciła na jakości. Następnie mamy deployment, wyjście na produkcję, czyli wszystko związane z CI, CD.

Będziemy pokazywali, jak korzystać z GitHub Actions, a później takie dwa bardziej ambitne moduły, też rzadziej, myślę, spotykane we wszelkiego rodzaju kursach, czyli Frontend zespołowo, jak pracować w sposób techniczny nad bibliotekami, jak kontrybuować do projektów inner source, jak korzystać z monorepozytorium, tego typu historie.

I na końcu architektura, czyli jak zadbać, żeby ta nasza aplikacja była szybka, bezpieczna, aby było można ją rozszerzać, utrzymywać w czasie, więc wszystkie te takie tematy, można nawet powiedzieć seniorskie, również na końcu poruszymy i liczymy, że w ten sposób właśnie z osoby, która po prostu umie Reacta i Nexta, wyjdzie osoba, która jest pełnoprawnym, kompletnym inżynierem frontendowym, gotowym do pracy w poważnej firmie.

I jeżeli chodzi o stronę, o której zapomniałem, to zapraszam na opanujfrontend.pl. Tam znajdziecie wszystkie informacje, dokładną agendę.

PS: Ja tylko dodam, że dla słuchaczy tego podcastu też mamy mały upominek dla wszystkich, którzy dotarli do tego momentu. Mamy kod 25% zniżki: POIT. Porozmawiajmy o IT, tutaj reklamujemy też tę markę Krzysztofa, autora tego podcastu, więc jeśli wejdziecie na koszyk zakupowy i wpiszecie POIT, to od nas 25% zniżki. I mamy nadzieję, że po prostu sporo wartościowych materiałów, sporo ciekawej wiedzy, której nie znaleźliście w innych miejscach, uda Wam się tam właśnie odnaleźć.

 

Bardzo dziękuję. Oczywiście te wszystkie informacje będą w notatce do odcinka. Myślę, że Marcin i Przemek dzisiaj bardzo dobitnie pokazali, że wiedzą, o czym mówią, mają dużo doświadczenia w temacie nie tylko frontendu, ale i AI, i ten kurs jest bardzo dobrym sposobem na to, żeby albo wskoczyć do branży, albo rozszerzyć te swoje możliwości i być bardziej pewnym tego miejsca w karierze i miejsca w pracy, w którym się obecnie znajdujesz, Słuchaczu.

Zapraszam oczywiście też i polecam jak najbardziej tutaj panów. Marcin, Przemek, bardzo Wam dziękuję za rozmowę.

 

MC: Dzięki również.

 

PS: Dzięki serdeczne.

 

Powiedzcie jeszcze na koniec, oprócz oczywiście opanujfrontend.pl, gdzie słuchacze mogą Was znaleźć i zapoznać się z tymi materiałami, które tworzycie.

 

PS: Tych miejsc robi się coraz więcej, więc ja tylko powiem, że przeprogramowani.pl to jest nasza strona główna, to jest taki hub informacyjny, tam znajdziecie linki do naszych podcastów, do newsletterów, i też do platformy, którą niedawno uruchomiliśmy.

Chcemy zbudować fajne nowe forum dla programistów, bo wydaje się, że w Polsce brakuje takich przestrzeni, takiego miejsca, gdzie można pogadać o programowaniu bez trollingu, bez głupich zaczepek, z memami, bo memy oczywiście muszą być, więc do tego służy nasza platforma. Ponad 300 osób na tej platformie już na dzisiaj się znajduje, ale myślę, że przeprogramowani.pl i nasz substack i podcasty to są te miejsca, które warto sprawdzić.

 

Świetnie. Oczywiście standardowo wszystkie linki, a trochę ich będzie w notatce do odcinka. Jeszcze raz Wam bardzo dziękuję. Do usłyszenia. Cześć!

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach.

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, co słychać na frontendzie i jak zmieni go AI.

Zapraszam do kolejnego odcinka już wkrótce. 

Cześć!