Mateusz: Hej, to już trzeci odcinek naszego podcastu PiwnicaIT. Dzisiaj razem z Wojtkiem chcielibyśmy porozmawiać o CSSie. O tym w jaki sposób się zmieniał, jak pojawił się na rynku, jak wyewoluował i co może nam zaoferować CSS w dzisiejszym profesjonalnym frontend developmencie. Cześć Wojtku.

Wojtek: Cześć Mateuszu. 

M: I co? Jak Ci się podoba temat CSSa?

W: Myślę, że jest bardzo fajny i tak, jak dobrze zauważyłeś, dotyka on wszystkich. Myślę, że chciałbym zacząć od tego, żeby zabrać nas w podróż do przeszłości i porozmawiać trochę o Twoich i moich doświadczeniach. Chciałbym, żebyś mi opowiedział jak wyglądały Twoje początki. Z czego korzystałeś? Czy to był zwykły CSS czy może korzystałeś z Bootstrapa? Jak pamiętasz wsparcie w różnych przeglądarkach? 

M: Ja zaczynałem od czystego CSSa. I to był CSS w wersji drugiej. Tak, CSS w wersji 2.0 albo 2.1, nie pamiętam dokładnie, która to była wersja, ale na pewno nie były to jeszcze  czasy CSS 3. Nie były to czasy preprocessorów. I były to czasy, kiedy ja się uczyłem pisania kodu, więc pisałem klasy po polsku. Nie miałem problemu z tym, żeby używać identyfikatorów w kodzie css. Bardziej złożonych operacji raczej tam nie robiłem. Pamiętam to bardzo dobrze. Jakiś czas temu wrócił do mnie klient z 2009 roku, któremu robiłem jedną z pierwszych stron internetowych. Ta strona oczywiście już nie istniała, przestała działać po prostu. Tam były case'y takie, że nie klient nie opłacił swojego hostingu i różne tego typu rzeczy. Natomiast udało mi się znaleźć ten kod. Bardzo mu zależało, żeby tę stronę przywrócić. Jak spojrzałem, to się załamałem - tak to było napisane. Bardzo ciekawe doświadczenie. Tak, rzeczywiście, zaczynałem od CSSa od podstaw, czyli od zwykłego CSSa bez zwracania uwagi całkowicie na to, czy specyficzność CSSa jest zachowana, czy kaskadowość jest zachowana. Po prostu pisałem ten kod. Zresztą to tak, jak się pisze pierwsze projekty do szuflady. Tak to mniej więcej w moim przypadku wyglądało. I ten CSS gdzieś tam się przewijał w tych wszystkich pierwszych stronach internetowych. Warto tutaj zwrócić uwagę, że z całej tej wielkiej trójki, czyli z HTMLa, JSa i CSSa - CSS był ostatnim, który powstał. Powstał najpóźniej. Od samego początku, tak jak wszystkie te technologie webowe, miał problem. Miał problem tego rodzaju, że każda przeglądarka troszeczkę inaczej go rozumiała, troszeczkę inaczej interpretowała pewne zapisy. Na pewno pamiętasz wszelkiego rodzaju prefixy, które się dodawało w zależności od przeglądarki, żeby dana funkcjonalność zadziałała albo nie zadziałała.

W: Zdecydowanie pamiętam.

M: To było dość ciekawe. Później troszeczkę preprocessory i wszelkiego rodzaju minifikatory do CSSa bardzo w tym pomagały. Wszelkiego rodzaju task runnery, typu właśnie Gulp, które za pomocą wbudowanych narzędzi, czy też dokładanych przez nas narzędzi, potrafiły nam to wsparcie odpowiednio wyskalować, uzyskać. A później, gdy nastał 2011 - 2012 rok, pojawił się w moim życiu Less, jako pierwszy preprocessor. To był taki projekt, dosyć fajny. To czego mi w CSSie brakowało czyli wszelkiego rodzaju zmienne, tworzenie różnych funkcji czy też tak zwanych mixin'ów - to wszystko tam było. Ten projekt mega mi się podobał. Oczywiście napisałem go byle jak, nie znając wtedy zasad specyficzności CSS, wprowadzałem selektory, które tą specyficzność łamały na każdy możliwy sposób. To były takie czasy. 2011, 2012 - taka można powiedzieć przeszłość, dosyć odległa. Do dzisiaj pamiętam jak chciało się zapewnić wsparcie, np. dla IE dla CSSa, robiło się specjalne IFy w htmlu, po to, żeby inne pliki CSS wczytywały się na przeglądarkach IE. Mam taką anegdotę. Gdy pracowałem w Magento, to było Magento jedynka. W Magento 1 był plik ie6.css, który był wczytywany tylko dla IE6. Jak się wchodziło w ten plik to tak był tylko jeden komentarz. Nie było żadnego kodu. Tylko komentarz: "Let them die". Początki CSSa to całkiem fajna historia. W moim przypadku całkowicie taki język, który pozwalał nam na fajne kolorowanie, fajną wizualizację tych danych, które chcemy przestawić. Na pewno też jesteś w stanie sobie przypomnieć CSSa bez flexboxa czy sposób w jaki musieliśmy tworzyć różne obejścia po to, żeby stworzyć jakąś stronę internetową, która będzie odpowiednio poukładana. Nie koniecznie na tabelkach.

W: Jak najbardziej. Ja też miałem swoje wspaniałe doświadczenia na początku swojej pracy, która chyba zaczęła się trochę później niż Twoja Mateuszu. Pamiętam, że zaczęła się około początków CSS3, chociaż miałem jeszcze okazje pracować z CSSem 2, powiedzmy. Pamiętam wszystkie float'y, pamiętam wszystkie clear'y, które trzeba było robić. Wszystkie tego typu zabawy i zdecydowanie to jak to ewoluowało, i jak to wyglada teraz - myślę, że to jest świetlny krok do przodu, ale to widać we wszystkich technologiach tej wielkiej trójcy, o której wspominałeś, czyli HTML, JS i CSS. Pamiętam też swoje doświadczenie z preprocessorami. Ja akurat zawsze kochałem Sass'a. Nie w wydaniu SCSSowym, tylko w tym wydaniu, powiedzmy, prawdziwym. Bez klamr, bez średników - zawsze byłem zdziwiony, jak zacząłem programować aplikacje w React, które wykorzystywały style SCSSowe, to byłem tak zdziwiony, że one wykorzystują SCSSa, a nie tego Sass'a. Przecież ten Sass jest tysiąc razy lepszy  i tysiąc razy fajniej się go pisze.

M: Powiedz mi w takim razie Wojtku, co Ty robisz w świecie Javascriptu? Czemu nie świat Pythona?

W: Ha. Miałem swoje przygody z Pythonem, ale jednak Javascript to jest to. Jednak technologie frontendowe. Myślę, że nie da się tego zastąpić. Co prawda Python jest bardzo fajny i myślę, że może podczas innego odcinka możemy pogadać o jakiś innych technologiach, z którymi mieliśmy przygody. To też jest temat do ciekawej dyskusji. Jak doświadczenia w innych technologiach wpływają na to, jak piszemy kod w naszych głównych technologiach.

