Tomasz Ducin Odnoszę dziwne wrażenie, graniczące niemalże z pewnością, że ludzie, którzy stali za klepaniem nowego frameworka javascriptowego codziennie, teraz zajmują się AI-em. Świadomość architektoniczna po stronie frontendu jest lepsza, ale nadal jesteśmy w lesie albo gdzieś tam na pograniczu lasu. Nie ma szału. Jest to niejako absurdalne, że do tego, żeby zrobić na przykład stronkę czy podstronkę z formularzem, gdzie w jakiejś większej aplikacji, ale podstronkę z formularzem, Ty musisz myśleć o memoizacji referencji na funkcję. Interfejs, który jest no bardzo ładny, jeżeli go wypromptujesz, bardzo ładny i dla większości ludzi, dla większości frontendowców znajomość CSS-a staje się opcjonalna siłą rzeczy. Bardzo mocno zakwestionować status quo. To, co jest teraz, bo uważam, że jest szkodliwe, jest nieprzemyślane, często jest po prostu głupie.

Łukasz Kałużny: Cześć, słuchacie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka lewo, prawo, góra, dół, ogarniecie, wygooglacie, wyczytujecie albo Patoarchitekci.io. Wierzymy w Was.

Łukasz Kałużny: Dobra, to szybciutko na początek Patoarchitekci.io/szkolenia. Jest jeszcze jeden termin na Agentic AI The Hard Way. To jest taka pierwsza rzecz. Druga, przypominamy o konferencji 16 czerwca. Mamy już prawie zamkniętą agendę. Jak prawdopodobnie oglądacie ten odcinek, to będzie już wszystko na stronie. Z takich rzeczy. I co? Przelatujemy Szymon do odcinka. O czym dzisiaj?

Szymon Warda: Dziś będzie o frontendzie, czyli obszar, o którym zakładamy, że większość z Was trochę wie mniej i nie na co dzień, że tak powiem, a pewnie generujecie większość przez AI-a, o czym też będzie trochę w tym odcinku.

Łukasz Kałużny: Będzie, tak. Rozmowę już nagraliśmy, więc jest trochę rzeczy, które my sami wyciągnęliśmy po niej. I pogadamy teraz o stanie frontendu i ekosystemu z osobą, która naszym zdaniem bardzo mocno się w tym światku przewijała i ma ciekawe, bardzo mocne opinie. No to zacznijmy.

Szymon Warda: Lecimy.

Łukasz Kałużny: Cześć Tomku. Jakbyś się przedstawił słuchaczom, dla tych, którzy Ciebie nie kojarzą, bo tego trochę trudno, jeżeli ktoś trochę oglądał frontendu, to mógł Ciebie, na pewno na Ciebie trafił. W pewnych miejscach.

Łukasz Kałużny: Gdzieś zerknąć. Cześć Łukasz, cześć Szymon i witam wszystkich, którzy nas słuchają. No jestem Tomek, zajmuję się na tym etapie przede wszystkim chyba należałoby powiedzieć architekturą. Przez pierwsze ileś tam lat siedziałem w backendzie, potem przez dekadę na frontendzie. Teraz, że tak powiem, znowu zmieniam, zmieniam barwy, bo jednak po 10 latach mi się trochę znudziło. Co tam? No głównie consulting, w międzyczasie jakieś tam szkolenia, ale zasadniczo to zajmuję się wspieraniem zespołów w jakiejś tam pracy produktowej, tam, gdzie sobie, że tak powiem, własnymi siłami radzą mniej niż biznes by tego oczekiwał. Tak bardzo uogólniając.

Łukasz Kałużny: Słuchaj, dobra, Tomek, to pytanie rozgrzewkowe będzie od razu zabawne, ale jak popatrzymy 77% stron w internecie używa jednej specyficznej technologii. Pewnie już się domyślasz której, jak o tym mówię.

Tomasz Ducin Zaczyna się na J?

Łukasz Kałużny: Tak, dokładnie. I powiedz mi, bo wyszła w tym roku nowa wersja. I co sądzisz o tym jQuery 4.0? Przepraszam, musiałem, jako że rozmawiamy o stanie frontendu, więc musiałem o to zapytać na dobry początek.

Tomasz Ducin Powiem tak, no jest to chyba optymistyczne i pozytywne, że to co nadal bazuje na jQuery, czyli tak jak mówisz, dosyć duża liczba stron, chociaż pytanie jeszcze w jakim zakresie tego używają, ale że jednak ma to jakieś update’y, jest utrzymywane. Tam z tego co kojarzę, to chyba ta wersja 4 to ohoho ile to lat było? W sensie, że pracowali nad tym, ale to się naprawdę długo zeszło. Nie wiem czy nie za dekadę, ale jakoś tak, jakoś oporowo długo.

Szymon Warda: Angular żyje krócej.

Tomasz Ducin Long term support, to jest powód do radości. A to, że wiesz, z tych 77 stron, nie wiem, strzelam, że 90% pewnie mogłoby to jQuery bardzo małym narzutem pracy pewnie zaorać. Ale z drugiej strony jakby…

Tomasz Ducin Działa.

Tomasz Ducin So what?

Łukasz Kałużny: Przy tym odcinku, bo mam akurat u klienta, mamy taką małą smart aplikacyjkę, która kiedyś była napisana i miała jQuery, oparta była o jQuery, bo był tam jeden gotowy plugin do uploadu plików. Ona na siebie nieźle zarobiła, ale wczoraj poleciał update gdzie to jQuery… Inaczej, modernizujemy stos, Bootstrap 5 i jQuery wyleciało, dokładnie. Ale słuchaj, działało Tomek. I wiesz, i tak patrzę na to i to był pomysł, żeby zacząć w ogóle. Dobra, to chyba co, rozgrzaliśmy to Szymon, przejdźmy już z żartów na poważne tematy.

Szymon Warda: Ale to jest dobre przejście, bo właściwie tak naprawdę kiedyś frontend to były takie minimalistyczne właśnie, proste jQuery i się leciało, hulaj dusza, piekła nie ma. No a teraz mam wrażenie, że ten frontend to już jest taka zupełnie inna bajka, inna architektura. Zakładam, musimy w sumie zrobić jakąś ankietę, że słuchają nas głównie backend developerzy, ludzie, którzy nie siedzą tak mocno we frontendzie. Powiedz jak właśnie wygląda obecny stan frontendu? Jak to się ma? Co jest popularne? Jak ten ekosystem wygląda? Co tam się w ogóle dzieje?

Tomasz Ducin Jeżeli chodzi o to, co powiedziałeś, że tam kiedyś to były, tam wiesz, jakieś tam jQuery i tak dalej, w sensie tak, ale to było naprawdę dawno. No tak myślę, że z 15 lat temu to już był ten etap przełomowy, więc to trzeba by było sięgnąć jeszcze dalej niż te 15 lat temu. Chociaż wiadomo, że w różnych firmach adaptacja była różna. I jeżeli chodzi o… Znaczy można było spojrzeć na to od dwóch stron, w sensie od, nie wiem, struktury/architektura aplikacji. Z drugiej strony, jeżeli chodzi o tooling, to coś, co jest pozytywnym moim zdaniem zjawiskiem, to jest to, że Dziki Zachód pod kątem toolingu wyhamował. Odnoszę dziwne wrażenie graniczące niemalże z pewnością, że ludzie, którzy stali za klepaniem nowego frameworka javascriptowego codziennie teraz zajmują się AI-em i tam robią nowy framework AI-owy codziennie. Odnoszę wrażenie, że to są ci sami ludzie. I czasem jak zerknę w jakieś tam nazwiska i contributions, to, że tak powiem, potwierdza to moją tezę, chociaż znowu trzeba by to było jakoś dokładniej zbadać. Natomiast jeżeli chodzi o tooling właśnie, to myślę, że jest bardzo stabilnie, więc te żarty co były o tych frameworkach, to myślę, że są, znaczy były adekwatne, ale że już nie są aktualne na tym etapie. Natomiast jeżeli chodzi o architekturę, to w sensie wiesz, w jaki sposób się do tego podchodzi, tak socjotechnicznie, nie? Technologia to jest jedno, a co ludzie z nią robią, to jest drugie. Więc wyzwania stawiane przed aplikacjami są coraz ciekawsze. I to myślę, że tak już od ładnego czasu jednak trzeba się dobrze zastanowić, jak tą aplikację zbudować, jak zależnościami zarządzać. Przy czym nie zależnościami w pakiet JSON, tylko zależnościami wewnątrz aplikacji, jakiejś tam przepływu, jakimiś nie wiem, może domenowymi tematami i tak dalej. Natomiast z mojej perspektywy właśnie takiej consultingowej nie idzie za tym wśród ludzi świadomość/wiedza. I tak jak na przykład środowisko backendowe w momencie rewolucji mikroserwisowej czy tam ileś czasu po tym mocno odrobiło pracę domową. Wiadomo, że nie wszyscy, nie każdy projekt, nie każdy developer, ale jednak ta wiedza architektoniczna nie jest w żadnej mierze niszą, jest raczej powszechnie dostępna. O tyle świadomość architektoniczna po stronie frontendu jest lepsza, ale nadal jesteśmy w lesie albo gdzieś tam na pograniczu lasu. Nie ma szału.

