Frontend z Tailwind & Tailwind UI

Cześć !
witam Cię w kolejnym newsletterze Ahoy Dev! Dzisiaj mam dla Ciebie artykuł o podejściu Adama Gospodarczyka do tworzenia Frontu z Tailwind & Tailwind UI, serię ultra ciekawych linków do sprawdzenia - od artykułu wyjaśniającego, dlaczego powinieneś blogować (albo udzielać się na społecznościach eksperckich), przez cheatsheet odnośnie architektury, aż po informację o Bun i wiele więcej.
Jeżeli jest coś, co powinniśmy poruszyć w Newsletterze, to daj nam znać w ankiecie oceniającej to wydanie.
Pozdrawiam,
Jarek

Dlaczego już nie tworzę Frontu bez Tailwind & Tailwind UI?
Autorem dzisiejszego artykułu jest Adam Gospodarczyk (overment)
Już praktycznie każda rozwijana przeze mnie aplikacja wykorzystuje połączenie Tailwind oraz Tailwind UI i postaram się wyjaśnić dlaczego tak jest.
To ze sam Tailwind zyskał popularność jest oczywiste. Pomimo wielu negatywnych opinii z którymi spotykałem się gdy pierwszy raz publikowałem wpisy i filmy na jego temat, dość szybko zaadresował swoje główne problemy oraz wprowadził znaczące usprawnienia (m.in. JIT Mode czy w ogóle całą bibliotekę Tailwind UI).

Buduj od podstaw

Pisanie CSS teoretycznie daje nam absolutnie pełną kontrolę nad UI ale jednocześnie dodaje też mnóstwo pracy. Najważniejsze jednak jest to, że wraz z rozwojem aplikacji coraz trudniej było utrzymać spójność interfejsu i nazewnictwa klas (podczas gdy BEM mi osobiście dał sporo to i tak w porównaniu do Tailwind praca z nim była bardzo mało efektywna).
Z drugiej strony do dyspozycji zawsze mieliśmy gotowe komponenty, których założenie było świetne ale w praktyce wypadały średnio ze względu na fakt, że próba nadpisania większości stylów kończyła się w najlepszym przypadku koniecznością napisania złożonych selektorów a w najgorszym sięgania po !important.
Trzeba jednak przyznać, że wówczas nie było za bardzo alternatyw i jedyne co można było zrobić to rozwijać swoje umiejętności zarządzania kodem CSS lub ewentualnie iść na znaczny kompromis pomiędzy szybkością i niską elastycznością a własnoręcznym tworzeniem wszystkich komponentów.

Tailwind

Koncepcja wykorzystania klas w Tailwind początkowo wśród wielu osób budziła jednoznaczne skojarzenia z pisaniem stylów "inline". Jednocześnie konieczność dodawania wielu klas i tym samym zwiększanie objętości kodu HTML raczej nie była pozytywnie przyjmowana.
Rzecz w tym że ani jeden ani drugi argument nie są trafne. Po pierwsze jest różnica pomiędzy przypisaniem klasy do elementu, którą można globalnie kontrolować a przypisaniem na sztywno stylu z konkretną wartością. Po drugie dalej mamy możliwość tworzenia własnych klas z pomocą chociażby dyrektywy @apply łączącej klasy tailwind.
Jeżeli miałbym wskazać dwie rzeczy, które w Tailwind najbardziej doceniam to:
praktycznie brak konieczności wymyślania nazw dla klas
ogromne wsparcie w zachowaniu spójności, która odgrywa fundamentalną rolę budowania przejrzystych interfejsów
dzięki organizacji klas istnieje możliwość prostego nadpisywania naszego motywu i tym samym globalnego wprowadzania zmian w projekcie, co zawsze jest dla mnie 🤯

Tailwind UI

To już moja osobista preferencja i z pewnością nie sprawdzi się w każdym projekcie. Jednak w sytuacji gdy tworzycie projekt w przypadku którego interfejs musi powstać bardzo szybko, wykorzystanie Tailwind UI jest w zasadzie oczywiste. W pozostałych sytuacjach warto się nad tym chwilę zastanowić.
Tutaj muszę przyznać że im więcej korzystamy z tych komponentów tym łatwiej możemy je ze sobą łączyć i modyfikować. Początkowe zderzenie z nimi, szczególnie jeszcze gdy sam Tailwind jest dla nas czymś nowym, może być zwyczajnie trudne. Z pewnością jednak warto dać mu szansę, ponieważ tak jak wyżej wspomniałem, często umiejętność pracy z komponentami może znacznie wpłynąć na naszą skuteczność.
Dlaczego już nie tworzę front-endu bez Tailwind?
Ponieważ hasło: Rapidly build modern websites without ever leaving your HTMLze strony głównej Tailwind jest w 100% zrealizowane i przekonałem się o tym już przynajmniej na kilkunastu projektach różnej skali. Jedyną sensowną alternatywą która sprawdza mi się przy tworzeniu front-endu są web buildery takie jak Webflow lub ostatnio Framer. Natomiast jest to zupełnie inna kategoria narzędzi, po którą sięgam głównie na potrzeby landing page'y oraz prostych paneli.
Podobnie też w sytuacji gdy wiem że będzie istniała potrzeba aby sam front-end był w jakiś sposób połączony z moją back-endową aplikacją, sięganie po web buildery raczej mija się z celem (poza drobnymi wyjątkami).

