State of CSS 2022 is here! | Frontend Weekly vol. 106

1. State of CSS 2022

Mamy to! Wreszcie nastał ten czas w roku, kiedy nasze Vivedowe przeglądy zaleją statystyki i podsumowania. W tym roku gorący sezon otwiera State of CSS 2022!

Tak będą wyglądać nasze weekly, przez następne miesiące – przygotujcie się!

Jeśli szukacie w internecie podsumowania nowości z CSS z kilku ostatnich lat, to nie znajdziecie lepszego źródła niż State of CSS. Większości pytań towarzyszą linki do “Can I Use” i dokumentacji MDN. Na podstawie rozkładu odpowiedzi łatwo też wyczuć, którymi funkcjonalnościami należy już się zainteresować, żeby nie pozostać w tyle za rynkowymi standardami. Poniżej podzielę się z Wami kilkoma moimi spostrzeżeniami po przeczytaniu wyników ankiety, ale nie traktujcie tego jako dogłębnego podsumowania i odkryjcie ankietę na własną rękę.

Bootstrap to CSSowy jQuery

Bootstrap od samego początku ankiety State of CSS jest najczęściej używanym frameworkiem CSS. W tym roku przewaga nad drugim Tailwindem wyniosła ponad 30 punktów procentowych. Nigdy nie był to natomiast najbardziej lubiany framework wśród deweloperów, a z roku na rok jego liczby lecą na łeb na szyję. Czy tylko ja dostrzegam tutaj mocną analogię do sytuacji jQuery w środowisku JS?

Kiedy dołączas do projektu i widzisz zależność na Bootstrapa

Utility-first first for the win

W kategorii satysfakcji z frameworków CSS dwa pierwsze miejsca zajęły Tailwind i PureCSS. Oba te rozwiązania to biblioteki utility-first, a przewaga nad trzecim Ant Design była spora i wyniosła ponad 20 punktów procentowych. Wszystkie znaki na niebie wskazują, że deweloperzy pokochali inline styles na sterydach (bo tak pieszczotliwie niektórzy nazywają podejście utility-first), a stylowanie komponentów przekazali w ręce bibliotek (takich jak Material UI czy Chakra) zamiast frameworków CSS (takich jak Bootstrap czy Ant Design).

To jest coraz mniej popularna opinia, ale od czasu do czasu temat wraca jak bumerang

CSS staje się nudny?

Jeśli spojrzycie na kategorię CSS Frameworks i CSS-in-JS, to na pewno od razu rzuci się Wam w oczy brak nowych “błyszczących” rozwiązań. Wygląda na to, że jako społeczność bardzo dojrzeliśmy, wreszcie dopracowaliśmy nasze narzędzia i wydajemy się zadowoleni z obecnego stanu rzeczy.

W CSS wreszcie zaczyna się dziać!

Interop, to inicjatywa w której udział bierze Chrome, Firefox i Safari, która na celu ma usprawnić Developer Experience Web Developerów. W dużej mierze dzięki jej działalności w tym roku do wszystkich trzech przeglądarek trafiły Container Queries (tl;dr; Media Queries zrobione jak należy) i selektor `:has()`. Są to dwie od dawna wyczekiwane funkcjonalności, które naprawdę rewolucjonizują CSSy. O ile o tej pierwszej słyszało prawie 90% deweloperów, to o tej drugiej nie słyszał tylko co trzeci respondent. Jeśli i dla Was jest to pierwsza styczność z tymi funkcjonalnościami, to najwyższy czas nadrobić zaległości.

Tak zareagowałem, kiedy dowiedziałem się, że Container Queries działają w Chrome, Safari i Firefox

Deweloperzy testują aplikacje na tabletach i czytnikach ekranu

No dobra, trochę przekoloryzowałem… 30% deweloperów testuje swoje aplikacje na tabletach i 10% na czytnikach ekranów. Na swoją obronę powiem jednak, że jestem urodzonym pesymistą i spodziewałem się, że liczby te będą co najmniej dwukrotnie mniejsze. Zwłaszcza biorąc pod uwagę jaki procent ruchu w internecie stanowią tego typu urządzenia.

Jeśli nie wierzycie w mój pesymizm to zapytajcie moich współpracowników 😉

Istnieją deweloperzy, którzy do budują aplikacje w Brave i Safari