Szymon Warda: A nie masz takiego wrażenia, że właściwie, bo obecnie jest konsolidacja, React rządzi praktycznie, można tak powiedzieć. Coś się, TypeScript też właściwie wygrał tą układankę można powiedzieć całkowicie. Wracają pomysły typu właśnie Server Side Rendering i tak dalej i tak dalej, trochę kręcimy się. Czy to już nie jest tak, że właściwie w frontendzie jest jedna droga na robienie wszystkiego? I czy tam coś się będzie działo? Będzie to rozwojowe? Czy tak mamy stagnację i już temat jest ogarnięty?

Tomasz Ducin Trafne pytanie, ale też bardzo trudne pytanie, bo ciężko powiedzieć wiesz jakie konkretnie czynniki za każdą z inicjatyw stały, kiedy one powstawały. Wydaje mi się, że jest tutaj duży czynnik społecznościowo ludzki, mianowicie sporo innowatorów, którzy swoje pomysły po prostu przekuwali często w startupy. Nawet nie biblioteki, tylko po prostu w jakieś tam wiesz, VC w San Francisco. I wiesz, w ten sposób powstawały buny, w ten sposób powstawały różne inne toolingi, których dzisiaj w większym czy mniejszym stopniu używamy. Aczkolwiek no ja tak na serio bym tutaj stawiał kwestię odpływu pewnej części społeczności po prostu w tematy AI-owe, bo tam jest teraz dużo do odkrycia, tam jest eksploracja, tam się dużo dzieje. Natomiast po stronie frontu jesteś troszeczkę ograniczony do toolingu, znaczy jesteś ograniczony do API natywnego przeglądarki siłą rzeczy z jednej strony. Z drugiej strony i tak jesteś ograniczony do toolingu, który Ci daje NodeJS, który summa summarum jest i tak toolingiem, no jakby nie patrzeć, serwerowym. Więc nie wiem, czy gdyby powstały jakieś super, w sensie nie przychodzi mi do głowy, co mogłoby być następnym The Big Thing. Te problemy, które mamy, które widzimy, co by tu miało jeszcze być dodane? Bo z jednej strony…

Szymon Warda: To Cię jeszcze pomęczymy o tym. Ale mamy parę takich szybkich strzałów generalnie na koniec. Zobaczymy, czy to wejdzie.

Tomasz Ducin Kiedyś było na przykład tak, że tak jak mówiłeś, że zataczamy koło, że byliśmy po stronie serwera, tam jakieś wiesz PHP-y czy inne technologie, gdzie to było jakby dominujące, czy tam JSP, ASP. Potem było wsadzanie wszędzie single page applications czy to miało sens, czy nie miało sensu. Teraz od paru lat znowu wraca razem tam właśnie z Nextem i innymi technologiami SSR. Ale to jak gdyby obserwujemy cały czas to samo, że tak jak SPA było wsadzane wszędzie i czasami bez sensu, nierzadko bez sensu, tak i tutaj SSR też jest nierzadko wsadzane bez sensu. No właśnie, więc wiesz, jeżeli się okaże, że jest jakieś wyzwanie przed konkretnymi aplikacjami, no to pewnie znajdzie się jakieś rozwiązanie. Ale ja nie widzę takich wyzwań, co do których duża część biznesu, dużo aplikacji biznesowych faktycznie by je miało. Natomiast na przykład co się dzieje? Przykładowo Bun czy na przykład przepisywanie różnych bibliotek narasta. To są już takie bardziej kwestia dojrzałości i toolingu, który ma sens, jest wykorzystywany i rozwiązuje jakiś problem, jest przepisywany na technologie, które mogą, znaczy platformę, która może być ciut szybsza, to tam inne są też różnice. Natomiast…

Szymon Warda: Też trochę mody tam jest, nie oszukujmy się.

Tomasz Ducin Tak, ale wiesz, jeżeli coś może być ciut szybsze, to czemu nie? To jest taka krótka piłka, nie? Oczywiście to jest kwestia dojrzałości, czy na przykład tego, że nie wiem, Bun pomija na przykład postinstalle czy preinstalle. To dlaczego coś jest szybsze robić mniej? Nie zrobię Ci postinstalla, czemu nie? Natomiast to już moim zdaniem jest kwestia po prostu takiej dojrzałości.

Łukasz Kałużny: Dobra, słuchaj, jak mamy o dojrzałości, bo idealnie przeszedłeś z tego. Słuchaj, ale jeżeli teraz popatrzymy, bo to jest też pytanie od słuchacza, które padło. Ja sobie tylko zerknę, bo przepraszam, muszę sprawdzić, bo powiem od kogo było, żeby też zachować… Tak, Mateusz Dev na Discordzie rzucił. Czy to jest, i też potem wejdźmy trochę powoli, a potem pójdziemy sobie jeszcze do AI Slopa. Więc AI Slop zostawimy sobie Tomek na koniec.

Tomasz Ducin Nie dotykać AI-a, okej.

Łukasz Kałużny: Tak, aż za bardzo, ale będzie też. W kontekście trochę AI-owym, czy nie uważasz, że jest to też koniec właśnie z tymi nowymi frameworkami, innowacjami, że w dobie agentów AI, jak popatrzymy, słuchaj, wiesz co robią, bo największa reprezentacja danych treningowych to jest React i Tailwind, w Cursorze, w innych. Showdown jest domyślnie na Tailwindzie wykorzystywany, tak jak teraz tam Cursor to wypycha. No i właśnie czy to nie podkręci tylko tego usage’u Reacta i rzeczy na bazie Reacta i nie będziemy robić w korze, w głównych takich zastosowaniach biznesowych, że będzie teraz React, długo, długo nic i kończymy innowację w tym momencie, dopóki przeglądarki się nie rozwiną w jakimś tam konkretnym kierunku?

Tomasz Ducin Czy Ty pytasz o rozwój w sensie rozwój frameworków i technologii? Czy Ty mówisz o rozwoju w sensie na przykład adopcji firm? Bo tak czuję, że są dwie części tego pytania.

Łukasz Kałużny: Wiesz co, to zacznijmy sobie rozwój frameworków. Rozwój frameworków, czy to jest taki koniec, wiesz, mocnych innowacji? Bo są challengerzy na rynku, tam mamy Svelte, mamy Solida, mamy też Astro. Jest tam dużo różnych, ale one są bardzo niszowe w mojej takiej perspektywie. Fajnie się nimi pobawić, ale nikt tego…

Tomasz Ducin To są bardzo fajne technologie, natomiast pracy w tym nie jest łatwo znaleźć. Znaczy przynajmniej w naszej części świata, bo w Stanach znajdziesz wszystko. Jeżeli chodzi o rozwój technologii, to stwierdzenie, że wszystko już zostało wymyślone i nic nie zostanie dodane, to jest bardzo ryzykowne, więc będzie na pewno coś. To co mi chodzi po głowie, co może się coś zmienić, to raczej uproszczenie wszystkiego. Bo jeżeli ktoś siedzi w React’ie dłużej niż rok, to ciężko się oprzeć wrażeniu, że jednak musisz mieć doktorat z programowania funkcyjnego albo innych rzeczy, żeby po prostu pisać te reacty, jakieś duże reacty sensownie. W sensie, że jest to bardziej skomplikowane, niż być powinno. Wiesz, na przykład teraz masz React Compiler, znaczy teraz, od ładnych kilku lat masz React Compiler, który na przykład zdejmuje z Ciebie konieczność, już tam nawet nie wiem, w jakim stanie jest, bo ostatnio jak na niego patrzyłem, to był w becie, nie wiem jak z jego stabilnością, natomiast zdejmuje z Ciebie na przykład konieczność używania różnych tych takich niskopoziomowych optymalizacyjnych tooli, typu tam use memo, use callback i tak dalej. Natomiast w momencie kiedy tego nie mieliśmy, to jest to niejako absurdalne, że do tego, żeby zrobić na przykład stronkę czy tam podstronkę z formularzem, gdzie w jakiejś większej aplikacji, ale podstronkę z formularzem, Ty musisz myśleć o memoizacji referencji na funkcję. Jakby od tego wyabstrahować, to…

Łukasz Kałużny: Na frontendzie.