M: Rzeczywiście tak jest. Na pewno pamiętasz czasy, kiedy CSS był w takim stanie, że ciężko się z nim pracowało. Osiąganie pewnych efektów na stronie internetowej, typu osiąganie takiej tabelkowej formy bez użycia tabelek, czyli z wykorzystaniem clearfixów czy też tworzenie różnego rodzaju obejść dla IE było dość kłopotliwe. Na pewno kojarzysz technologię, o której chcę teraz wspomnieć. Twitter wprowadził narzędzie (bibliotekę / framework CSS), które trochę zmieniło świat Internetu. Wiesz o czym myślę?

W: Tak. Domyślam się, że myślisz o Bootstrapie. I jestem ciekawy jakie jest Twoje podejście do niego. Jakie było wtedy i jakie jest teraz? Ja mam dość mocne przekonanie, zarówno wtedy miałem, jak i teraz mam. Chętnie usłyszę Twoje zdanie na temat Bootstrapa.

M: Bootstrap to był taki game changer. Jakbyśmy sobie spojrzeli na świat Internetu w tamtym czasie, to pisanie strony internetowej pod kątem CSSa bez wykorzystania Bootstrapa to była taka trochę droga przez mękę momentami. Dodawanie pustych divów lub na pseudoelementach clearowanie sobie pewnych struktur, aby elementy się poprawnie układały. Bootstrap dał nam gotowe rozwiązanie wszystkich problemów, które w zasadzie mieliśmy z CSSem. Miał jedną wadę, która spowodowała, że cały Internet zaczął wyglądać tak samo. Prawda jest taka, że Internet zmienił swój wygląd. Lata 90. czy początek lat 2000 w świecie Internetu strony internetowe wyglądały tak samo, próbowały zmierzać do maksymalnego odwzorowania świata rzeczywistego. Na pewno pamiętasz strony internetowe gier czy portale gdzie występowały jakieś cienie, jakieś takie belki porobione, że to niby witryna. Tak to mniej więcej wyglądało. Twitter z Bootstrapem bardzo to uprościli. Wprowadzili jedne z pierwszych optymalizacji wyglądu, tak żeby był on maksymalnie spłaszczony, czytelny, prosty. Bootstrap rzeczywiście to wprowadził. To jest tylko kwestia wizualna, pozostaje nam jeszcze tego jak bardzo wydajny był Bootstrap. Biorąc pod uwagę takie frameworki CSS, powstające na rynku, do dzisiaj jest problem wydajności. To nie jest kwestia tylko Bootstrapa od razu trzeba powiedzieć. Bootstrap był jednym z pierwszych, który miał ten problem. Sprawa tego, jak jego kod był optymalnie napisany, jak był wydajny. Bardzo często było tak dużo nadmiarowego kodu, bardzo dużo importantów pododawanych, czyli tych notacji !important, które nadpisują zasady CSSa. To był i jest duży problem. Bo o ile robisz stronę tylko z wykorzystaniem takiego frameworka to nie jest wielki problem, natomiast kiedy robisz taką stronę wykorzystując Bootstrapa jako dodatkowa rzecz do swojej strony, to się może pojawić case, gdzie dopisanie własnych styli może być dość kłopotliwe. Bootstrap zmienił Internet. W moim odczuciu bardzo mocno go zmodyfikował, uprościł i ujednolicił. W tamtym momencie nie była to wada, natomiast po czasie okazało się, że wszystko wygląda tak samo, jak strona example ze strony Bootstrapa. Ale największym problemem był problem wydajnościowy. Chętnie usłyszę teraz Twoje zdanie.

W: Porozmawiajmy jeszcze o tej przeszłości, o której mówiłeś Mateuszu. Przejdziemy jeszcze do tej sekcji jak ten Bootstrap ma się w dzisiejszych czasach i co o nim myślę teraz. Rzeczywiście wtedy, myślę, że nasza część wspólna jest większa, bo zgadzam się z Tobą, że zmienił Internet, uprościł wiele rzeczy i pokazał, że można zrobić taki naprawdę ładny design nie korzystając czy też próbując odwzorowywać elementy ze świata rzeczywistego, tak jak to ładnie powiedziałeś. Większość tych stron rzeczywiście wyglądała strasznie. Myślę, że UI i UX design nie był wtedy jeszcze aż tak rozwinięty. Myślę, że naprawdę niewiele osób się tym zajmowało. Chociaż dla mnie od samego początku Bootstrap był, tak jak mówisz, mało optymalny i dodatkowo zabierał mi to, czego chciałem się nauczyć. Od zawsze chciałbym być frontendowcem, więc to co ułatwił Bootstrap wydawało mi się, że jest kolejnym meta frameworkiem i ktoś zabrał mi część, za którą ja chciałbym być odpowiedzialny. Tworzę coś, czy też buduję z klocków, coś co ktoś wymyślił i jest odebrana mi kreatywność. Zdjęty jest z moich barków ciężar wiedzy, którą czuję, że jako frontend developer powinienem mieć, bo chciałbym się w tym specjalizować. 

M: Mi się wydaje, że to nie jest tak, że on zabierał odpowiedzialność posiadania wiedzy z Ciebie jako programisty. Rzeczywiście, jeśli robiłeś stronę tylko wykorzystując Bootstrapa, nie musiałeś wiedzieć za dużo. Problem pojawiał się wtedy, i to był problem który dotyczył większości projektów, gdy klient nie chciał mieć niestety czystego Bootstrapa. Innym problemem było to, że designer, który mówił że robi z Bootstrapem, tak naprawdę Bootstrapa na oczy nie widział. Wykorzystując z Bootstrapa tylko grid. Grid jako podział na 12 kolumn. Często, nie ukrywajmy, było to źle podzielone, niezgodnie z zasadami Bootstrapa. Pamiętam bardzo dokładnie czasy, kiedy musieliśmy wykorzystywać go, po to, żeby spełnić wymaganie klienta. Klient chciał koniecznie, żeby to było z Bootstrapem, ale żeby też spełniało wymagania designu. Wtedy wiedza z CSSa była niezastąpiona, bo trzeba było dobrze rozumieć jak działa specyficzność, jak działa kaskadowość i dlaczego mój styl css nie nadpisuje tego, co daje Bootstrap.

W: To ciekawe co mówisz Mateuszu, ponieważ ja w życiu nie spotkałem się z wymaganiami od klienta, żeby chciał żeby jego strona wyglądała tak, jak Bootstrap. Ja mam wrażenie, że wybór developerów. 

M: Designerów. A designer szedł do klienta. Ja tak myślę. Jak się sprzedawało strony internetowe? Nie sprzedawał ich programista. Kto miał wiedzę o tym, że tam pod spodem jest jakiś kod? Jakieś mylne pojęcie było tam. Tam jest jakiś kod. Coś tam się składa. Każdy w szkole robił tego HTMLa, CSSa, więc prawdopodobnie to, co jest pod spodem to jest ten kod, którego się uczyliśmy. Tak pewnie sprzedawano stronę pod kątem kodu, ale trzeba zwrócić uwagę, że jak się sprzedawało - to się robiło najpierw design, się mówiło, że to będzie takie wspaniałe, bo Twitter wprowadził takie super narzędzie, które tak optymalizuje czas stworzenia strony internetowej. Designer brał takiego Bootstrapa - wrzucał sobie ten grid do, wtedy, photoshopa. Próbował się wpisać w swój customowy design, tak aby to pięknie, ładnie wyglądało. I z tym szedł do klienta. I to się sprzedawało. Nie to czy ten kod był super świetnie optymalnie napisany. 