Przez długi czas myślałem, że budowanie webowych aplikacji na Safari jest swego rodzaju memem. W końcu narzędzia deweloperskie w Chrome są obecnie nie do pobicia. Jak się okazuje żyłem w bańce. Co trzeci respondent ankiety deklaruje, że jako podstawowej przeglądarki do developmentu aplikacji używa Safari, co 5 deklaruje w ten sposób Edge, a co 10 Brave. W pytaniu tym można było jednak zaznaczyć więcej niż jedną odpowiedź i coś czuję w kościach, że niektórzy mocno tutaj przy kolorowali.

Tak reaguje, kiedy widzę ludzi, którzy używają Safari zamiast Chrome do dewelopmentu aplikacji

Źródła:

https://2022.stateofcss.com/en-US/

2. Codux – pierwsze dedykowane IDE dla Reacta

W zeszłym tygodniu jeden z współzałożycieli Wix zaprezentował światu nowy produkt w portfolio firmy – Codux. Reklamuje się on jako pierwsze IDE dedykowane dla Reacta, ale w rzeczywistości jest to kolejne narzędzie low-code. Jest ono o tyle ciekawe, że jako źródło prawdy wykorzystuje Reactowy kod. Co jeszcze ciekawsze, Codux umożliwia modyfikowanie komponentów zarówno przez kod jak i interfejs użytkownika.

Na ten moment Codux jest w otwartej becia i nie wiadomo kiedy wydana zostanie jego finalna wersja. Spróbowałem pobrać aplikację i przetestować ją na własnej skórze. Wydaje się odrobinę ociężała i toporna (to akurat można zrzucić na barki wersji beta), a odnalezienie się w interfejsie użytkownika zajęło mi chwilę. Na pochwałę zasługuje natomiast wybór edytora kodu – jeśli oczy i palce mnie nie mylą, to twórcy IDE zdecydowali się skorzystać z odpowiednio ostylowanego VSCode.

Pod skórą przeczuwam, że w rozwiązaniu jest spora dawka potencjału. Wyobraźcie sobie sytuację, kiedy Designer lub Product Owner może samodzielnie przygotować pierwszą wersję komponentu. Potem programista przeprowadza drobny refactoring i wrzuca aplikację na produkcję. Kiedy designer chce wprowadzić poprawki, to po prostu wyklikuje je na interfejsie użytkownika. Jako że to kod jest źródłem prawdy, to programiście zostaje tylko ocenić, czy Codux zbytnio nie namieszał i czy uwzględnił wszystkie przypadki brzegowe. W mojej głowie jest to taka Figma, ale źródłem prawdy nie jest tajemniczy format danych, a Reactowy kod. Dzięki takiemu podejściu zarówno programiści jak i designerzy pracują na wspólnym materiale źródłowym.

Jak to zwykle bywa, w całej tej beczce miodu jest też łyżka dziegciu. Po pierwsze, wykorzystanie jako źródła prawdy Reactowego kodu sprawa, że designerzy w dłuższej perspektywie zmuszeni będą zrozumieć podstawy HTML’a, CSS’a i samego Reacta. Po drugie Codux generuje kod w bardzo konkretny i mocno zopiniowany sposób. Jeśli nie przypadnie on Wam do gustu, albo będziecie chcieli skorzystać z innego zestawu bibliotek, to utonięcie w morzu refactoringu. W takiej sytuacji wszystkim na zdrowie wyjdzie designowanie w jednym narzędziu i programowanie w drugim (np. Figma + Storybook).

Podsumowując, w Codux drzemie całkiem spory potencjał, ale przed twórcami jeszcze bardzo dużo pracy. Wydaje mi się też, że głównym beneficjentem IDE nie będą programiści, a właśnie osoby nie techniczne jak Designerzy czy Product Ownerzy.

Źródła:

https://dev.to/codux/introducing-codux-15j5

3. Storybook szykuje wsparcie dla NextJS, Nuxt, SvelteKit i Remix

W ostatnich latach popularność Storybooka nieustannie wzrasta. Programiści wykorzystują go nie tylko do publikowania w sieci swoich bibliotek komponentów, ale również jako lekkie, dobrze wyizolowane środowisko deweloperskie. Wszystkie fanów Storybooka na pewno ucieszy fakt, że jego twórcy przebudowali znaczną jego część, tak aby ułatwić integrację z kolejnymi frameworkami. W wersji 7.0, która premierę ma mieć jeszcze przed końcem roku, dodane zostanie wsparcie dla Next.js. Następnie twórcy zabiorą się z Nuxt, SvelteKit i Remixa.