Tomasz Ducin Na frontendzie, gdzie masz jednego użytkownika, w sensie w przeglądarce jest jeden użytkownik, nie serwer, który obsługuje tam, nie wiem, setki czy tysiące użytkowników jednocześnie z jakimiś tam cache’mi, sesjami, cookie’sami, tylko jakby jeden user. Więc jest to dziwne i myślę, że jest sentyment. Pytanie jak on jest duży. Myślę, że on będzie rósł z czasem, że to jest po prostu przekomplikowane. Ale to nie zmienia faktu, że na przykład coś, co myślę, że zostanie z nami na bardzo, bardzo długo, to jest JSX. Więc ja bym spodziewał się raczej tak, że nie widzę w horyzoncie czasowym czegoś, co by miało zastąpić po prostu taką wiesz, składnię widokową JSX-a. Natomiast myślę, że w oknie czasowym ok. 5 lat spodziewam się, że będzie wzrastał właśnie taka siła sentymentu, żeby jednak zastąpić to czymś prostszym. Chyba, że na przykład React Compiler zdąży czy jakiekolwiek inne toolingi albo jakieś inne eksperymenty w stylu Preact, które stwierdzą, że okej, wyrzucamy rzeczy, które są po prostu przekomplikowane. Natomiast pod kątem, pod kątem jakby zastosowania Reacta, to jest troszeczkę tak, jak taki monopol, który już się toczy jak kula śnieżna, po prostu ściąga wszystko.

Łukasz Kałużny: Chociaż na przykład tam, gdzie widać aplikacje, chyba to jest też e-commerce mocno zaczął, przykład polskiego Allegro i też Ubera, że jest ten Preact na przykład mocno, próba zrobienia czegoś lekkiego na bazie składni Reacta.

Tomasz Ducin No dokładnie, dokładnie. Znaczy składni masz na myśli właśnie JSX-owej?

Łukasz Kałużny: JSX-owej, tak, ale też gdzieś tam kompatybilność, podobne API, nie tylko składnia, ale podobne API, bo nie wiem, wiesz jak patrzymy sobie właśnie mówię o, mam tutaj na myśli Preacta, że to jest chyba taki wątek, który trochę odwzorowuje to, co powiedziałeś, że trzeba coś lżejszego, ale być może z bardzo podobną składnią i podejściem.

Tomasz Ducin Znaczy dzisiaj, w 2026 roku, gdybym ja miał coś startować, to mój wybór padłby na framework, który znam z tych trzech dużych najmniej, czyli na Vue. Ponieważ prostota użycia jest niesamowita, bariera wejścia jest bardzo niska. Robisz szybko i tooling oraz wsparcie społeczności jest bardzo, bardzo szerokie. Bo na przykład Angular jest niszą. Natomiast też bariera wejścia do Angulara, wiesz, kiedy chcesz robić coś na poważnie, to jednak jest dosyć wysoka. Moim zdaniem bariera do robienia Reacta dobrze też jest wysoka. A Vue Ci zdecydowanie więcej wybacza. Nie ma tak dużo konceptów i wydaje mi się, że… Znaczy nie ma tak dużo konceptów właśnie związanych z tymi, z takim zboczeniem wokół referencji.

Łukasz Kałużny: Dobra, jestem dinozaurem, bo patrzyłem na Vue w wersji 1.0, to pamiętam te czasy.

Tomasz Ducin Nie, to się dużo zmieniło.

Łukasz Kałużny: Tak, ale wtedy był już przyjemny. W sensie był lekki. Ja pamiętam, właśnie było tak, że…

Szymon Warda: On zawsze był prosty. To była duża przewaga.

Łukasz Kałużny: Tak, pamiętam, że po zobaczeniu… Bożesz, tak, dobra. To jest ten. Przypomniałem sobie Szymon te AngularJS-y, pamiętam.

Szymon Warda: Tak, pamiętam, (…)

Tomasz Ducin Ale to jest tylko składnia.

Szymon Warda: I miliony plików.

Tomasz Ducin Znaczy ta składnia dla mnie też wygląda trochę dziwnie z tymi jakimiś tam dyrektywami zapiętymi, ale to jest tylko składnia. W sensie jak przymknie oko na tą składnię, to summa summarum to jest proste. Czy masz proste, masz takie bardzo proste reguły, że na przykład stan musi być zainicjalizowany na obiekcie, bo wtedy podczas inicjalizacji będzie objęty reaktywnością. Tyle. Nie musisz o niczym więcej myśleć. I to też nie odbywa się na przykład takim performance hitem, jak masz na przykład, wiesz, tam już nie chcę wchodzić w szczegóły, ale na przykład w Angularze też niby tak masz, ale jednak przychodzi to z pewnym kosztem. Bez wchodzenia w technologiczne szczegóły. Ale tak wracając do Reacta, są wiesz, firmy, które, w sensie takie bardzo duże korporacje, że tak powiem, z silnymi tradycjami technologicznymi, tak to ujmę, które siedzą na przykład w Angularze i one z tego Angulara też nie widzę, żeby miały jakkolwiek wyjść. Natomiast patrząc, w sensie one też będą generowały w cudzysłowie oferty pracy. Więc myślę, że nie obudzimy się w takiej rzeczywistości na przykład za dwa lata, że będzie tylko React albo za trzy lata, nie będzie tak.

Szymon Warda: Okej, a teraz wejdźmy na trochę taki poziom wyższy, bo mówimy sporo o React’ie, mówimy o Angularze, mówimy o Vue. Ok, spoko loko. A trochę z innej perspektywy, bo kiedyś dużo słyszeliśmy, był mega hype na… Były mikroserwisy, to na frontendzie były mikrofrontendy. Dyskusja odnośnie monorepo, polirepo i wszystkie te legacy. Jak w ogóle wyglądała architektura, te klocki budulcowe? Z czego się składa? Jak się podchodzi do wszystkiego? I na koniec pytanie za 100 punktów, mianowicie jak się ma DDD na frontendzie? Wiem, że szeroko, szeroko, więc możemy zacząć od w ogóle podziału frontendów, jak to w ogóle wygląda?

Tomasz Ducin Powiem tak, bardzo dużo różnych wzorców czy stylów architektonicznych ma swoje odwzorowanie na frontendzie i mechanika jest podobna. Natomiast bardzo też sporo z nich może być totalnie przestrzelonych pod kątem frontu. Przykładowo coś takiego jak, czasami na przykład dostaję takie pytania: czy warto robić na przykład architekturę heksagonalną na frontendzie?

Szymon Warda: Co?! Że jak w ogóle?

Tomasz Ducin Wiecie ludzie są…

Łukasz Kałużny: Wygrałeś Tomek. Wygrałeś.

Tomasz Ducin Ludzie słyszeli, więc są ciekawi. Natomiast są problemy takie, że tak powiem, wspólne, na przykład z zależnościami, czy na przykład w jaki sposób moduły się powinny ze sobą komunikować. I tu jest na przykład moim zdaniem jedna z głównych elementów pracy domowej dla środowiska frontendowego, mianowicie po stronie backendu, gdybyś chciał mieć dwa moduły niezależne od siebie…

Szymon Warda: Proste.

Tomasz Ducin Czy pierwsza rzecz, o której pomyślisz, to sprawić, żeby bazowały dokładnie na tych samych tabelach w bazie danych, jeszcze w szczególności, wiesz, tak że…

Szymon Warda: Nie do końca.

Tomasz Ducin No właśnie. I teraz przejdźmy na stronę frontendu. Czy pierwsza rzecz o tym, o czym pomyślisz, to jest na przykład zrobić globalny store, w którym każdy moduł ma dostęp do tego store’a? W wykonaniu większości frontendowców - tak. W wykonaniu większości frontendowców. I to mam na myśli mówiąc o pracy domowej, gdzie problematyka jest dokładnie ta sama, siły fizyczne, jakieś wypadkowe są dokładnie te same. Czy na przykład to, że nie wiem, dla backendowca to, że takim, nie wiem, reguła kciuka, jeżeli chcesz uniezależnić, to pierwsza rzecz, o której myślisz to są eventy. Nie zawsze to jest optymalne, ale to jest pierwsza rzecz, o której myślisz. To czy to będą eventy in-memory, czy będzie jakaś kawka, czy coś innego, to jest jakby temat jakiś wtórny. Natomiast przykładowo, na przykład to jest architektura, którą ja rekomenduję i ja polecam, że jeżeli ktoś pracuje w systemie, w którym jest więcej niż jeden zespół, więcej niż jedno zwierzę, gdzie jest czynnik taki organizacyjny, że chcemy mieć niezależność zespołów od siebie, to wypadałoby pomyśleć o jakiejś tam kombinacji vertical slices czy zasadniczo o tym, żeby ten monolit był modularny. W ogóle na frontendzie, nie wiem, 95% projektów, które widzę, to są niemodularne monolity. Od tego zacznijmy. Tak w tej definicji backendowej.

Szymon Warda: Na backendzie nie jest wcale dużo lepiej, bym powiedział.