W: Ciekawostka dla mnie. Nie spotkałem się z takim case'm. Chociaż myślę, że tutaj różnica pomiędzy doświadczeniami jakie mamy, dość mocno się rozbiega. Nie wiem jak wyglądał początek Twojej kariery, ale ja na początku byłem freelancerem i to w większości to ja sprzedawałem te strony, ja byłem designerem i też byłem odpowiedzialny za dostarczenie tej strony. Myślę, że pewnie dlatego nie miałem tego typu problemów, które Ty opisujesz.

M: Ja nie pracowałem jako designer i bardzo się z tego cieszę. Od samego początku bawiłem się z kodem, projektowałem, ale dla siebie. Współpracowałem z grafikami, którzy starali się właśnie coś takiego dostarczyć. Zresztą w większości przypadków i to do dzisiaj widzę w agencjach reklamowych - szefowie agencji kreatywnych czy interaktywnych są bardziej powiązani z designem niż z programowaniem. W Software House'ach jest zupełnie inaczej. Tam na pierwszym miejscu stoi zazwyczaj kod, a dopiero gdzieś dalej stoi design, co widać chociażby w projektach, w których już w tym momencie jesteśmy. Ten design prawdopodobnie jest, gdzieś tam, ale nie gra pierwszych skrzypiec. W czasach, o których mówimy, czyli w czasach, kiedy ten CSS właśnie był taki ohh, taki sobie, jeszcze nie dojrzały, pojawił się Bootstrap. To on był takim świeżym podejściem. Nagle się okazało, że stronę internetową możesz postawić - taką zwykłą html'ową, css'ową w kilka godzin i ona będzie działać, wyglądać i to będzie wow. To jest optymalizacja rzędu kilkudziesięciu godzin.

W: Zgadzam się, myślę też, że to ciekawy temat do dyskusji. Jak takie narzędzia zmieniają podejście do biznesu i co zyskujemy? Myślę, że większość osób właśnie od takiej strony biznesu nie chce tutaj oczywiście też za bardzo generalizować, ale takie mam wrażenie, że takie podejścia typu Bootstrap są bardzo kuszące z pozoru, z perspektywy właśnie tego, że możemy zbudować praktycznie od razu te strony, tylko tak jak wspomniałeś też Mateuszu, problem zaczyna się wtedy, kiedy zaczynamy coś zmieniać i chcemy, żeby ono wyglądało w jakiś tam sposób. Myślę, że bardzo szybko wtedy ten koszt czy też ten zysk, który mieliśmy na początku, bardzo szybko znika.

M: No tak, to jest Wojtek, ten sam case, który mamy w tym momencie na rynku, z LowCode / NoCode. Klient bardzo szybko zyskuje produkt, ale customizacja tego produktu jest trudna. Jeżeli jesteśmy w stanie dostarczyć szybko MVP, to to jest duża wartość dla klienta. Dlatego agencje, software house'y, które zajmują się LowCode / NoCode, one rzeczywiście są w stanie dostarczyć te produkty fajnie, szybko, tanio i klient jest zadowolony do momentu, w którym ten klient chce mieć custom. Jak on będzie chciał mieć coś zcustomizowanego w szerszym tego słowa rozumieniu albo zoptymalizowanego, to wtedy pojawia się problem. Pojawia się problem, bo nie zawsze jesteśmy w stanie zrobić to narzędziami, które są dostępne w LowCode / NoCode. I ten sam case występował właśnie w sytuacji, kiedy mówiliśmy o Bootstrapie. Okazywało się, że zyskujemy bardzo dużo czasu na tym, że tą stronę tworzymy, bo tworzymy ją bardzo szybko, a nie musimy pisać CSSa praktycznie w ogóle. Okazało się, że pliki, którymi pisaliśmy CSSowe, które miały po kilkaset, kilkadziesiąt, kilkanaście tysięcy linijek, a nagle się okazało, że mają 100 linijek, bo wszystko pozostałe załatwiałBootstrap. Tyle tylko, że pojawiły się case'y w stylu: ok, czy to jest optymalne, czy to wygląda dokładnie tak jak klient chce, czy jeżeli klient chce jakiegoś custom'a, czy to co napiszę będzie zawierało więcej kodu niż gdybym to napisał w czystym CSS. Na tym na tym polu przegrywał Bootstrap. Warto wspomnieć o tym, że Bootstrap nie był jedyny. Zaraz za nim pojawiły się kolejne frameworki CSSowe: Foundation, jeszcze wcześniej Skeleton, ale w zasadzie wszystkie opierały się o jeden podział. Chodziło o podział struktury na kolumny i magiczną dwunastkę podzieloną przez bardzo dużą ilość liczb.

W: Myślę, że jeszcze zapewniały naprawdę dużo gotowych komponentów poza właśnie Grid'em, który rzeczywiście był szeroko wykorzystywany, nawet poza Bootstrapem - zapewniał bardzo dużo elementów i rzeczywiście, jeśli popatrzymy na taki zwykły guzik w HTMLu i guzik z takiego Boostrapa to różnica jest ogromna i zdecydowanie widzę jak to może być przyjemne wizualnie. Jak fajnie, że tak szybko możemy sobie zrobić coś tak ładnego mając relatywnie małą wiedzę.

M: Tak, to prawda.

W: Mateuszu, chciałbym Cię zapytać o jeszcze jedną rzecz. Bo myślę, że dużo tu mówimy o Bootstrapie a było to rozwiązanie też pewnego problemu, czyli tak naprawdę radzenia sobie z CSSem w naszych produktach. I chciałbym Ci przypomnieć o takich rzeczach jak BEM czy SMACS, czy OOCSS, o których mieliśmy okazję już porozmawiać, poznać właśnie Twoje doświadczenia z nimi i dowiedzieć się jak widzisz właśnie te architektury CSSowe w dzisiejszych czasach, w dzisiejszym nowoczesnym webdesign'ie czy też web development'cie.