Jak zacząć pracę z Tailwind?

Od oficjalnych screencastów dostępnych na kanale Tailwind Labs. Nawet oglądanie ich "do kawy" robi robotę, tym bardziej że można spotkać wiele małych tricków, które znacząco ułatwiają pracę.
Poza tym wręcz konieczne jest zainstalowanie rozszerzeń do IDE wspierających Tailwind i podpowiadanie klas, z uwzględnieniem zmian które wprowadziliśmy w motywie danego projektu (!).
I ostatnia rzecz to rozszerzenie dla Raycast, które również ułatwia pracę z dokumentacją oraz szybkim odnajdywaniem klas, które początkowo trzeba zapamiętać:
No i to wszystko ostatecznie trzeba połączyć z praktyką. Każdy kolejny projekt będzie prostszy i przyjemniejszy do realizacji.
Na sam koniec sugeruję jeszcze zaobserwowanie twórców oraz oficjalnego profilu na Twitterze aby pozostać na bieżąco ze zmianami a nawet móc sugerować i mieć wpływ na kolejne funkcje ponieważ często padają pytania oraz realizowane są ankiety w ich sprawie, właśnie na Twitterze.

Ciekawe linki

Jesteśmy przekonani, że warto budować swoją markę osobistą. Można to robić poprzez blogowanie, jak przekonuje autor w tym artykule, ale istnieje też sporo innych sposobów - udzielenie się na social mediach, czy w społecznościach eksperckich, takich jak Ahoy.
Architektura to nie jest bardzo prosty temat, ale warto próbować o nim mówić w możliwie prosto, W tym artykule znajdziecie 10 właściwości / nie funkcjonalnych wymagań, razem z przydatną ściągą.
4 nowe featury JS - w zeszłym miesiącu pojawiły się nowe featury JS - sprawdź 4 przykładowe, które FAM będzie wykorzystywać.
Koniec GitHuba? - o tym przynajmniej próbują nasz przekonać niektóre portale. Wszystko ze względu na udostępnienie płatnego Copilota (asystent AI), który korzysta z dostępnego za darmo kodu Open Source. Każdy może wyrobić sobie swoje zdanie na ten temat.
Bun, to świeży, szybki Runtime, zamiennik dla Node, czy Demo. Warto się zapoznać, o czym też rozmawialiśmy w jednym z wątków na Ahoy.

Na Społeczności

Jak czysty jest czysty kod? - taką dyskusję na Ahoy rozpoczął Czarek, pokazując, że mamy na pokładzie sporo pragmatyków, ale pewnie i puryści się znajdą. Co oznacza czysty kod, jak go zapewnić, jak o niego zadbać - o tym wszystkim dyskutowaliśmy - oszczędzając sobie na szczęście przekonywania o wyższości tabów nad spacjami. Jeśli nie czujecie tego ostatniego problemu, to chyba nie widzieliście tego wideo - koniecznie zajrzyjcie.
Czy dany projekt NFT to scam? - bardzo ciekawy wątek związany z Web3 poruszył na Społeczności Przemek. Kilka ciekawych pomysłów i narzędzi się pojawiło, ale jest to temat, który prawdopodobnie będzie się jeszcze bardziej rozwijał, bo niestety różne formy oszustw w świecie Web3/NFT funkcjonują.

Zapowiedzi i wydarzenia

Making your own Angular CDK (Component Development Kit) - live na ten temat poprowadził w zeszłym tygodniu Wojtek Parys Senior Frontend Developer z nexocode. Retransmisja jest oczywiście dostępna dla członków Ahoy.
Full Stacki Q&A z Wojtkiem Połowniakiem odbędzie się już 12.07- zadaj swoje pytanie już teraz przez Tally, żeby mieć pewność, że zostanie obsłużone w pierwszej kolejności.
Ahoy Book Club zbiera się ponownie pod koniec lipca, żeby podyskutować o atomowych nawykach Jamesa Cleara. To świetna lektura i sam jestem ciekaw, nad jakimi nawykami będą wszyscy pracowali.