Tomasz Ducin Dobra, tylko w dalszym ciągu to nie jest wiedza… Znaczy inaczej, przepisać backend wydaje mi się, że jest często trudniej niż przepisać frontend. Zresztą frontendowcy często lubią czy lubili, nie wiem, teraz chyba zajmują się AI-em, brać i przepisywać swoją aplikację na nowy framework. No i zasadniczo nie zdziwicie się, że to było przepisywanie na nowy tooling, ale dokładnie tej samej myśli technologicznej, tych samych konceptów i wizji, jak to ma wyglądać. I na przykład kiedy rekomenduję, że masz na przykład jeden store, który będzie co najwyżej na moduł, o ile w ogóle nie na slice i że te store’y mogą ze sobą rozmawiać eventami. Kurde, jesteśmy w przeglądarce. Jedno z najważniejszych narzędzi, jakaś najbardziej oczywista rzecz dla frontendowca, to są eventy, kurde, ButtonClick event. Nie obsługujesz te eventy wszędzie, że store czy tam jakiś wrapper na store’a może wysyłać event, na który drugi store będzie reagował. Ale tego nie ma w dokumentacji. Nie, nie, wiesz, tak nikt nie robi. To jest tak mentalnie to momentami jest kilka, kilka wieków do nadrobienia. Więc problematyka w dużej mierze myślę, że jest bardzo zbliżona. Tak jak mówię, na przykład nie wiem, heksagony, oniony i tak dalej, to jest gruba przesada. Czy na przykład nie wiem, jak wejdę w środowisko angularowe, to na przykład nie będziesz widział pliku, który Ci strzela, w sensie może to być jakaś klasa, może być obiekt, może być zestaw funkcji, wszystko jedno, które na przykład strzelają żądania HTTP. Niektórzy to nazywają API, niektórzy to, ja na przykład to nazywam HTTP, bo przynajmniej z nazwy wiadomo o co chodzi, ale niektórzy stwierdzą repository. I jakby ok, w sensie nie boli mnie ta nazwa, ale to jest takie dążenie do tego, żeby wsiąść do pociągu i podpiąć się pod ten pociąg, nie wiem, mądrych nazw bez zrozumienia, jakby wiesz o co chodzi. Albo wchodzisz na przykład, nie wiem, na DDD.eu, patrzysz na prezentację, a tam na przykład gość mówi jak robi, bo tutaj zahaczyłeś Szymon o DDD, jak robić agregaty na frontendzie. I sprowadza się do tego, że jak masz formularz, który ma na przykład reguły. Jakie? Reguły walidacji takiej technicznej, że string ma być stringiem, string ma być e-mailem i tak dalej, że to są reguły spójności, których chroni i że to jest agregat i że opakowujesz go repozytorium. I to co mnie najbardziej boli, to jest jakby taki stan mentalny i to, że nie jesteś, nie wiem, architektem, jeżeli po prostu nie nauczysz się kanonu, jakiegoś takiego, jakichś fundamentów, jakichś takich uniwersalnych prawideł, jakiegoś takiego ABC.

Łukasz Kałużny: Dobra, Tomek, bo tak, to pytanie było Szymona, ale się tak wtrącę. Bo jak Ciebie słucham, to mi się taka, to jest takie stwierdzenie, że frontend powinien być tylko od wyświetlania, ładnego wyświetlania i jakiejś wstępnej walidacji, a nie powinien być rozbudowanym tworem i wszystko powinno być obsłużone prawidłowo tak naprawdę na backendzie.

Tomasz Ducin W sensie to jest pytanie czy teza? To jest teza i…

Szymon Warda: To jest teza.

Łukasz Kałużny: Teza, ale co o tym sądzisz, co powiedziałem? Bo ja tak spróbowałem podsumować, bo słyszę trochę żal, że za dużo kombinujemy na tym frontendzie jako branża.

Tomasz Ducin Znaczy wiesz, też zależy kto, bo na przykład czasami wypadałoby pewne rzeczy bardziej rozbudować i przemyśleć, a jest na przykład totalna olewka i ignorancja. Więc jak gdyby zależy gdzie ucho przystawisz. Natomiast tam gdzie się pojawia jakaś tam myśl architektoniczna, to moim zdaniem wysiłek i są chęci, jest wysiłek, ale niekoniecznie kierowany tam gdzie trzeba. Natomiast a propos tego co pytasz Łukasz, myślę, że summa summarum w wielu aplikacjach tak właśnie powinno być. Natomiast byłbym ostrożny ze stawianiem kwantyfikatora ogólnego pod tytułem, że zawsze i tak dalej. Bo możesz mieć np. aplikację typu real time, nie wiem, przykładowo jakiś Uber, gdzie summa summarum, mimo że masz warstwę prezentacji, czy tam wiesz po prostu interfejs graficzny, to wskutek tych eventów, które potrzebujesz pokazać, tam nawet na stanie wizualnym może się dziać dużo, więc często tak, ale to bardziej taka zasada Pareto 20/80. 80% powiedziałbym tak, natomiast 20% bym sobie tak bezpiecznie założył, że…

Łukasz Kałużny: Słuchaj, edge case’y zawsze będą, to nie jest i takie… Inaczej, sławetne “to zależy”, o, i tutaj trzeba zacząć wymieniać.

Tomasz Ducin Tak, natomiast myślę, że zdecydowana… Znaczy wiesz, też zależy jaka aplikacja, ale zdecydowana większość aplikacji biznesowych, typowo biznesowych, gdzie na przykład wiesz pytanie, które często na przykład zadaję tam rozmawiając o jakimś tam projekcie wstępnie: czego jest w Waszej aplikacji dużo lub na czym, na budowaniu czego spędzacie na przykład większość czasu? I na przykład 2/3 odpowiedzi to jest: no mamy dużo formularzy.

Szymon Warda: Jest to aplikacja biznesowa, normalka.

Tomasz Ducin No tak, no to jest aplikacja biznesowa i nie ma w tym nic złego. Tylko to właśnie powinniśmy dążyć jako inżynierzy, żeby uprościć to, w sensie sprawić, żeby przy tych wymaganiach, jakie mamy i jakie wszystko wskazuje, że będziemy mieli ich jeszcze więcej, żeby optymalizować się właśnie pod to, a nie optymalizować się pod problemy, których nie mamy, które może kiedyś będziemy mieli. I to na przykład, że tam nie wiem, możesz mieć, wiesz, rozbudowane formularze, w których na przykład jedno zależy od drugiego i trzeciego, i tak dalej, czy tam cały ten formularz tańczy. Spoko, będzie tam jakaś jak najbardziej logika, tylko znowu wysiłek na przykład idzie pod tym kątem, że hmm, Node to jest wolny, więc weźmy Yarna. A nie, nie, nie, teraz to jest Bun, a teraz to w ogóle nie, nie, nie, bo tam już nie pamiętam, jak się nazywa ten gość od Vue, to robi znowu jakiś tam, jakąś tam platformę, która ma zastąpić ROM, już nie pamiętam. I znowu tu idzie effort. Ale tak, w większości wypadków to powinna być warstwa po prostu GUI.

Szymon Warda: Słuchaj, a odnośnie mówienia, bo mówiłeś o problemach i tak dalej, to dla mnie takim elementem, który w wielu sytuacjach, znowu generalizuję, mówimy o większości sytuacji, to jest takie trochę generowanie sobie problemów, to są mikrofrontendy. Czy to się w ogóle utrzymało, jak to wygląda? Bo mi tam raz śmignął taki nawet biblioteka, która robi, umożliwia odpalanie Angulara razem z React’em i z Vue jednocześnie na jednej stronie. Czyli takie połączenie wszystkiego i tak dalej. Jak ten nurt się w ogóle obecnie zachowuje? Czy to żyje? Czy to nie żyje? Wycofaliśmy się z tego?