M: Znasz historię BEMa? Jak się pojawiły na rynku? Może przypomnijmy ją troszeczkę. Tam chodziło o firmę Yandex. W tym momencie geopolitycznej sytuacji nie powinniśmy za dużo mówić o firmie Yandex, ale fakt faktem to jest firma, która jest odpowiedzialna za wprowadzenie BEMa na rynek. To jest właściwie ich koncept z tego co kojarzę i z tego co wiem, BEM jako metodyka CSS został wprowadzony, ponieważ Yandex jako firma produktowa miała bardzo dużo różnych produktów, które współdzieliły CSSa. Miały wiele różnych komponentów, które współdzieliły jeden plik CSSowy i zmiana w tych plikach współdzielonych powodowała, że randomowo wywalały im się różne aplikacje. Wtedy wymyślono właśnie koncepcję, która miała za zadanie oddzielić CSSa w taki sposób, żebyśmy mogli w jakiś sposób enkapsulować sobie te style. Enkapsulować, czyli wyłączać je odpowiednio w zależności od tego, co my chcemy osiągnąć. BEM jako metodyka wprowadził ten podział na Block jako pierwsza literka B, Element i Modyfikator, czyli co do zasady wprowadził koncepcję, która mówi nam o tym, że dzielimy naszą aplikację w sposób, który będzie nam gwarantował niezależność komponentów pomiędzy sobą i jeśli będą one reużywalne, będą samowystarczalne i będą mogły występować samodzielnie, dzięki czemu wykorzystanie tych komponentów czy też ich usunięcie z jakiegoś miejsca w kodzie czy to CSSowym, czy HTMLowym nie wpłynie i nie zniszczy aplikacji jako takiej. Więc metodyki CSS, na przykładzie BEMa, miały za zadanie wyłączyć ten chaos, który w CSS panował. Bo jeżeli spojrzymy na CSSa takiego pisanego bez metodyk, to najczęściej było tak, że randomowo wymyślaliśmy sobie nazwy klas CSSowych. Właściwie każda klasa była albo wraperem, boxem, albo kontenerem, które były pomiędzy sobą wymieszane, zmiksowane, gdzie specyficzność selektorów była dość złożona, to prowadziło do sytuacji, w której trudniejsza zmiana mogła wywołać tzw. efekt motyla. Czyli tutaj zmieniam jedną linijkę, ale okazuje się, że wywaliłem pół aplikacji. I tak mniej więcej wyglądało pojawienie się BEMa na rynku. Później mieliśmy kolejne metodyki Object Oriented CSS, który wprowadzał nam trochę szerszy podział niż tylko Block, Modyfikator, Element. Mieliśmy SMACS i mieliśmy ten słynny Atomic Design, który założył, że co do zasady będziemy robić atomowe klasy CSSowe, czyli takie, które najczęściej będą przechowywały jeden styl. Na przykładzie: będziemy ustalać, że margines górny będzie miał 10 pikseli, więc klasa CSSowa odpowiedzialna za tą jedną właściwość wyglądała np. mt10. Pamiętam, że bardzo mi się spodobał w ogóle jak tękoncepcję poznałem. Tym bardziej, że ją poznałem też z perspektywy architektury aplikacji. Pojawił się koncept, który mówił o tym, że BEMa można traktować szerzej. Można już zacząć przy projektowaniu aplikacji i rozmawianiu z klientem, projektować konkretne bloki, a niekoniecznie całe widoki. Klient akceptuje blok, a my ten blok wdrażamy w naszej aplikacji w naszym widoku. Ta koncepcja bardzo mnie uderzyła i bardzo mi się podobała. Pamiętam jak poszedłem na MeetJS. I pamiętam jak dziś, była prezentacja właśnie o BEMie i chłopak powiedział, że BEM jest super, tylko największą wadą jego jest wymyślanie nazw dla kolejnych bloków. To jest coś co było dość złożone i dość skomplikowane.

W: Tak, historia Bema jest ciekawa. Też zastanawia mnie Twoje zdanie na temat tego jak właśnie takie architektury CSS widzisz w dzisiejszych czasach? Czy one dalej są aktualne? Czy jeśli dzisiaj bym zaczynał uczyć się CSSa, czy zaczynał swoją przygodę z CSSem poleciłbyś, żebym sprawdził sobie właśnie je?

M: Hasłem wytrychem - kluczem w tym wypadku jest enkapsulacja, czyli problem, z którym walczyliśmy w CSS od samego początku. Jak sprawić, że style z danego komponentu będą dotyczyły tylko tego komponentu, a nie będą dotyczyły całej aplikacji? Jeśli mówimy o enkapsulacji, to warto wspomnieć o tym, że są o wiele lepsze sposoby w dzisiejszych czasach niż BEM czy SMACS czy Object Oriented CSS. W przypadku aplikacji frontend'owych: Angulara czy Reacta, możemy sobie tą enkapsulację już ustawić z poziomu z poziomu naszej aplikacji, z poziomu naszego komponentu. W przypadku Angulara jest to dość proste, bo w zasadzie z tego co pamiętam to tam jest po prostu dekorator, gdzie ustawiamy sobie enkapsulację dla naszych styli. Style są bezpośrednio przypisane pod nasz komponent. Nie stanowi większego problemu. W przypadku Reacta mamy kilka podejść tutaj m.in. CSS Modules, ale też traktowanie styli jako Styled komponentów, o których pewnie za chwilę też za jakiś czas powiemy jako współczesne podejście, co też jest wartościowe, czy też traktowanie styli np. z wykorzystaniem web komponentów, co nie jest tak popularnym podejściem, ale też się może się zdarzyć i też można pewnie wykorzystywać to w ten sposób. BEM w tych starszych czasach, kiedy nie było jeszcze tych podejść typu CSS Modules czy Styled Components był na pewno wartościowy i na pewno dawał nam dużo wartości, która pozwalała nam odpowiednio budować, tworzyć taką aplikację, która będzie, jakby to ładnie powiedzieć, stabilna, która nie będzie randomowo się wywalała w różnych miejscach, nieoczekiwanych miejscach, że zmienimy styl jakiegoś przycisku i okazuje się, że nasz mechanizm logowania się wysypał, bo zmieniliśmy jakiś styl. To co miał zapewnić BEM w tamtym czasie, czy też inne metodyki, dzisiaj jest rozwiązywane troszeczkę inaczej. Wspomniałem o Styled komponentach, wspomniałem o technologii, która nazywa się CSS in JS. Jest to dość stara technologia, której początki sięgają 97 roku. Jak na pewno pracowałeś z CSSinJS - chociażby przy Styledkomponentach, co myślisz w ogóle o tym podejściu?

W: Jeszcze niedawno wydawało mi się, że jest to jedyne słuszne rozwiązanie problemu właśnie stylowania w nowoczesnych aplikacjach, czy też super rozwiązaniem, które dawało Styled Components, czy też ciągle daje Styled Components i Emotion - w React było to, że tą enkapsulację styli o których mówisz dostawałeś za darmo, niejako z samym frameworkiem i ten setup Styled Components był relatywnie prosty w porównaniu do tego co się spotkałem z CSS Modules, więc to był duży plus. Ale ogólnie był to dla mnie super świeży powiew. I od momentu kiedy to zobaczyłem byłem zachwycony. Zastanawiałem się jak to jest możliwe, że nie robiliśmy tego wcześniej. Przecież jest oczywiste i kod, który to produkuje jest po prostu świetny. Mamy tak dużą kontrolę za pomocą kodu nad tym, co się dzieje w naszych stylach, że ten kod zmienia się bardzo zbity i łatwy do zrozumienia. Logika, za co kocham Reacta, czyli złożenie tych wszystkich rzeczy, czyli widoku i logiki do jednego miejsca, co moim zdaniem nie powinno być rozdzielone w związku z tym, że koniec końców, tak jak wiesz Mateuszu chociażby przy Angularze, jakby kończymy z tą logiką w widokach. To samo tyczy się też styli. Są takie sytuacje, kiedy jest ogromnie dużo takich sytuacji na Frontendzie, kiedy musimy zmieniać style naszego komponentu w zależności od tego jak wygląda interakcja chociażby użytkownika z aplikacją, czy w zależności od tego co się dzieje na Backendzie. Musimy zmienić kolor, border, shadow, cokolwiek i jest to idealne rozwiązanie jak możemy to zrobić w łatwy sposób. Co prawda myślę, że teraz już te rozwiązania są trochę inne, może nawet trochę lepsze, ale w czasach kiedy pojawiły się Styled Components byłem po prostu zachwycony. Jaka była Twoja reakcja na Styled Components? Czy była równie wspaniała jak moja?

