Czym jest Tailwind? Rozmowa z Maćkiem Korsanem

[@GreenMerlin]

Jeśli jest jakaś dynamiczna klasa to można zawsze dodać ją w "safelist". Odnośnie design systemów to jest ich sporo bazujących na tailwindzie shadcn / nextUI / hyperUi / Sailboat UI co sprawi, że masz swoje MUI tylko łatwiej customizowalne no i dalej działasz na tailwindzie a nie mieszasz jakieś SXy z scss czy innym styledComponents. Tailwind sam w sobie świetnie minimalizuje czas stylowanie systemu.

[@bard_X]

dzieki, fajny material, jak zawsze ;)

[@gbkEmilgbk]

12:50 "Wymyślanie klas ... największa bolączka ... konwencje ..." [BEM etc] - śmiem zauważyć że w nowoczesnych frameworkach typu Angular mamy enkapsulacje komponentów która działa w ten sposób że nazwy klas CSS nie są widoczne poza obszarem komponentu - więc nie trzeba trzymać się żandych konwencji... (nawet jeśli komponent jest duży to... dąży się do rozbicia go na mniejsze...)

[@frontendarchitecture]

Tak, ale coś takiego wspiera jedynie Angular. A nie wszyscy go używają, wiec w innych frameworkach trzeba to implementować samemu (np poprzez użycie CSS modules). A jak Maciek słusznie zauważył, jeżeli łączysz technologie (np BE i FE) to nie użyjesz narzędzi frontendowych

[@gbkEmilgbk]

@@frontendarchitecture uuu Angular to wspiera chyba już od 8 lat - życie frontendowca bez enkapsulacj css w komponentach musi być bardzo smutne... - ale właściwie jest to słabe że inni tego nie podpatrzyli... (swoją drogą z angulara konkurencja masę rozwiązań skopiowała... oczywiście zwylke z wieloletnim opóźnieniem)

[@anothermail5117]

@@gbkEmilgbk Vue też tez to wspiera, na pewno od (już przestarzałej versji 2), czyli od bardzo dawna. Z popularnych technologii SPA nie ma tego jedynie w Reactcie, ale w nim najbliższym odpowiednikiem będą (s)css modules.

[@addn07]

Spoko, ale nie wydaje mi się to w ogóle argumentem przeciw Tailwindowi. Kiedyś, gdy nie było czegoś takiego jak komponenty w obecnym rozumieniu, to właśnie klasy CSS wyznaczały granice poszczególnych sekcji na stronie, więc pomocny był tutaj np. BEM - nazwy klas miały znaczenie. Teraz ta odpowiedzialność przeniosła się na komponenty, bo w trochę dojrzalszych projektach, by zbudować jeden duży komponent bierzesz kilka innych. Ale również wtedy dość często potrzebujesz to nadbudować jakimś divem (kontenerem). W projektach spotykam się wtedy z sytuacjami, gdzie ludzie wszystko nazywają container, wrapper itp. itd. Gorzej jak coś jest dosyć niestandardowego, bo jest to jakaś np. nietypowa komórka w tabelce. Zamiast wklepać tam z palca utility klasę Tailwindową to trzeba wymyślać jakąś ciulową nazwę, bezsensowna strata energii. Poza tym osoba przeglądająca kod musi potem jakoś podejrzeć czym ta klasa jest zamiast od razu widzieć co jest pięć. Wg mnie utility classes, niezależnie czy to Tailwind czy nie, to wygryw pod tym kątem. A jak jest to spięte z tokenami z design systemu to już totalnie cudo.

[@bard_X]

chyba da sie dokupic do figmy gotowy design z shadcn, gdzie sa gotowe te komponenty, tak mi sie kojarzy

[@frontendarchitecture]

O to tego nie wiedziałem, musiałbym sprawdzić. Ale tak czy siak w naszym wypadku niestety to nie zadziała, tj musielibyśmy już na etapie wyceny opierać o to designy czyli de facto zdecydować o technologii… Ale jak ktoś może sobie pozwolić na pracę z shadcn to myślę że bardzo fajna opcja :)

[@jacob5403]

Panowie, takie dyskusje to sie powinny odbywać z 8/10 lat temu : D

[@frontendarchitecture]

Hej, dzięki za komentarz. Mógłbyś rozwinąć myśl? Nie rozumiem co masz na myśli, a chciałbym w przyszłości tworzyć lepsze materiały :)

[@jacob5403]

@@frontendarchitecture no bo tailwind to nic nowego, mam mial sie nauczyc/polubić to juz pewnie zdażył. Z drugiej strony trzeba pamieć o nowych programistach którym taki materiał moze sie przydać ; D

[@frontendarchitecture]

@jacob5403 aa ok. Tak zgodzę się, ale też nie każdy się z nim zetknął. Mi też na początku wydał się fajny. miałem też nadzieję, że wiele jego wad uda się rozwiązać w inny sposób (np użyć MUI Base jako Design System). Ale koniec końców okazało się, że to dużo więcej pracy niż myślałem, że będzie potrzebna.

[@TheGilotyn]

Maćka Korsana fajnie zawsze posłuchać ale nastawienie prowadzącego, który raz użył tailwinda, w zasadzie nie wie jak go używać i w związku z tym mial problemy i nie jest w stanie swojego toku myślenia zmienić odejmuje całej rozmowie, że ciężko się to ogląda

[@frontendarchitecture]

Hej, dzięki za komentarz. Może to nie wybrzmiało, Tailwinda uzylem w dwóch projektach (a właściwie dalej używam), w sumie pracuje z nim jakiś rok. W nagraniu chciałem przedstawić inny punkt widzenia niż mega optymistyczny, poruszyć wady i uwypuklić te elementy gdzie Tailwind sobie nie radzi: - nie jest design systemem, nie ma dobrych darmowych design systemów opartych na Tailwind przez co nie jesteś w stanie postawić szybko projektu - trzeba nauczyć się nowego narzędzia. Nie tylko nazw tokenów ale także jak z tym pracować/konfigurowac. Dodaje to złożoność do projektu. W dodatku ktoś kto zna CSS zrobi w CSS rzeczy szybciej (to jest feedback od osoby z zespołu) - tailwind sprawia, że kod jest złożony, ciężko się go czyta. Twórcy nie dają na to rozwiązań, np dobrych praktyk - rozbicie na logikę i prezentację staje się trudniejsze, nawet jak rozbijesz komponent to ten z logiką mimo, że ma tylko kilka elementów to mogą one mieć bardzo dużo klas co będzie zaciemniało kod Nie znaczy to przy tym, że nie ma przypadków w których Tailwind się sprawdzi, tak jak Maciek zaznacza, jeżeli pracuje się z osobami z BE/fullstackami/roznymi technologiami to Tailwind może być bardzo dobrym wyborem. Niestety u nas (w software house gdzie bazujemy mocno na Material UI) nie widzę zastosowania. Klienci raczej nie będą chcieli ponosić dodatkowych kosztów licencyjnych, a użycie innych design systemów jest bardziej problematyczne