Tomasz Ducin Wiesz co, to jest znowu trochę tak jak po stronie backendu, mianowicie pierwsza rzecz, w którą idziesz, to nie są mikroserwisy, ale tam, gdzie trzeba, to mikroserwisy są odpowiednim rozwiązaniem. Mikroserwisy rozwiązują delikatnie inny problem. Znaczy znowu zależy jak na to spojrzymy, ale oprócz jakiegoś tam skalowania przepustowości, to masz jeszcze kwestie niezależności zespołów. Jeżeli tych ludzi po prostu jest za dużo i potrzebujesz móc wdrażać niezależnie od siebie. I teraz dużo znowu zespołów poszło: a teraz mikrofrontendy są popularne, więc pójdziemy w mikro frontendy. Tradycyjny błąd. Natomiast to nie zmienia faktu, że jeżeli masz produkt, w którym zespołów jest dużo, to jak najbardziej mikrofrontendy mogą być jednym z rozwiązań, bo drugim może być na przykład monorepo, ale to znowu strasznie zależy od tego, w jaki sposób to zrobisz. Ja pracowałem w dwóch produktach, nie jako konsultant, tylko on side full time’owo, w których mikrofrontendy były właściwym rozwiązaniem. Ktoś mógłby powiedzieć: a bo tam, a dlaczego? Bo mieliśmy na przykład w jednym produkcie 20 zespołów rozsianych po całym świecie i tego się nie dało zrobić monolitem. Ktoś mógłby powiedzieć: a przecież to jest problem organizacyjno-ludzki, a nie techniczny. No ok, so what? To co, zmienisz teraz organizację po prostu tu i teraz? Czy biznes mówi musimy to ogarnąć bez przepisywania kodu, który istnieje 15 lat? No jakie masz rozwiązanie? Możesz na przykład zastosować mikrofrontendy i po pół roku mieć architekturę. A żeby zrefaktoryzować organizację, która kupowała dużo innych firm, no to to jest przecież, to jest nierealne, to jest niewykonalne z żadnej strony. I teraz dużo ludzi, którzy po prostu nie mieli okazji pracować w czymś takim, stwierdza, że mikrofrontendy to jest tam, już nie będę brzydkich słów używał. Ok, tylko jak gdyby jest takie coś, nie doświadczyłem pracy w projekcie o określonych wymaganiach, więc na pewno tamto podejście to jest syf. Nie wiem czy to warto jakoś tam więcej komentować, natomiast nurt jest, czy sentyment w społeczności jest taki, że mikrofrontendy są złe. Natomiast moim zdaniem to jest tak samo głupie jak to, że mikroserwisy są dobre albo mikroserwisy są złe. To wahadełko kiedyś było bardzo pozytywne, w tej chwili jest mocno negatywne. Nie doszło jeszcze do jakiegoś takiego plus minus balansu. I nie wiem czy dojdzie. Znowu, jeżeli nie ma takiej sytuacji, bo zasadniczo problemu skalowania ruchu czy tam przepustowości po stronie frontendu no siłą rzeczy nie ma, więc pozostaje Ci skalowanie pracy developerów. Więc pytanie jak dużo produktów jest rozwijanych razem z częścią frontendową przez na przykład nie wiem, co najmniej 5 zespołów? Bo wtedy faktycznie realnie tam wiesz, tam te wszystkie przecięcia w wielokącie i tak dalej, wtedy możesz mieć dużo różnych zależności. Więc wydaje mi się, że nie tak dużo, ale to nie jest pierwsza głupota, która krąży po społeczności.

Łukasz Kałużny: Dobra, słuchaj, jak jesteśmy przy głupotach. Idealnie słuchaj Tomek to podsumowałeś.

Tomasz Ducin Płynne przechodzenie z tematu na temat.

Łukasz Kałużny: Dokładnie.

Tomasz Ducin Nieświadomie.

Łukasz Kałużny: No to co, lecimy z AI slopem, bo nie mogło go… Inaczej, wiemy, że nie mogło go zabraknąć, niektórzy już zwymiotują jak usłyszą AI, ale dobra, taka jest prawda. I tu jest chyba, w ogóle jakbym miał popatrzeć na obszary, to jest chyba jeden z największych boostów, poza IaC-em, w frontendzie. To taka moja perspektywa, jak popatrzymy. I słuchaj, może tak, patrząc się, bo chciałbym trochę porozmawiać tutaj, Cię podpytać o przyszłość i inne takie rzeczy. Ale zacznijmy od pierwszej rzeczy, którą wiem, że też traktujesz z przymrużeniem oka, czyli wszystkie v0, czy jak to się tam nazywa, od Vercela, Bolty, Lovable i cały ten pseudo vibe coding, teraz modny chyba z Antigraviti, jak przeglądam newsy. I co sądzisz o tym całym AI slopie, o tak, który teraz powstaje od tej strony takiej - ludzie rzucili się i po prostu generują aplikacje nie wiedząc w czym. Nawet Ci, którzy mają doświadczenie jednak w IT.

Tomasz Ducin Wiesz co, zadałeś trzy pytania co najmniej w tym jednym pytaniu.

Łukasz Kałużny: Dobra, ale zacznijmy sobie od vibe codingu frontendów.

Tomasz Ducin Vibe codingu, to zacznijmy od definicji. Przez vibe coding ja rozumiem i tej definicji się trzymam, sytuację, w której tworzysz kod i praktycznie go nie nadzorujesz, nie weryfikujesz. Tak ja to rozumiem. Nie wiem czy Ty rozumiesz tak samo?

Łukasz Kałużny: Podobnie, ja jeszcze rozbijam to na promptowanie na pałę dodatkowo. Definiuję to jako promptowanie na pałę bez…

Tomasz Ducin Vibe prompting.

Łukasz Kałużny: Vibe prompting, tak.

Tomasz Ducin Wiesz co, myślę, że bardzo dużo zostało powiedziane o vibe codingu trzeźwego. Jeżeli chodzi o rozwój profesjonalnych produktów, no to nie wiem czy tu trzeba coś dodawać, że to nie jest dobra ścieżka. Natomiast żeby nie było, sensowność w ewentualnym vibe codingu widzę taką, jak na przykład nie wiem, idziesz do klienta i chcesz coś, że tak powiem, wymłotkować, żeby zobaczyć czy na przykład kierunek rozwoju jakiegoś, nie wiem, modułu czy nawet jakieś podaplikacji jest ok. I naprawdę Cię wtedy wali, czy tam będzie TypeScript, czy nie TypeScript, czy będzie framework, czy nie framework, byleby to było jakkolwiek klikalne, byleby biznes albo użytkownik na przykład, z którym robisz jakieś badania, czy jakieś takie prototypowanie, takie rapid prototyping, to tutaj widzę zastosowanie tego. Bo przykładowo dlaczego… W ogóle nie ma trochę kultury, przynajmniej z tych produktów i tych firm, w których ja, z którymi ja pracowałem, nie ma kultury tego, że programista, w szczególności frontendowy, siada z klientem albo siada z biznesem i rozmawia o tym, jak to powinno być, żeby taki… Znaczy to, o co chodziło w Agile, to o co chodziło w pewnym sensie w DevOpsie i tak dalej…

Szymon Warda: Minęło.

Tomasz Ducin Tak, to, o co w tych wszystkich transformacjach chodziło, to jakoś tak cały czas to ginie. Więc wydaje mi się, że pewnym okienkiem, które daje nam vibe coding czy ogólnie cały ten AI slop jest to, że rapid prototyping może wreszcie stanie się standardem, że można wiesz, naklepać stronkę, pokazać biznesowi, biznes mówi: wiesz co, delikatnie inaczej. Minuta i masz, albo pół minuty i masz.

Łukasz Kałużny: Mi się przypomina właśnie…

Tomasz Ducin I tu widzę sens.

Łukasz Kałużny: I wiesz co, teraz śmieszne, bo jest tam, Andrzej Krzywda też chyba u nas wspominał, że właśnie jego przewagą w Railsach, wtedy to był, mówił chyba z 20 lat temu prawie, o tak, z prawie 20 lat temu mówił, że przewagą było to, że był w stanie pokazać prostą makietę z formularzami ad hoc na spotkaniu w Railsach, że był w stanie. I to, co teraz Ty mówisz, tak, ciągle rozbija się o to, że ludzie chcą coś zobaczyć, a nie usłyszeć i powiedzieć o tym. A drugie, nie komunikujemy się. Ale to już…

Tomasz Ducin Też myślę, że klikalny interfejs przemawia lepiej niż prezentacja w PowerPoincie pod kątem sprzedażowym. Przynajmniej dopóki to nie jest standardem. Bo jak to będzie standardem, no to będzie twardym wymaganiem. No ale nie jest standardem dzisiaj.

Łukasz Kałużny: Tak, nie jest. Dobra, a teraz…

Tomasz Ducin Wię tu widzę sens. A poza tym to…

Łukasz Kałużny: Dobra, a teraz przejdźmy sobie, AI slop, ok, a przejdźmy sobie teraz, słuchaj Tomek, już o faktycznym, bo też się… Inaczej, wszyscy się tym zajmujemy, Ty też się zajmujesz tym, faktycznie wykorzystanie narzędzi agentowych do odciążenia, dostarczania tego kodu frontendowego. Jaką Tutaj masz opinię w tym miejscu? Być może jakieś polecajki co do procesu, może jakieś rzeczy, które wstawiasz w swoich configach u klientów w CI-u? Więc jak trochę patrzysz na tą część wykorzystania tego w praktyce, już takiej profesjonalnej pracy, a nie tylko prototypowaniu.