M: Moje pierwsze doświadczenia ze Styled Components dotyczyło aplikacji mobilnej pisanej w React Native dla projektu, którego designer zmieniał projekty co dwie minuty. Co de facto sprowadzało się do tego, że tworzyliśmy komponenty, które wyglądały tak samo, ale miały za to 15 tysięcy wersji. Ja znienawidziłem Styled Components od samego początku za to, że jeżeli design nie był przygotowany od samego początku dobrze albo nie dawało się wolnej ręki programistom, tylko wymagało się pixel perfect, to Styled Components było takim wrzodem na czterech literach. De facto powodowałtworzenie mnóstwa nadmiarowych komponentów, które wcale nie były reużywalne. Później się trochę przyzwyczaiłem do tego sposobu pracy i sam znalazłem dosyć fajne drogi - jak pracuje się ze Styled Components? Jak można to robić wydajniej, lepiej? I rzeczywiście nadal stoję na stanowisku, że albo dajemy wolną rękę programistom, albo bardzo dobrze przygotowany design, jeśli chcemy używać tego typu komponentów, tego typu podejścia komponentowego przy stylach. Natomiast wydaje mi się, że ten komponent ma jedną wadę, której nie zwyciężymy w żaden sposób, czyli wydajność - zdecydowanie we wszelkich metrykach jak byśmy spojrzeli na wydajność styli tworzonych za pomocą komponentów, to z tego co kojarzę to CSS Modules czy zwykły CSS bije na głowę po prostu rozwiązania typu typu CSS in JS.

W: Muszę się z Tobą zgodzić odnośnie tego co powiedziałeś, w szczególności rzeczy związanych z architekturą. Zgadzam się z Tobą w stu procentach, że w momencie, kiedy mamy Styled Components i często zmienia nam się projekt i wizja naszego UX/UI designera, może to być bardzo problematyczne. Zgadzam się też z Tobą, że Styled Components sprowadza się do tworzenia dużej ilości kodu, dużej ilości komponentów i rzeczywiście staje się to nagle problem też architekturalny aplikacji. Wcześniej, kiedy mieliśmy oddzielnie style i mogliśmy tak naprawdę być bardzo elastyczni w kontekście tego, jak ja tworzymy, bo nie miało to takiego dużego wpływu na ten kod, gdzie mamy logikę, gdzie znajdują się wszystkie najważniejsze elementy naszej aplikacji. Mieliśmy CSSa, który czy SCSSa, który jest gdzieś tam z boku i mogliśmy go w miarę dynamicznie modyfikować, nie aż tak się przejmować co się dzieje w projekcie. To w momencie, gdy dodajemy do projektu Styled Components - nagle te style tyczą się też architektury i są bardzo mocno związane z tym jak wygląda nasz kod. Właśnie jaki jest ten developer experience na samym końcu? Co w połączeniu z tym dynamicznym projektem, z tymi dynamicznymi zmianami w samym template projektu może powodować naprawdę duże i wkurzające po prostu zmiany w naszym kodzie.

M: Dokładnie tak myślę i zgadzam się w stu procentach. Jeśli spojrzymy w ogóle na ewolucję tego CSSa, to zwróć uwagę, że mieliśmy na początku pisanie w czystym CSS, potem poszliśmy w Bootstrapa. Gdzieś ten Bootstrap trochę rozwiązał problemów związanych z CSSem. Miał swoje wady, dawał też duży narzut i powodował, że wielu rzeczy nie mogliśmy zrobić. W pewnym momencie gdzieś tam się pojawiły, podsumowując to w zasadzie - a nie wspominaliśmy też o tym, w pewnym momencie pojawiła się koncepcja Material Design, która została zaimplementowana później w kolejnych frameworkach. Między innymi polski produkt Material Design for Bootstrap, zresztą firma z Warszawy, która wprowadzała do koncepcji Bootstrapowych Material Design i wprowadzała te założenia designerskie, User Experience do framework'ów CSSowych. Następnie poszliśmy w zasadzie technologie sprzed lat. To, co Netscape wymyślił, czyli CSS in JS przywróciliśmy do życia w postaci Styled Components czy Emotion, ale też Chakra UI. O czym też warto wspomnieć. Właśnie tu chciałem Cię zapytać czy miałeś przyjemność pracować właśnie z jakimiś frameworkami, które typowo wykorzystywały właśnie Styled Components, czy też to podejście CSS in JS, typu Chakra?

W: Miałem okazję pracować z Chakrą. Też chętnie poznam Twoje zdanie na ten temat. Myślę, że wkładanie w ogóle Chakry z Bootstrapem i Material UI czy też z MUI jest troszkę błędem i myślę, że to są trochę frameworki na innym poziomie. Rzeczywiście mają dużo podobieństw, ale myślę, że też są pewne różnice pomiędzy nimi. Moje zdanie ogólnie na temat tego typu frameworków jak Chakra, MUI czy Bootstrap jest takie, że oddajemy czym powinniśmy się zajmować, i dla mnie jako developera, w szczególności frontend developera jest to dziwne, że instalujemy style, za które powinniśmy byćodpowiedzialni. Moim zdaniem nasza rola jako frontend deweloperów powinna być taka, że to my zapewniamy bibliotekę komponentów i chcemy, żeby ona działała jak najlepiej. A zainstalowanie jej z jakiegoś innego miejsca czy ściągnięcie z jakiegoś innego miejsca od razu zamyka drzwi do bardzo wielu rzeczy. I tak jak już mieliśmy okazję rozmawiać jest super fajne na początku, bo mega szybko możemy coś zrobić. Dla mnie ten moment, o którym też rozmawialiśmy, który przychodzi, czyli próba modyfikacji i próba nadpisywania takich rzeczy przychodzi zdecydowanie za szybko i jestem tego tak świadom od samego początku, że dla mnie zaczynanie już nawet na tym mija się z celem, więc tak naprawdę od zawsze unikałem właśnie tych frameworków, mimo że miałem jakieś tam doświadczenia z nimi i jestem ciekawy Twojego zdania. Mateuszu, jak Ty się zapatrujesz na tego typu frameworki?

M: Więc mówiąc, jednym tchem, o Bootstrapie, Material Design czy właśnie Styled Components i Chakra UI w zasadzie chodziło mi o to, żeby pokazać przekrój jak to się mniej więcej rozwijało. Natomiast też warto podkreślić, że Material Design i Material UI jako takie to nie jest dokładnie to samo, bo Material Design to będzie podejście architektoniczne, które mówi nam o tym, jak projektować interfejsy użytkownika, a Material UI będzie frameworkiem, który to podejście wdraża. I tutaj mam podobne zdanie co Ty, czyli zgadzam się, że takie rozwiązania częściej przyśpieszają pracę, jeśli chodzi o dostarczenie jakiegoś widoku i bardzo często zdejmują bardzo dużo pracy i odpowiedzialności z frontend developera na temat tego jak to powinno wyglądać, działać i w takiej sytuacji bardzo często developer musi iść na mnóstwo kompromisów. Musi zdecydować o tym, które rzeczy zrobi sam, a które będzie wykorzystywał z tego danego frameworka. Z prostej przyczyny: w takiej sytuacji najczęściej nadpisanie czegoś będzie po prostu kłopotliwe i trudne. Mam dużo doświadczenia z Material UI. Wydaje mi się, że ostatnimi czasy jest to chyba jeden z najczęściej wybieranych frameworków CSSowych czy to pod React czy pod Angulara. I bardzo często jest tak, że wszystko jest ok dopóki nie musisz zrobić jakiegoś custom'a. Jak musisz coś nadpisać to się będziesz w tym dłubał, bo tam są jakieś dodatkowe wewnętrzne klasy tworzone w tych komponentach, które to mocno nam utrudniają, które powodują, że specyficzność selektorów staje się dość złożona. I pomimo tej enkapsulacji, która tam gdzieś jest w tych komponentach, to nadpisanie takiego komponentu jest dość trudne. Wydaje mi się, że jesteśmy na tym samym stanowisku. Są to rozwiązania ok, ale zawsze trzeba mieć świadomość tego, z czego rezygnujemy i w którą stronę pójdziemy. Pojawiła się jeszcze jedna technologia. Chyba już ostatnia taka, o której chcieliśmy chcielibyśmy powiedzieć na pewno, która powróciła nam troszeczkę do jednej z metodyk metodyk, o których wspominaliśmy. Wspominałem o czymś takim jak Atomic Design. Atomic Design został ostatnio jakby przywrócony troszeczkę do biblioteki, która nazywa się Tailwind CSS. Tailwind teżtrochę z nami jest, ale różni się w zasadzie dość mocno od tych podejść typu Chakra. W zasadzie Charka czy Styled Components zakładają nam tworzenie komponentów ze stylami, z tym że w Chakra i MUI będą raczej frameworkami, a Styled Components biblioteką, która dostarcza możliwość tworzenia tych komponentów. Natomiast przy Tailwind mamy troszeczkę inną sytuację. Sytuacja wygląda w ten sposób, że tworzymy sobie komponenty w oparciu o klasy atomowe, gdzie w zasadzie pełnymi garściami czerpiemy z tej metodyki CSSowej, właśnie Atomic Design. Nie miałem przyjemności pracować z Tailwind'em, widziałem troszeczkę jak ten kod wygląda. Mi osobiście się nie podoba. Bardzo nie lubię w ogóle Atomic Design. Wydaje mi się, że masz inne zdanie na ten temat i chciałbym, żebyś troszeczkę powiedział. Dlaczego uważasz, że to jest spoko?

W: Bardzo chętnie Cię przekonam: dlaczego ze swojej strony myślę, że Tailwind CSS jest rozwiązaniem dużej ilości problemów, o których dziś wspominaliśmy i myślę, że jest to jedna z takich technologii, co też dość śmieszne, i może któryś z naszych słuchaczy ma podobnie, które na początku wyglądają trochę strasznie. A jeśli zacznie się z nimi pracować, naprawdę zmienia się totalnie podejście do tego, jak się na to patrzy. Dla mnie Tailwind CSS rozwiązuje pierwszy problem, o którym wspominaliśmy i o którym wspomniałeś Mateuszu, czyli nazewnictwo. Nazywanie rzeczy jak wiemy jako programiści jest naprawdę ciężkie, w szczególności kiedy mamy do czynienia z jakimiś abstrakcyjnymi tworami, musimy opisywać jakieś abstrakcyjne fragmenty kodu czy też abstrakcyjne zadania, za które ten kod jest odpowiedzialny. Tailwind ten problem rozwiązuje, ponieważ nie tworzymy żadnych klas, tylko właśnie nasz atomowy CSS wklejamy od razu do komponentu. Tworzymy go razem z komponentem. Kolejną rzeczą, którą myślę, że Tailwind świetnie rozwiązuje i jeszcze może troszkę wracając do poprzedniego punktu, że takie nazywanie tych rzeczy nie dość jest trudne, to w momencie kiedy uda nam się je dobrze nazwać może się okazać, że za tydzień, dwa tygodnie czy za miesiąc już nie będzie to taka świetna nazwa, bo często mówimy w przypadku programowania i programowania aplikacji internetowych o rzeczach abstrakcyjnych. Dodatkowo mamy też problem komunikacji między różnymi osobami i dla mnie Box mimo tego, że jest to rzecz niby prosta, może oznaczać zupełnie co innego niż oznacza dla Ciebie. Drugim punktem, o którym chciałem wspomnieć jest enkapsulacja i to też o tym rozmawialiśmy przy okazji metodologii, BEMa, SMACSa i OOCSSa. Pozbywamy się tego, czego nie lubimy w CSS, czyli właśnie tej specyficzności selektorów i tak naprawdę pozbywamy się jej zupełnie. Bo teraz mamy bardzo atomowe klasy, które piszemy dla konkretnego komponentu i zmiany w tym komponencie będą dotyczyły tylko tego jednego komponentu. Nie musimy się martwić, że zmiany, które wprowadziliśmy do tego jednego komponentu będą miały jakieś reperkusje w innych miejscach naszej aplikacji. Też myślę, że dużym plusem Tailwinda w porównaniu do tych frameworków, o których przed chwilą rozmawialiśmy, czyli Chakry, Bootstrapa i MUI powiedzmy jest to, że on nie ma ograniczeń w związku z tym, że to jest tak naprawdę rozszerzenie CSS czy też inny sposób na pisanie CSS, a więc ogranicza nas tylko nasza własna wyobraźnia i nasz projekt. Dodatkowo myślę, że też wsparcie wielu narzędzi już teraz jest naprawdę świetne. Więc jakby pisanie tego jest mega szybkie i myślę, że to jest takie całkiem niezłe podsumowanie dlaczego uważam, że Tailwind jest taki super.