Tomasz Ducin Sporo. Sporo tutaj by było rzeczy. Przede wszystkim, tak jak też zwróciłeś uwagę, modele są bardzo mocno trenowane na kodzie frontendowym i to widać z każdej strony. Nie wiem czy do tych Lovabli i tak dalej jeszcze wrócimy, natomiast sam fakt, że tego typu narzędzia są w stanie postawić Ci, wiadomo, że nie production ready, ale są w stanie postawić Ci interfejs, który jest bardzo ładny, jeżeli go wypromptujesz, bardzo ładny i dla większości ludzi, dla większości frontendowców znajomość CSS-a staje się opcjonalna siłą rzeczy, wskazuje, że jesteś w stanie naprawdę lwią część roboty zakodować. Więc ja jak najbardziej jestem za tym, żeby lwią część frontendu jak najbardziej generować modelem. Natomiast też podkreślam, że są rzeczy, których nie powinniśmy oddawać modelowi np. projekt modularyzacji, czy tam szumnie mówiąc architektura. Czyli przykładowo w jaki sposób podzielić aplikację na moduły na przykład wiesz, use case’ami, czy jakimiś tam subdomenami, czy w ogóle, żeby skoncentrować się przede wszystkim na tym, że rozdzieliliśmy się kiedyś technologicznie, frontend i backend, i wydaje mi się, że to jest moment, w którym powinniśmy się z powrotem, że tak powiem, złączyć i przestać się dzielić na jedno i drugie. I gdybyśmy myśleli holistycznie, kompleksowo, od frontendu aż po bazę czy tam infrastrukturę per moduł, dużo problemów, które są na frontendzie by zostało zredukowanych, albo może nawet i by zniknęło. Przykładowo, generujesz sobie jakiś tam, wiesz, kontrakt, z którego generujesz, wiesz, typy TypeScript’owe, jakieś Swaggerowe, czy cokolwiek innego. Przestajesz nagle, w sensie lwia część roboty Ci w ogóle całkowicie odpada. Tylko znowu, musisz przemyśleć sobie czy dany interfejs, czy dany jakiś tam DTO, czy on będzie wspólny między modułami, czy on będzie osobny. To są rzeczy, nad którymi powinniśmy się zastanawiać. I teraz, jeżeli masz na przykład, nie wiem, tworzysz skilla czy tworzysz subagenta, czy cokolwiek byś miał w swoim toolingu, który by Ci wyznaczył kanon, w jaki sposób stawiać granice między modułami i te granice to jest coś, czym Ty się powinieneś zajmować. Natomiast jeżeli masz dodatkowo, znaczy też jestem fanem, aczkolwiek gdyby ktoś używał czegoś innego, to wiadomo, że można używać czegoś innego. Gherkin i Cucumber, mianowicie piszesz w języku naturalnym, wiesz, specki, given-when-then i co jak co, ale one pasują jak ulał do językowości, do językowej natury LLM-ów. I wiesz, oczywiście tam pod spodem masz framework jaki chcesz, to może być Playwright, to może być Cypress, to mogą być testy integracyjne typu V test i tak dalej, ale jak najbardziej to się spina. Znaczy tam w angularowym toolingu jest trochę trudniej, ale w Reactowym wiesz, napisać testy gherkinowe. W sensie masz masz plugin gherkinowy do praktycznie każdego frameworka testowego, jesteś w stanie opierdzielić lwią część roboty. I nie ma większego znaczenia, jeżeli odpowiednio ustawisz właśnie modularyzację, czy tam masz use state’a, czy masz use reducer, czy masz reduxa, czy masz jakieś, wiesz, uje muje dzikie węże, to przestaje mieć po prostu znaczenie. I ogromna część wysiłku, który szedł w dyskutowanie, czy ta biblioteka do zarządzania stanem, czy ten styl, czy styl w sensie patent, albo czy takie style, czy komponenty powinny być większe czy mniejsze, te problemy stają się problemami tak bardzo mikro, one tak bardzo są bez znaczenia, moim zdaniem, że to otwiera pod kątem frontendu niemalże może nie nowy styl w SDLC, ale, zastanawiam się jak to nazwać, może nie nowy paradygmat, bo to za dużo powiedziane, nie nowy styl, ale podejście, w którym można powiedzieć stawiasz granicę, definiujesz wymagania, a model niech po prostu robi implementację znośną. I teraz, jeżeli na przykład nie stosujesz stanu globalnego, to na przykład nie otwierasz się na problem, który w wielu aplikacjach reduxowych istniał. To znaczy ludzie nie umieją używać Reduxa, więc na przykład robią selector z całego stanu. W dużym skrócie to powoduje to, że selector jest… Znaczy źle używają selectorów, że selector za często się odpala. I to powoduje lagi na dwie sekundy, na trzy sekundy, że klikniesz coś i wiesz, freezuje Ci się przeglądarka. To nie jest Redux zły, to po prostu ludzie nie umieją go używać. Natomiast jak na przykład nie masz store’a globalnego, no to problemu też nie ma. Komunikujesz się eventami i wystarczy, że masz jeden moduł zaimplementowany przykładowo, w sensie ja takie rzeczy robię, także u klientów, gdzie jesteś w stanie z wymagań i z takich właśnie guard Railsów wygenerować lwią część. Oczywiście poprawiasz, natomiast to rewolucjonizuje sposób robienia frontu o tyle, że wysiłek i effort przesuwa się w zupełnie inne miejsce. I jestem zdania takiego, że tak, nie musisz czytać całego kodu, a jeżeli robisz to dobrze, to nie musisz czytać większości kodu, bo naprawdę masz testy. I tutaj testy są takim warunkiem absolutnie krytycznym. Na przykład co ja czytam? Czytam kontrakt od deski do deski, w sensie linijka po linijce, całość. Czytam testy, gherkiny, całość, bo nie mogę ufać testom, co do których nie mam pewności, że one robią dokładnie to, co trzeba. Oglądam też te testy, w sensie end-to-endowe na przykład, czy tam UI-owe. Chcę je zobaczyć, że one faktycznie robią to, co trzeba. I jeżeli na przykład z kontraktu widzę, że modularność jest ok, widzę na przykład, że eventy, które są wysyłane między modułami są ok, widzę, że testy przechodzą i na przykład może być komponent, który ma 400 linijek. Co mnie to obchodzi? Przeklikam sobie profilera, żeby zobaczyć czy to ścierwi. Ale co mnie to obchodzi, że on ma 400 linijek. I ogromna część wysiłku nagle okazuje się, że jest wolna.

Łukasz Kałużny: To chyba ja miałem ten, bo miałem, prowadziłem w zeszłym tygodniu warsztat akurat z technologii zupełnie backendowych i frontendu, których nikt nie chce oglądać, bo jakieś… Oracle Forms, o tak, dla tych co słuchają, ojej, ojej…

Tomasz Ducin Brzmi grubo. Oracle Forms.

Łukasz Kałużny: Tak, Oracle Forms, tak, jest taka przedpotopowa technologia. Ale wracając sobie do tego, to ja też, to co mówiłem uczestnikom, że guys, myślenie nie zostało rozwiązane.

Tomasz Ducin Tak.

Łukasz Kałużny: Pewną część kodu będziecie musieli przeczytać, część da się pewnie użyć na pałę w miejscach bezpiecznych, nie krytycznych. No bo trochę jak teraz powiedziałeś, że z tą zasadą Pareto trochę, jak wcześniej powiedziałeś, wychodzi na to, że jak dobrze zdefiniujesz specyfikację i tutaj przez tą specyfikację teraz mam na myśli przykładowy moduł, modularyzację, kontrakty, może jakiś design, tokeny, styl taki gotowy użyty, to reszty tak naprawdę tego wygenerowanego HTML-a nie ma sensu i TypeScriptu, aż tak oglądać, się nad nią męczyć.

Tomasz Ducin Właśnie, powiedziałeś HTML-a, to powiem, że… Znaczy dopóki jakiejś funkcji…

Łukasz Kałużny: Raczej HTML-a wiem, uprościłem.

Tomasz Ducin Dopóki wymagania funkcjonalne są spełnione, to szczerze, nie wiem… Znaczy inaczej, jeżeli strona jest customer facing i na przykład nie wiem, jesteś ogromnym e-commercem albo nie wiem, po prostu masz stronę o masowym wejściu, no to tak, tam potencjalnie będziesz patrzył na HTML-a i CSS-a. Natomiast jeżeli to jest typowa aplikacja biznesowa i nie masz masowego użytkownika, to zaryzykuję stwierdzenie, że oglądanie HTML-a czy CSS-a, jeżeli jesteś ok z Tailwindem, naprawdę nie ma sensu. Ale jeszcze jedno bym dodał, wśród testów jeszcze rzecz, na którą warto było zwrócić uwagę, to jest accessibility. Ale znowu tam jesteś w stanie, tam to się delikatnie zmienia, ale coś w stylu 30-40% zautomatyzować, te 60% tam plus minus jednak trzeba przeklikać ręcznie. Więc są takie rzeczy, które będziesz chciał zweryfikować dodatkowo, ale zdecydowanie bardziej przechodzimy w stronę end-to-end. Ale ważne też, że oprócz HTML-a dodałeś właśnie tego TS-a. Właśnie, czy jest ten use state, czy use reducer, czy cokolwiek innego, so what? Albo przykładowo chcesz też coś, co się przydaje, to na przykład Storybook. Fajne narzędzie, ale summa summarum prędzej czy później ludziom niekoniecznie chciało się to utrzymywać, bo to trzeba utrzymywać ręcznie, dodatkowa robota, trochę tak jak z testami. Miało nas przyspieszać, a nas spowalnia. Tutaj piszesz w rules, czy w jakimś skillu: do każdego komponentu, który trafia do folderu X, ma być stories. I teraz definiujesz to, że coś jest w Storybooku jako jakiś tam atom czy molekułę. Agent wie co to znaczy, bo przecież był na tym trenowany. Śmigasz i wiesz, budujesz z building bloków, w ten sposób też automatyzujesz sobie czym jest biblioteka komponentów. To jest też temat w ogóle w wielu aplikacjach frontendowych, czy tam w wielu produktach frontendowych zepsuty. I to jest bardzo podobnie, co jest w platform engineeringu, tu Szymon, że tak powiem, patrzę na Ciebie, myślę, że Ci to zarezonuje. Mianowicie przerośnięta platforma, która próbuje robić za dużo, staje się blokerem dla zespołów budowania, wiesz…