M: Mnie tylko w tym wszystkim martwi ilość klas, która występuje w tych komponentach. I w zasadzie ten problem z nazewnictwem dotyczy nie tylko klas CSSowych, ale ogólnie wszystkich rzeczy, również komponentów, ponieważ jakikolwiek komponent byśmy nie tworzyli, zawsze musimy stworzyć dla niego nazwę i często ta nazwa jest nieadekwatna do tego, co my chcemy stworzyć. Widziałem takie wariacje na temat nazw komponentów, które miały coś robić i z nazwy w zasadzie wynikało, że coś robią, a okazywało się, że ten komponent w zasadzie robi coś zupełnie innego, że się nie dziwie, że jest to duży problem. Śmiem nawet twierdzić, że jest jakaś cząstka prawdy w tym, że najtrudniejszą rzeczą w programowaniu jest nazywanie rzeczy, nadawanie im nazw: klasom, funkcjom czy czemukolwiek innemu, obiektom, zmiennym. I tutaj w zasadzie może rzeczywiście jest to wartość dodana w tych klasach atomowych, że nie musimy się martwić o nazewnictwo konkretnych klas CSSowych, ale z drugiej strony nadal ten problem nie zostanie rozwiązany w stu procentach, bo te nazwy zawsze gdzieś tam się pojawią. Problem przy Styled Components, który byłzwiązany z nazewnictwem był taki: jak rozróżnić co jest komponentem typu Styled Component, a co jest komponentem czysto Reactowym? Spotykałem się z bardzo różnymi podejściami, gdzie dodawało się na końcu nazwy "styled" albo na początku jako prefiks lub sufiks do nazwy, gdzieś tam dodawało się jakąś pojedynczą literę, albo np. się nazywało odpowiednio, używając nazwy typu komponent, typu UI. To też nie było najlepsze rozwiązanie. Z jednej strony bardzo ładnie pokazywało co jest czym. Ale z drugiej strony też wprowadzało dosyć duży chaos i te nazwy były coraz dłuższe. Jak coś się nazywało Container of Something to jeszcze do tego musiałeś dać 5 razy Styled, żeby jeszcze się w razie czego jeszcze nie powaliło z innymi komponentami. To rzeczywiście było problematyczne. Zgodzę się z tym, że częściowo ten problem jest rozwiązany, ale z drugiej strony wydaje mi się, że zataczamy koło, czyli wracamy do początków, bo CSS się dość mocno rozwinął, patrząc z perspektywy tych już ponad 20 lat istnienia CSSa. Jeżeli sobie przeanalizujemy jak ten CSS wyglądał na początku, jak wygląda w tym momencie, jaka czeka go przyszłość, to można powiedzieć, że jest to rozwiązanie też już dość dojrzałe, dynamicznie rozwijające się nadal, ale dość dojrzałe i to co my mogliśmy robić kiedyś było obarczone jakimś sporym ryzykiem, bo musieliśmy dodawać dużo różnych narzędzi, żeby utrzymać utrzymać jakiś poziom tego CSSa. Natomiast dzisiaj sam język już nam dostarcza wiele możliwości, a przez to, że przeglądarki w zasadzie są spójne, jeśli chodzi o standard w dużej mierze już, to tak naprawdę nie martwimy się już o to, jak bardzo ten CSS jest wspierany, czy też nie, na różnych poziomach kodu. Tailwindoże może być fajnym narzędziem. Nadal nie jestem do niego przekonany. Twoje argumenty do mnie trafiają, aczkolwiek wydaje mi się, że jest to nadal jakiś narzut dodatkowy, który jest troszeczkę zbędny, który można osiągnąć dużo łatwiejszym, niższym kosztem niż właśnie poprzez dodawanie kolejnego narzędzia, tak naprawdę kolejnej biblioteki do naszego kodu, naszego projektu.

W: Rozumiem. Myślę, że to jest właśnie ta kwestia, że jeszcze nie miałeś okazji pracować z Tailwind'em, więc pozwolę Ci się mylić w tej kwestii. Oczywiście żartuję, ale naprawdę polecam. Jeśli nie miałeś okazji, spróbuj. Myślę, że nie będziesz żałować.

M: Próbowałem z nim pracować nawet jeden projekt z nim zrobiłem.

W: To za mało.

M: Proof of concept nie wyszedł. W każdym razie uważam, że to samo co napisałem wykorzystując Tailwinda mogłem napisać niższym kosztem, wykorzystując np. CSS Modules i Sass'a.

W: Myślę, że podejście o którym mówisz, bo właśnie chciałem zapytać Cię jakie widzisz alternatywy do mojego teoretycznie rozwiązania na wszystko, jeśli chodzi o stylowanie, czyli Tailwind'a. I rozumiem, że w Twoim wypadku to są CSS Modules?

M: CSS Modules z Sass'em czy też w wersji SCSS dla mnie spisują się bardzo dobrze już od kilku projektów. Przez to, że mi się w tym wygodnie pisze, to może się trochę zamknąłem w tym i to jest trochę błędne i nie powinienem tego robić, bo chciałem się też rozwijać, otwierać się na inne rozwiązania, ale wydaje mi się, że największą wydajność i optymalność jestem w stanie sobie zapewnić, wykorzystując właśnie ten stack. Bo jeśli byśmy spojrzeli chociażby na samego SCSSa, SCSS daje nam sporo różnych możliwości, chociażby placeholder classes, traktowanie styli jako modułów, wprowadzanie różnego rodzaju zmiennych, funkcji do CSSa - co nam bardzo mocno rozszerza możliwości samego CSSa, ale nadal jest to kompilowane do zwykłego CSSa, więc to co mamy w procesie developerskim zostaje w procesie developerskim. A wynikowo jeżeli dobrze napiszemy tego Sasa powstanie nam całkiem fajny, wydajny kawałek kodu CSSowego, który jest w zasadzie najprostszym językiem rozumianym przez przeglądarkę bez żadnych dodatkowych narzutów. Nie wprowadzając dodatkowych frameworków typu Tailwind nie musimy się martwić o zwiększanie jakiejś wagi naszego bundle'a poprzez dodawanie kolejnych paczek. Tak naprawdę mamy mniejszą po prostu aplikację, co ostatecznie przełoży się w zasadzie na plus naszej aplikacji.

W: Ale myślę, że jeśli chodzi o Tailwind to ten argument odnośnie wielkości paczki jest trochę nieadekwatny, ponieważ Tailwind nie waży nic na dobrą sprawę, bo przy kompilacji czy też przy transpilacji dokonuje czegoś takiego co się nazywa po angielsku "purge" i czyści CSS z wszystkich nieużytych klas i koniec końców tworzy taką paczkę, która zawiera tylko te style czy też te klasy, które rzeczywiście wykorzystujesz.

M: To jest wartościowe. O tym nie wiedziałem.

W: Dodatkowo, jeszcze a propo CSS Modules, myślę, że jestem ciekawy jak rozwiązujesz problem, o którym trochę rozmawialiśmy przy okazji Styled Components i który właśnie myślę, że też jest całkiem dobrze rozwiązany przez Tailwinda, chociaż może aż tak idealnie jak w Styled Components, ale myślę, że jest jeszcze bardziej adekwatny i widzialny w momencie kiedy wykorzystuje się CSS Modules, czyli właśnie różnice w CSS, czy też modyfikowanie tego jak wygląda nasz komponent w zależności od tego co się dzieje przez całe życie w interakcji z użytkownikiem czy też z innymi częściami naszego systemu.

M: To jest rzeczywiście problematyczne, ponieważ rzeczywiście w Styled Components mieliśmy możliwość dodawania propsów do komponentów i na tej podstawie wprowadzania odpowiednich zmian w stylach z racji tego, że style były traktowane de facto jako komponent aplikacji. W CSS Modules rozwiązuję to na takiej zasadzie, klasycznie w zasadzie, czyli można powiedzieć, że troszeczkę czerpiąc z Object Oriented CSS czy też z Modyfikatorów z BEMa, dodając klasę, która będzie klasą stanu wprowadzaną do kodu, wtedy, kiedy się coś zmieni. Czyli tak naprawdę mamy jakiś warunek na widoku, który odpowiednio będzie tę klasę przełączał w zależności od stanu, w którym jesteśmy. A Tailwind jak to rozwiązuje?

W: Tailwind sam w sobie nie rozwiązuje tego problemu. Ale są takie frameworki, które bardzo dobrze z nim współgrają, żeby rozwiązać niejako ten problem. M.in. biblioteka, która nazywa się Class Variance Authority, która pozwala definiować klasy dla różnych wariantów naszego CSSa i wynikowo możemy za pomocą jakiegoś tam property dostać listę klas, które potrzebujemy.

M: Muszę się przekonać. Okazuje się, że mamy trzeci odcinek, trzeci epizod naszego podcastu, a Ty wprowadzasz mi trzecią zajawkę. Próbujesz mnie przekonać do trzeciej rzeczy, zaraz stanie się to dla nas jakąś tradycją. OK, Wojtek, więc jak już sobie przegadaliśmy całego CSSa, spojrzeliśmy na niego od samego początku, to chyba zostaje nam jeszcze kwestia tego, co nas czeka w przyszłości. Wiele się mówi o tym, że CSS3 tak naprawdę to już jest koniec, że nie powstanie nigdy CSS4 i że CSS4, tak naprawdę, to jest można powiedzieć przyszłość naszego CSSa, która wprowadzi nam tak naprawdę dużo, dużo zmian. Tylko co to miałyby być za zmiany? Bo tak naprawdę wiele z tych rzeczy, o których się mówi, czyli CSS4 traktowane jako język programowania już w CSS są, bo możemy w CSS się wprowadzać zmienne, mamy dużo różnych funkcji, które wprowadzają obliczenia, mamy też dużo tak naprawdę różnych funkcjonalności, które nam rozszerzają tego CSSa i cały czas coś się rozwija. Wprowadzane są funkcje, wprowadzane są różnego rodzaju możliwości obliczeń, wprowadzane są zmienne. Co innego może się wydarzyć według Ciebie w CSS w następnych latach, które może wprowadzić ten CSS na wyższy poziom? Może jakiś pomysł? Czym myślisz może, że to co mamy to tak naprawdę to już to już jest ten maks, który możemy z tego CSS wyciągnąć i raczej dalej w tym nie pójdziemy.

W: Jest to ciekawe pytanie Mateuszu. Myślę, że rzeczywiście powoli zbliżamy się niejako do max'a. Jeśli miałbym strzelać i próbować wróżyć z fusów jak będzie wyglądać przyszłość, może bym próbował z czymś takim jak powiedzmy 3D i jakaś większa integracja CSSa, rzeczy związanych z augmented reality, VRem, ale tak poza tym nie przychodzi mi nic do głowy, bo mam wrażenie, że aktualny stan CSSa to jest właśnie tylko rozszerzanie tego, co już tam aktualnie istnieje i dodawanie rzeczy, które w jakiś tam drobnych przypadkach pomagają i ułatwiają nam pracę. Tak jak powiedziałeś funkcji dodatkowych, które ułatwią nam rzeczy, które musieliśmy wcześniej robić, czy też nawet samych properties, które możemy ustawiać na obiektach tak, żeby je zmienić. Chociaż zdecydowanie może będę zaskoczony. Czy Ty masz jakieś pomysły, Mateuszu? Co może być takim następnym krokiem właśnie takim CSS 4?

M: W zasadzie wydaje mi się, że dobrym pomysłem dla CSS w takiej wersji czwartej byłaby możliwość wykonywania tego CSS w locie, czyli w zasadzie na produkcji. Czyli przeglądarka dałaby możliwość interpretowania kodu CSS w zależności od stanu aplikacji, bo w tym momencie jest to dość statyczne. CSS musimy przygotować, CSS ląduje do przeglądarki, przeglądarka go czyta i czasami są funkcje typu calc, które pozwalają nam odnieść się do stanu naszej aplikacji, naszej strony internetowej i odpowiednio wykonać obliczenia. W większości przypadków jest to dość statyczne i wydaje mi się, że taki CSS w wersji czwartej mógłby właśnie trochę odejść od tej statycznej strony CSS i pójść w stronę taką bardziej właśnie dynamiczną, właśnie taką opartą o obliczenia w locie, w momencie wtedy, kiedy ta strona jest, kiedy strona jest wyświetlana, kiedy jest renderowana. Myślę, że to byłby fajny pomysł na CSS w wersji czwartej. Spodziewałbym się, że raczej ten CSS w wersji czwartej nie powstanie. Na pewno nie w najbliższych latach. Wprowadzane technologie, które pojawiają się cały czas, czyli wspomniane calc, zmienne i tak dalej. One z nami są już od dłuższego czasu, nikt tego nie wydziela jako oddzielny standard CSS. Nigdzie też nie słychać o tym, żeby CSS4 miał powstać. Wydaje mi się, że CSS jest na tyle dojrzały, że tak naprawdę rozwija się tak dynamicznie, jak rozwijają się pozostałe technologie, czyli JavaScript i HTML. I te zmiany nas czekają. Ale w którą to stronę pójdzie? Tego nie umiem określić jeszcze i obserwuję z dużym zaciekawieniem. Nie mam awersji do CSSa w przeciwieństwie do wielu frontendowców na rynku i wydaje mi się, że on jest dosyć ciekawym językiem do zabawy i do tworzenia fajnych rzeczy. Tak to widzę.

W: Myślę, że zgadzam się z Tobą Mateusz. Naprawdę będzie ciekawie zobaczyć jak to rozwinie się w kolejnych latach, gdzie technologia ewoluuje i czy zobaczymy jeszcze tak duży skok jaki jeszcze widzieliśmy niedawno z CSS3, HTML5, a w szczególności JavaScripcie. Czy będziemy jeszcze żyć w takich czasach, że te technologie ewoluują tak szybko i w taki fajny sposób moim zdaniem.

M: W takim razie podsumowując Wojtku, przeszliśmy praktycznie przez całą historię CSSa od jego powstania aż do dnia dzisiejszego i tego co może nas czeka w przyszłości. Jak ta podróż Ci się podobała?

W: Bardzo mi się podobała.

M: Mnie też bardzo się to podobało i myślę, że czeka nas dosyć dużo ciekawych rzeczy jeszcze w projektach, bo myślę, że podejścia, które mamy to nie są jeszcze ostateczne podejścia, które wprowadzają nam już jakąś finalną wersję tego, jak my będziemy to tworzyć. Tak naprawdę można powiedzieć, że ze zniecierpliwieniem czekam na to, co przyniosą nam kolejne lata w tej technologii CSSowej. Czy chciałbyś coś jeszcze od siebie dodać?

W: Nie, myślę Mateuszu, że to było świetne podsumowanie. Myślę, że mogę Ci tylko podziękować za świetną rozmowę i powiedzieć do usłyszenia.

M: Do usłyszenia. A tymczasem chcielibyśmy też bardzo zachęcić Was do subskrybowania naszego kanału, do dzielenia się opiniami, swoim zdaniem na temat tego, czym jest CSS dla Was? Jakie Wy macie doświadczenia z CSSem? Chętnie posłuchamy, poczytamy i nawiążemy może do tego w którymś z naszych kolejnych odcinków. Tymczasem ślicznie dziękujemy, życzymy miłego dnia, wieczoru czy odpowiedniej pory, w której aktualnie jesteście. I do usłyszenia!