Szymon Warda: Opus magnum.

Tomasz Ducin Tak, tak, tak, przerośnięte API, które miało pomagać, a po dwóch latach jest problemem i tak dalej, i tak dalej. Nawet niejedna konsultacja mi się w tym temacie i jakiś tam audyt mi się w tym temacie konkretnie trafił. I znowu brakuje takiego zainteresowania, że ok, tak naprawdę to ta platforma, tudzież biblioteka komponentów, ona powinna być bardzo wąska. I teraz, jak zrobić coś takiego, żeby ludzie mogli reużywać effort, czyli na przykład, że zespół X dowiózł coś, ale niekoniecznie reużywać 500 komponentów, że nie ma takiego zastanowienia się, ok, że w ogóle oprócz kodu jest w ogóle proces SDLC, że my tu pracujemy w jakichś cyklach, prawda, jak to będzie się zmieniało, jak to będzie ewoluowało, że publiczne API, które jest strasznie szerokie, że to jest, że to jest koszt, ten temat. Natomiast też nie wiem, jak zwrócicie uwagę na przykład właśnie, tak trochę nawiążę jeszcze do Lovabli i Boltów. Zwróćcie uwagę, że te apki czy te systemy, te silniki są w stanie zbudować frontendy, które dużą część, że tak powiem, wymagań spełniają, bo ładnie wyglądają, są klikalne, można w nich zaimplementować logikę, oczywiście plus minus w zależności od prompta, ale tam poza jakimś tam production ready typu jakieś tam, nie wiem, observability i tak dalej, czy tam nie wiem, testy, storybooki, one bardzo dużo rzeczy dają. Nie chcę powiedzieć wszystko, ale 90% roboty są w stanie za nas opędzić. I jeżeli mamy mieć jakiś backend, to nie wiem, Supabase i OAuth i tyle. A dlaczego nie ma backendu? Dlaczego nie ma takich silników, które stawiałyby backend? O to pytanie zostawiam, że tak powiem, otwarte. Ale z jakiegoś powodu nie ma backendów. I właśnie zastanówmy się nad tym.

Szymon Warda: A ja mam takie pytanie, bo trochę do tego nawiązałeś, rzuciłeś taką myśl, że powinniśmy się jako backend developerzy, frontend developerzy ponownie połączyć. I okej, to będzie gdybanie, bez dwóch zdań. Czy widzisz, jak widzisz w ogóle przyszłość właśnie developerki na frontendzie i właśnie tego potencjalnego połączenia? Jak… Bo AI daje duże możliwości, nie oszukujmy się. Gdzieniegdzie podkłada nogę, ale zmiana będzie. Jak Ty to widzisz?

Tomasz Ducin Na tym etapie przede wszystkim, bo jest taki rozdźwięk w społeczności, że z jednej strony AI pozwala mi robić ho ho ho ho ho, dużo rzeczy i pozwala robić bardzo, bardzo dużo. Natomiast duża część rozdźwięku, z tym, że okej, a gdzie my jesteśmy dzisiaj? Tu i teraz, tam w marcu 2026. Wynika z tego, że bardzo dużo firm, po pierwsze, nie ma, że tak powiem, doregulowanego SDLC pod uwzględnienie w ogóle agentów kodujących w swoim procesie. Wskutek czego na przykład nierzadko zdarza się sytuacja, że ktoś miał zakodować jakiś moduł, ale jakiś inny developer na przykład siadł i w weekend, wiesz, sam sobie doklepał i teraz są dwie równoległe implementacje do tego samego, bo się nie porozumieli ze sobą, ponieważ kiedyś na przykład development trwałby dwa tygodnie, więc w ogóle nie byłoby takiej sytuacji, że dwie równoległe strony by się wzięły za implementację. A teraz czynnik generacji kodu, czy tam tworzenia kodu, produkcji kodu został dramatycznie przyspieszony i można powiedzieć uncovered, odkryty został problem błędów w komunikacji, który wcześniej po prostu nie miał okazji się ujawnić, a teraz ma i trzeba dostosować SDLC. I to zaryzykowałbym stwierdzenie, że to dotyczy 99,9% firm. Natomiast problem jeszcze większy, czy ten blocker jeszcze większy jest taki, że dużo firm nadal albo nie ma pozwolenia na używanie narzędzi AI-owych, albo na przykład ma pozwolenie na narzędzia AI-owe, które są po prostu bardzo, bardzo, bardzo słabe, bez podawania nazw. I to też jest ograniczeniem, które sprawia, że miało być wspaniale i dlaczego nie jest wspaniale? No bo jeżeli wiesz, piszesz jakiegoś prompta i czekasz dwie minuty na to, że on Ci coś odpowie, to jakby cię tylko zirytuje. I ja się nie dziwię, że możesz rzucić to po prostu w cholerę. Natomiast będzie siłą rzeczy rosła ta adaptacja, to po prostu wymaga czasu. Ja widzę to w taki sposób, że siłą rzeczy ewolucyjnie te produkty, które będą dostosowane do developmentu z AI-em, nie wiem, czy to można nazwać AI native, czy nie, ale że po prostu będą miały przewagę konkurencyjną na rynku. Ludzie ludźmi, ale przede wszystkim produkty. Oczywiście to znowu też zajmie trochę czasu. Natomiast tak jak na przykład, nie wiem, dzisiaj nie zastanawiamy się nad Gitem. Jakby jak nie znasz Gita, to nie istniejesz. To myślę, że z perspektywy, nie wiem, trzech lat, na przykład trzech lat, bo wiadomo, że zawsze jest inercja, jest jakiś tam długi ogon, ale że z perspektywy trzech lat, jak nie będziesz znał tamtejszych odpowiedników dzisiejszych skilli, komend, subagentów, to też nie będziesz istniał, bo to będzie taką absurdalną oczywistością, jak dzisiaj jest Git. A nie wiem, 15 lat temu ludzie robili szkolenia z Gita, bo to było novum, ludzie nie znali Gita.

Łukasz Kałużny: Tomek, poczekaj.

Tomasz Ducin Że co, że dzisiaj też nie?

Łukasz Kałużny: Poczekaj, teraz jest dowcip i mówię to na poważnie. Mamy klienta, gdzie pewien zespół, ale akurat nie od strony, od strony ludzi od networku w administracji Windowsami, od nas osoba szkoliła z podstaw Gita i pracy takiej rozproszonej na skryptach i innych rzeczach. I w IT na przykład, tak jak mówisz, że ten, to poza developmentem jest dużo działek, która to co dla nas wydaje się normalne, jak Git na przykład i standard, to oni w ogóle na przykład takich rzeczy nadal używali fileshare’ów i innych rzeczy, żeby sobie trzymać i wersjonować. Więc teraz są zmuszeni przez te narzędzia to poznać.

Tomasz Ducin Znaczy poza developmentem myślę, że też potrzeba na stosowanie Gita być może nie była do tej pory taka duża. W każdym razie… Znaczy ja wyobrażam sobie to tak i pod tym kątem celuję, że to, co robili w większości frontendowcy, to było pisanie kodu. I tak jak na przykład patrzymy na SDLC, czyli zbieranie wymagań, potem dopiero planowanie, projektowanie, kodowanie, wdrażanie, monitorowanie, to większość z tych czynności przez frontendowców nie była wykonywana. Większość, miażdżąca większość to po prostu pisanie kodu. I teraz, tym się będziemy, będziemy się AI-em posiłkować, więc to w dużej mierze nam odpada. I trzeba się zająć zbieraniem wymagań, projektowaniem, planowaniem, monitoringiem, więc tu będzie trochę roboty. Natomiast, no właśnie, jaka jest opcja? Albo na przykład zainteresujesz się produktem szerzej, czyli na przykład full stackowo. Inna opcja, która też mi się wydaje sensowna, to jest na przykład taka, że człowiek o doświadczeniu, o backgroundzie technologicznym, który mniej więcej wie, jak się koduje albo w ogóle kodował wiele lat, czy kodowała, zbliży się do biznesu. Nie mówię tutaj nawet o jakimś tam Forward Deployed Engineer i tak dalej, ale zasadniczo masz doświadczenie z kodem, bierzesz Lovable’a z jakąś tam subskrypcją płatną, idziesz do klienta i tam na przykład wiesz pod jakim kątem na przykład promptować i na przykład ramię w ramię z klientem siedzisz i po prostu robisz te rzeczy. Nie na zasadzie, że jesteś, nie wiem, managerem marketingu albo jakimś accountem, tylko że masz jakiś tam plus minus background, background technologiczny i jesteś, moim zdaniem dla dużej firmy jesteś złotym zasobem, bo idziesz i jesteś w stanie wydusić od klienta nie tylko czy podoba mu się interfejs. Jesteś w stanie wydusić precyzyjnie, bo Ty wiesz jak boli, bo masz doświadczenie programistyczne, wiesz jak bolą niedoprecyzowane wymagania, więc wiesz jakie pytanie zadawać. I jesteś w stanie ramię w ramię z klientem po prostu wiesz, wymłócić z niego wszystkie te pytania. Więc tutaj widzę ogromne pole do popisu dla wielu frontendowców, którzy stwierdzą: a, teraz to już, kiedyś to były czasy, teraz to już nie ma czasów. Sporo ludzi ma też taki sentyment, że fajnie się pisało kraftowy kodzik, a teraz to już nie jest takie, to już teraz nie jest to samo. Więc takie coś widzę. Natomiast to, że ktoś będzie siedział i kodował, tak jak do tej pory, poza jakimiś wyjątkami, niszami, to tego to nie widzę. Ale żeby nie było, nie, że dzisiaj, nie, że w tym roku, ale to tak w oknie dwóch, trzech lat ginęło.

Łukasz Kałużny: Będzie postępowało, tak, to będzie postępowało.

Tomasz Ducin Tylko to nigdy nie będzie overnight, jakaś rewolucja, tylko to będzie taka zmiana zachodząca w tle, po której się człowiek zorientuje, jak zacznie szukać pracy, że te oferty już są zupełnie inne.

Łukasz Kałużny: Ja zawsze daję Tomek przykład, jak bardzo rola database administratora zniknęła. Tak wiesz… Inaczej, nadal są w systemach krytycznych i w miejscach, gdzie trzeba mieć… Ale tych specjalistów jest…

Tomasz Ducin Tak, DB Nazi. A dlaczego? Bo kumaty senior backendowy czy kumaty architekt lwią część roboty zrobi.

Szymon Warda: Nie wydaje mi się, że to jest ten powód.

Tomasz Ducin Ewentualnie jakiś DevOps.

Szymon Warda: Wydaje mi się, że bardziej ten zakres obszaru, gdzie taka baza, specjalistyczna wiedza jest potrzebna, żeby te kwerendy optymalizować i tak dalej, to już tego jest po prostu coraz mniej, ORM-Y wygrały. I często po prostu taniej jest dorzucić pieniędzy, mówiąc bardzo prosto. I to jest taka typowa rola ekspercka.

Łukasz Kałużny: Albo wziąc konsultacje z zewnątrz.

Szymon Warda: Tak, dokładnie. To się zamieniło, że tam jest potrzebna unikalna wiedza, a nie człowiek 24h w organizacji.

Tomasz Ducin Ale a propos optymalizacji bazy, tu też LLM-y wjeżdżają bardzo skutecznie.

Łukasz Kałużny: Tak, wiemy, wiemy.

Tomasz Ducin Bardzo skutecznie. Ja na przykład uwielbiam, uwielbiam dosłownie skonfigurować sobie tak, że pokazuję mu kawałki kodu, w sensie serwerowego, aplikacji serwerowej, gdzie on sobie to tłumaczy pod spodem jaki tam SQL leci. Czasami wchodzi w logi, żeby zobaczyć jaki SQL leci, potem strzela to explain analyzem. I to jest odlot, to jest kosmos. Cudo.

Łukasz Kałużny: Dobra, słuchaj, to Tomku, będziemy trochę podsumować. Jakbyś z tych tematów jakieś takie Twoje dwie rzeczy na temat frontendu, rzeczy AI frontendu, które chciałbyś, żeby słuchacze z tego zapamiętali, z dzisiejszej rozmowy. Albo dwie takie Twoje złote myśli, take awaye, dwa, trzy takie stwierdzenia, które chciałbyś, żeby zapamiętali.

Tomasz Ducin Jedno, to na pewno by było, że jeżeli ktokolwiek pracuje z frontendem albo być może będzie pracował z frontendem niedługo, to żeby gruntownie przemyśleć podejście do modularyzacji frontendów i bardzo mocno zakwestionować status quo, to, co jest teraz. Bo uważam, że jest szkodliwe, jest nieprzemyślane, często jest bardzo po prostu głupie. I iść w kierunku store’ów, co najwyżej na poziomie modułu, o ile w ogóle nie na poziomie slice’a i integrować się eventami. W związku z tym, że aplikacja bardzo często nie działa na iframe’ach, tylko jednak działa w jednym dokumencie, więc jakiś message broker in memory naprawdę w zupełności wystarcza. A nawet jak są mikrofrontendy, to to też da się zrobić message brokera bez żadnego problemu. I to jest znacznie, znacznie lepsze niż jakikolwiek scentralizowany, zglobalizowany stan. I tak samo zależności. Na masę unikać zależności globalnych. A druga jeszcze rzecz, która się z tym też wiąże, to bardzo polecam poświęcić właśnie slow thinking, według Kahnemana, poświęcić, chyba 50 minut to trwa, na obejrzenie prezentacji Grega Younga o tytule Art of Destroying Software, która 12 lat temu, czy tam ileś naście lat temu, znaczy najstarsza jaką kojarzę, to jest sprzed 12 lat, być może była starsza, wizjonerska, jak na tamten czas, gdzie jakby nie było tematu AI-a, Transformers nie istniało, bo jeszcze nie został napisany ten tekst, żeby przesłuchać sobie tą prezentację i przemyśleć jak to się ma do frontendu. I tutaj jakby widzę na horyzoncie nową architekturę czy nowe w ogóle podejście do generowania kodu, gdzie zamiast modyfikować to co mamy i mamy speckę spisaną, czy to w formie jakiejś tam BDD, czy w formie markdownów, czy w formie czegokolwiek, gdzie wygodniej i taniej jest wywalić moduł istniejący, albo w szczególności wywalić malutkiego slice’a, vertical slice’a, bo to tutaj pasuje idealnie. W sensie The Art of Destroying Software + vertical slices + LLM-y, to jest moim zdaniem drużyna zwycięska. Taniej będzie wywalić slice’a i wygenerować go od zera. Polecam tego talka.

Łukasz Kałużny: Wiesz co, aż zaskoczyłeś mnie, że wraca. Ja, Szymon pozwól, że się wtrącę i zapraszam Was na konferencję powtórnie, Pato 200, bo Oskar będzie mówił Tomek właśnie o tym. Czyli, że usuwalność softu jest nadrzędna nad utrzymywalnością, dokładnie i będzie swoje doświadczenia pokazywał.

Tomasz Ducin Tylko pod kątem backendu wydaje mi się, że jest więcej tematów trudnych/krytycznych, więcej tematów do weryfikacji. Pod kątem backendu jest to trudniejsze, żeby to bardziej oddać, oddelegować generowanie. Natomiast po stronie frontendu naprawdę modularyzacja plus tam wiesz, upewnić się, że masz odpowiednio dużo guard railsów. Ale tych obostrzeń, tych wymagań masz znacznie mniej. I ja widzę to w perspektywie na przykład 3-5 lat, że będą produkty powstające, czy tam projekty powstające w tym duchu i że to będzie miało sens. Przy czym na pewno firmy to zchrzanią jakieś, bo zawsze chrzanią.

Szymon Warda: Oczywiście, że tak.

Tomasz Ducin Zawsze, ale że będą produkty powstające…

Łukasz Kałużny: Tomek, my z tego żyjemy.

Tomasz Ducin Tak.

Łukasz Kałużny: Inaczej, zakończmy, żyjemy z tego.

Tomasz Ducin Tak, ale że widzę taki styl architektoniczny, ale to potrwa.

Szymon Warda: Znaczy ja w ogóle polecam bardzo mocno prezentacje Grega, bo są naprawdę uszczypliwe, cięte i inteligentne. Tak że warto, zdecydowanie.

Łukasz Kałużny: Dobra, to Tomku, to kończymy. Dziękujemy Ci za tą rozmowę.

Tomasz Ducin Dzięki wielkie.

Szymon Warda: Heja.

Łukasz Kałużny: Hej.