Podsumowanie artykułu
- Stawiaj na komponenty funkcyjne i hooki, by pisać krótszy, wydajniejszy kod.
- Dziel interfejs na małe komponenty i wyraźnie oddzielaj logikę biznesową od UI.
- Wykorzystuj TypeScript + wspólny model danych (np. OpenAPI), by uniknąć błędów typów.
- Rozróżniaj komponenty wielokrotnego użytku od biznesowych; korzystaj z bibliotek UI jak Tailwind czy shadcn/ui.
- Stosuj SSR/ISR lub streaming (Next.js, Astro) dla szybszego ładowania i lepszego SEO.
- Pisz testy (RTL, Jest/Vitest, Cypress) i optymalizuj kod (memo, lazy loading, tree shaking).
- Śledź nowe wersje Reacta i narzędzi, by szybko wdrażać usprawnienia i redukować koszty utrzymania.
React to biblioteka JavaScript służąca do tworzenia interaktywnych interfejsów użytkownika. Jej kluczową zaletą jest możliwość wielokrotnego użycia komponentów, co przyspiesza proces tworzenia aplikacji oraz zapewnia wysoką wydajność działania samego interfejsu. Co więcej istnieją łatwe do zintegrowania z Reactem biblioteki umożliwiające automatyczne testowanie, co przekłada się na mniejszą liczbę błędów i niższe koszty utrzymania oprogramowania. Jednak pełnię możliwości tej technologii można osiągnąć dopiero wtedy, gdy wdroży się dobre praktyki programistyczne i sprawdzone narzędzia. Oto nasze doświadczenia z pracy z Reactem zebrane w formie praktycznego przewodnika.
#1 Stosuj komponenty funkcyjne
W React można definiować komponenty na dwa sposoby: jako klasowe lub funkcyjne. Z biegiem lat to właśnie te drugie stały się standardem.
Zmiana ta nie jest przypadkowa. Komponenty funkcyjne oznaczają krótszy, bardziej przejrzysty kod, który łatwiej się pisze i czyta. Wystarczy wspomnieć, że oficjalna dokumentacja Reacta jest obecnie przepisywana w oparciu o komponenty funkcyjne — to jasny sygnał kierunku rozwoju.
Znaczna większość materiałów i zasobów dostępnych online — szczególnie tych regularnie aktualizowanych — bazuje właśnie na komponentach funkcyjnych. W praktyce oznacza to, że w razie problemów łatwiej będzie znaleźć pomoc czy zrozumieć przykłady, jeśli kod będzie napisany w tej samej konwencji.
Co więcej, komponenty funkcyjne łatwiej testować, a dzięki ich implementacji w runtime Reacta — po prostu działają szybciej. Chociaż twórcy Reacta nie zamierzają całkowicie usuwać komponentów klasowych ze swojej biblioteki (z racji istnienia wielu projektów na nich opartych), to obecnie ich nie rozwijają i sami zalecają wykorzystywać w nowych projektach podejście funkcyjne.
#2 Wykorzystuj hooki
Wersja 16.8 Reacta wprowadziła API hooków, co pozwoliło odejść od cięższych komponentów klasowych na rzecz lżejszych, funkcyjnych, także w przypadku bardziej złożonej logiki UI.
Dzięki hookom zyskuje się bezpośredni dostęp do funkcji Reacta, jak np. stan komponentu (useState) czy efekty uboczne (useEffect), bez potrzeby pisania klas. Kod jest więc krótszy, czytelniejszy i łatwiejszy w utrzymaniu.
Należy wspomnieć także hooki istotne w kontekście optymalizacji: useCallback oraz useMemo, które pozwalają memoizować funkcje i wartości. Są to swoiste sposoby cache’owania ograniczające re-rendery w aplikacji (więcej o tym w punkcie #11).
Najnowsze wydanie Reacta — wersja 19 — wprowadziło kolejne hooki warte uwagi: do obsługi „Actions”, takich jak useActionState i useOptimistic, które upraszczają zarządzanie stanem formularzy i operacji asynchronicznych.
Jeszcze ważniejsza jest możliwość ponownego wykorzystania hooków. Zamiast kopiować logikę lub przenosić ją do komponentów wyższego rzędu (HOC) czy wspólnych przodków w drzewie komponentów, można stworzyć własny hook i używać go wszędzie tam, gdzie jest potrzebny. To eliminuje duplikację kodu i pozwala na tworzenie abstrakcji dostosowanych do potrzeb konkretnej aplikacji.
Nie istnieją ograniczenia co do typu hooków, które można tworzyć — można więc budować własne, precyzyjnie dopasowane do logiki danego projektu.
Warto jednak podkreślić, że używanie hooków powinno być racjonalne i uzasadnione. Programista powinien świadomie decydować, w jakim miejscu przyniosą one korzyść, a w jakich nadmierne ich wykorzystywanie może pociągać za sobą straty, np. wydajnościowe.
#3 Twórz małe komponenty
Rozmiar komponentów ma ogromne znaczenie. Im mniejszy komponent, tym łatwiej go zrozumieć i używać, co z kolei przyspiesza wdrażanie nowych członków zespołu do projektu. Mniejsze komponenty łatwiej testować, co skraca czas pisania testów i zmniejsza liczbę błędów.
Warto z góry ustalić maksymalny dopuszczalny rozmiar komponentu. Pomaga to w stosowaniu zasady Separation of Concerns (SoC), czyli dzielenia aplikacji na wyraźnie określone moduły odpowiadające za różne funkcje. Ułatwia to również wdrażanie standardów branżowych, takich jak WCAG, czy optymalizację pod SEO.
Gdy komponent zbliża się do granicy rozmiaru, warto rozważyć code splitting — czyli dzielenie kodu na mniejsze, wyspecjalizowane fragmenty. Komponenty warto także klasyfikować zgodnie z ich funkcją, np. warstwa prezentacji, logiki biznesowej, dostępu do danych czy warstwa trwałości. Z pomocą przychodzą także wspomniane już custom hooki pozwalające stosować reużywalność logiki.
Z biznesowego punktu widzenia trzymanie się zasady „mały komponent = jeden cel” to realne oszczędności. Mniejszy kod, mniej błędów i łatwiejsze testowanie oznaczają znacznie niższe koszty utrzymania aplikacji.
#4 Oddzielaj logikę biznesową aplikacji od warstwy interfejsu użytkownika (UI)
Gdy komponenty zawierają jednocześnie logikę UI i logikę biznesową, struktura kodu staje się zbyt złożona. Tego typu komponenty trudniej testować, trudniej je refaktoryzować, są mniej wielokrotnego użytku, a zarządzanie stanem staje się problematyczne.
Zastosowanie tej zasady przynosi wiele korzyści. Proces wprowadzania zmian przebiega szybciej, ponieważ logika — czy to biznesowa, czy związana z wyglądem — jest łatwiejsza do znalezienia w mniejszych komponentach. Dodatkowo komponentów w aplikacji jest po prostu mniej, ponieważ mniejsze elementy można wykorzystywać wielokrotnie. Dotyczy to zarówno przycisków, menu, jak i całych formularzy czy bloków funkcjonalnej logiki — co znacząco upraszcza proces utrzymania kodu. Dodanie nowego elementu do projektu React to najczęściej po prostu dodanie nowego komponentu, a nie edycja kilku już istniejących.
Od strony technicznej logikę zarządzania stanem warto wyodrębnić do osobnego hooka, zamiast implementować ją bezpośrednio w komponencie. Potrzebną logikę można wtedy osadzić w komponencie potomnym, do którego komponent nadrzędny przekazuje odpowiednie props.
Oddzielenie warstwy biznesowej od warstwy interfejsu użytkownika przynosi też korzyści organizacyjne. Tak zbudowane komponenty UI mogą być z łatwością prezentowane jako zbiór gotowych elementów (np. z użyciem Storybooka) lub jako biblioteka komponentów. Dzięki temu stają się dostępne do omówienia z zespołem UI/UX lub do manualnych testów w bezpiecznym środowisku.
Wersja 19 biblioteki React wprowadza jeszcze jeden istotny element separacji — React Server Components (RSC), który w naturalny sposób przenosi część logiki biznesowej na serwer.
Na koniec warto dodać, że posiadanie takiej biblioteki komponentów znacząco ułatwia wdrażanie nowych członków zespołu do projektu.
#5 Rozróżniaj komponenty wielokrotnego użytku od tych specyficznych dla logiki biznesowej
Na poziomie całej aplikacji kluczowe jest oddzielenie komponentów wielokrotnego użytku od tych, które odpowiadają za realizację logiki biznesowej. Te pierwsze służą do budowania podstawowych interakcji i powinny być wykorzystywane jak najczęściej. Komponenty biznesowe z kolei łączą mniejsze elementy w celu realizacji konkretnych funkcji wymaganych z perspektywy działania aplikacji.
Wyraźne rozróżnienie między tymi typami komponentów pomaga w podjęciu decyzji, czy potrzebny jest nowy komponent, czy wystarczy wykorzystać już istniejący. To z kolei radykalnie obniża koszty utrzymania i modyfikacji aplikacji.
W projektowaniu frontendu popularne jest także podejście Atomic Design, które również zakłada podział komponentów na poziomy abstrakcji (atomy, molekuły, organizmy). Choć Atomic Design jest tylko jedną z metodologii, odzwierciedla tę samą ideę rozdziału warstw.
Obserwowane jest także powszechne korzystanie z gotowych bibliotek (Tailwind, Materialize, Bootstrap, Ant Design, czy zyskujący na popularności shadcn/ui) jako bazy „reusable components”, przy jednoczesnym pisaniu specyficznych komponentów biznesowych w aplikacji. Dzięki temu zespół może szybko budować funkcje biznesowe (składając gotowe klocki UI), zachowując spójny wygląd i redukując kod UI do utrzymania.
W skrócie, zasady te można sprowadzić do dwóch kluczowych wskazówek:
- Jeśli występują długie instrukcje warunkowe, warto rozdzielić zmienne na mniejsze fragmenty.
- Każdy element UI powinien mieć swoją własną strukturę komponentów.
#6 Korzystaj z TypeScript
JavaScript jako język dynamicznie typowany daje dużą elastyczność, ale w środowisku React może to prowadzić do większej liczby błędów. Komponenty Reacta nie mają z natury ściśle określonych typów danych, co utrudnia zarówno rozwój nowych funkcji, jak i utrzymanie istniejących.
Z tego względu TypeScript — jako nadzbiór języka JavaScript umożliwiający statyczne typowanie — jest idealnym uzupełnieniem aplikacji opartych na React. Można go stosować wszędzie: od obsługi API, przez logikę aplikacyjną, aż po najmniejsze komponenty UI. TypeScript zapewnia spójność typów danych w całej aplikacji webowej, pozwalając uniknąć błędów wynikających z ich niezgodności. Ułatwia też nanoszenie zmian w istniejących komponentach, wskazując, gdzie typy danych wymagają modyfikacji.
Dzięki TypeScriptowi możliwe jest łatwe korzystanie z istniejących już elementów aplikacji, a środowisko programistyczne (IDE) uzyskuje dodatkowe informacje, które wspomagają pracę programisty. Aplikacja staje się w ten sposób bardziej niezawodna podczas wdrażania nowych funkcji, a koszty i czas ich realizacji — mniejsze.
#7 Stwórz wspólny model danych dla frontendu i backendu
Podczas implementacji nowych funkcjonalności lub modyfikowania istniejących, zapewnienie spójności między API a aplikacją pochłania znaczną część czasu i zasobów zespołu. Narzędzia takie jak OpenAPI oraz automatycznie generowany interfejs API znacząco upraszczają ten proces, umożliwiając integrację frontendu z backendem bez konieczności angażowania programistów w każdą drobną zmianę.
W połączeniu z TypeScriptem, OpenAPI zapewnia spójność typów w całej aplikacji, co przekłada się na niższe koszty utrzymania usług API oraz mniejszą liczbę błędów.
W przypadku tworzenia nowego projektu w React, programiści mają dostęp do gotowych metod i nie muszą zagłębiać się w niskopoziomowe szczegóły dotyczące zapytań API. Dla bardziej złożonych funkcji obiektowy TypeScript oraz modele danych dostarczone przez OpenAPI umożliwiają tworzenie tzw. modeli pośrednich. Ułatwiają one formatowanie danych, ich serializację i deserializację, a także stosowanie wzorców projektowych adekwatnych do aktualnych potrzeb.
Jako inne popularne podejścia do zapewnienia spójności modelu danych można wskazać także GraphQL (możliwość generowania typów po stronie klienta) i tRCP (umożliwiające budowanie API typu RPC z natywnym współdzieleniem typów).
Takie rozwiązania pozwalają na wyraźne oddzielenie warstwy danych w aplikacji i upraszcza zarządzanie komponentami Reactowymi.
#8 Stosuj odpowiednie metody komunikacji między komponentami
W React komponenty organizowane są w strukturę drzewa, w którym każdy komponent może być rodzicem lub dzieckiem innego komponentu. Komunikują się one ze sobą na różne sposoby — od najprostszych po bardzo złożone. Do podstawowych metod należy przekazywanie props i funkcji zwrotnych (callback), nieco bardziej zaawansowaną opcją jest React Context, natomiast najbardziej rozbudowanym rozwiązaniem — Redux lub inne biblioteki do zarządzania stanem aplikacji.
W dużych aplikacjach zazwyczaj stosuje się kombinację wszystkich trzech podejść. Kluczowe jest jednak nie tylko, jakie metody się stosuje, ale również — gdzie się je stosuje. Nieprawidłowe użycie może prowadzić do niepotrzebnych komplikacji i zwiększenia kosztów projektu.
- Props to zestaw zmiennych przekazywanych z komponentu nadrzędnego do podrzędnego w dół drzewa komponentów.
- Callbacki to funkcje, które umożliwiają przekazywanie danych w drugą stronę — z komponentu potomnego do rodzica. Samą funkcję callback również można przekazać jako prop.
Ten model komunikacji sprawdza się przy prostych relacjach rodzic–dziecko i nieskomplikowanych funkcjonalnościach. Warto jednak pamiętać, że zbyt rozbudowana struktura komunikacyjna, zwłaszcza z wieloma komponentami przekazującymi dane w różnych kierunkach, utrudnia śledzenie przepływu informacji i zwiększa ryzyko błędów.
React Context służy do komunikacji między komponentami należącymi do tej samej gałęzi drzewa komponentów. Należy jednak dbać, by ta gałąź nie była zbyt rozbudowana i monitorować wydajność. Context nie powinien być wykorzystywany do budowania wielu funkcjonalności jednocześnie.
Redux jest wykorzystywany w przypadku konieczności komunikacji między komponentami na różnych poziomach aplikacji. Nadaje się do obsługi wielu funkcjonalności i zależności między nimi. Należy jednak kontrolować liczbę tzw. reducerów i w razie potrzeby dzielić je na mniejsze, niezależne grupy.
W Reduxie komunikacja nie powinna przebiegać przez komponenty UI — źródłem akcji ma być użytkownik, a nie komponent.
Warto wspomnieć także o Redux Toolkit (RTK), którego celem jest standaryzacja pisania logiki, a także uproszczenie złożoności samego Reduxa.
Inne zyskujące na popularności, a także dużo lżejsze biblioteki do zarządzania globalnym stanem, to chociażby Zustand i Jotai, a także biblioteka data-fetching Tanstack React Query, która umożliwia pobieranie, cache’owanie oraz synchronizowanie i aktualizowanie stanu serwerowego.
Na koniec należy podkreślić, że procesy przepływu informacji w aplikacji powinny być rozsądnie zaplanowane. Czasem użycie zwykłej kombinacji Reactowych useReducer i Context są wystarczające i eliminują konieczność stosowania „ciężkich” bibliotek.
#9 Śledź rozwój metod stylowania aplikacji
Jest to obszar dynamicznie zmieniający się. Często po okresie boomu na jakąś metodę okazuje się ona ciężka do dostosowania do, np. zmieniających się technik renderowania czy po prostu mało wydajna. Takim przykładem jest chociażby runtime CSS-in-JS (JSS, starsze wersje styled-components/Emotion) Okazał się on mieć duży narzut wydajnościowy. W temacie bardzo popularnej biblioteki styled-components sam jej twórca ogłosił przejście w maintenance mode, właśnie z racji umocnienia się trendu rezygnowania z tej techniki, ale także rozwoju samego Reacta.
Obecnie zaczynają pojawiać się inne podejścia, wśród których możemy wyróżnić dwa dominujące :
- utility-first CSS (Tailwind) — bardzo szybki wzrost popularność, łatwość prototypowania, dobra wydajność,
- CSS Modules i preprocesory — lokalny zakres stylów, brak narzutu run-time.
Głównym elementem decydującym przy wyborze metody powinien być jednak zawsze kontekst całej aplikacji, jej wielkość, czy wybrane technologie. Nie zawsze potrzebne jest użycie wieloelementowych bibliotek wymagających dodatkowych konfiguracji. Może się także okazać, że wybrany tech stack wspiera jakąś konkretną metodę, np. Next.js i podejście CSS modules. Ważne są także po prostu preferencje zespołu. Nie każdy developer czuje się dobrze, np. w podejściu utility-first.
#10 Stosuj renderowanie po stronie serwera (SSR i techniki pokrewne), serwując aplikację React
Aplikacja webowa zbudowana w React może być jedynie częścią większego systemu i działać tylko w niektórych jego sekcjach. Może też stanowić pojedynczy komponent osadzony w większej usłudze lub funkcjonować jako w pełni renderowana po stronie klienta strona internetowa.
Najczęściej jednak mamy do czynienia z aplikacjami webowymi pełniącymi funkcję wielofunkcyjnych serwisów informacyjnych. W takich przypadkach problemem może być długi czas uruchamiania. Aby temu zaradzić, należy jak najszybciej rozpocząć pobieranie danych z serwera. Sprawdzonym rozwiązaniem jest renderowanie po stronie serwera (SSR), które inicjuje proces renderowania zanim treść trafi do użytkownika.
SSR ma jednak swoje ograniczenia — może podwoić obciążenie obliczeniowe, zwłaszcza jeśli rendering musi być powtórzony po stronie klienta (np. po zmianie stanu), lub powodować opóźnienia, jeśli każda zmiana stanu musi być najpierw wyrenderowana na serwerze.
Alternatywą jest streaming dynamicznych stron, dzięki któremu przeglądarka może pobierać wszystkie zasoby równolegle.
Obecnie rynek zdominowały gotowe frameworki, zwłaszcza Next.js. Oprócz SSR oferuje on również ISR (Incremental Static Regeneration — dynamiczne aktualizowanie statycznie wygenerowanych stron) oraz SSG (Static Site Generation). Dużą rewolucją było także pojawienie się React Server Components (na których opiera się Next.js w podejściu App Router) oraz Server Functions. Innymi opcjami mogą być Remix, czy zyskujący ogromną popularność framework Astro, świetnie nadający się do stron zawierających duże ilości treści.
Warte podkreślenia jest również to, że zastosowanie powyższych sposobów renderowania stron ma duży wpływ na optymalizację pod kątem SEO.
#11 Testuj wszystkie komponenty Reactowe
Choć może się wydawać, że testowanie i lintowanie spowalnia pracę, wielu programistów zupełnie pomija ten etap. To jednak poważny błąd. Odpowiednie testowanie w dowolnym języku programowania przynosi szereg korzyści:
- Testy pomagają nie tylko wykrywać błędy, ale też weryfikować, czy każdy fragment kodu działa zgodnie z oczekiwaniami.
- Ich celem jest zapewnienie, że nowy kod nie zakłóci działania już istniejących funkcjonalności.
- Im wcześniej zostanie wykryty błąd, tym lepsza jakość końcowego produktu i łatwiejsze jego utrzymanie.
- Testy mogą stanowić użyteczną dokumentację — zarówno w raportach, jak i przy dalszym rozwoju projektu.
- Zaniedbanie testowania może prowadzić do kosztownych błędów ujawnionych dopiero po wdrożeniu.
- Aplikacje pozbawione błędów budzą większe zaufanie użytkowników i zwiększają ich lojalność, co przekłada się na rozwój biznesu.
W ekosystemie React dostępnych jest wiele narzędzi do testowania komponentów. Najlepiej testować kod na bieżąco — również wtedy, gdy importuje się komponenty z innych źródeł — oraz wdrażać automatyzacje na poziomie CI/CD.
Poza popularną biblioteką React Testing Library, warto znać też Jest — narzędzie do uruchamiania testów JavaScript, które emuluje DOM za pomocą jsdom,oraz nowocześniejszą, szybszą alternatywę w postaci Vitest. Dobrą praktyką jest również pisane testów E2E, np. z użyciem narzędzi Cypress lub Playwright.
Reactowe aplikacje można także testować bezpośrednio w przeglądarce podczas ich budowy (np. z użyciem dedykowanych rozszerzeń). Należy jednak pamiętać, że testy w nowym środowisku mogą nie być w pełni miarodajne — niektóre błędy mogą wynikać z działania samej przeglądarki, a nie kodu aplikacji.
#12 Dbaj o optymalizację i dostępność aplikacji
Bardzo ważną kwestią jest dbanie o wydajność aplikacji. Wpływa to zarówno na odbiór użytkowników, koszty jak i scoring aplikacji (a co za tym idzie, np. jej pozycję w wyszukiwarkach). Niemniej istotną praktyką jest dążenie do dostępności dla jak najszerszej grupy odbiorców. Przyjrzyjmy się, jak można to osiągnąć:
Optymalizacja renderowania
React posiada natywne mechanizmy, np. służące memoizacji:
- memo: dla komponentów funkcyjnych; zapobiega re-renderom przy niezmienionych propsach (płytkie porównanie). Należy stosować rozważnie, gdyż sama operacja porównania ma swój koszt;
- useMemo: memoizuje wyniki kosztownych obliczeń. Rekalkulacja następuje tylko przy zmianie zależności. Jest to szczególnie przydatne dla wartości (np. obiektów, tablic) przekazywanych jako propsy do komponentów opakowanych w memo, zapewniając stabilność referencji;
- useCallback: memoizuje funkcje callback. Zapobiega tworzeniu nowych instancji funkcji przy każdym renderowaniu, co jest kluczowe dla stabilności referencji propsów funkcyjnych, zwłaszcza w kontekście memo.
Lazy loading
- lazy() i <Suspense>: implementuj code splitting na poziomie komponentów, ładując je dynamicznie tylko wtedy, gdy są potrzebne (np. dla konkretnej trasy lub po interakcji użytkownika). Komponent <Suspense> pozwala wyświetlić UI zastępcze (np. spinner) podczas ładowania. Redukuje to początkowy rozmiar paczki JavaScript i skraca czas do interaktywności (TTI).
- obrazy: stosuj natywny atrybut loading=”lazy” dla obrazów <img>, aby opóźnić ładowanie tych, które znajdują się poza widocznym obszarem ekranu.
Optymalizacja bundli:
- code splitting: technika dzielenia głównej paczki JavaScript na mniejsze, ładowane asynchronicznie fragmenty. Bundlery takie jak Webpack czy Vite wspierają automatyczne dzielenie kodu, np. na podstawie tras lub dynamicznych importów;
- Tree Shaking: proces eliminacji nieużywanego kodu (tzw. „dead code”) z finalnej paczki produkcyjnej. Działa w oparciu o statyczną strukturę modułów ES6 (import/export).
Wdrażanie wytycznych WCAG (Web Content Accessibility Guidelines)
Wzrasta świadomość dostosowywania stron internetowych także dla osób z niepełnosprawnościami; to nie jest już tylko „przykry wymóg” dla instytucji czy sektorów zobligowanych prawnie do spełniania wymogów, ale po prostu dobra praktyka wpływająca na wizerunek.
#13 Śledź nowe wersje Reacta
Jedną z największych zalet oprogramowania open-source jest ciągłe ulepszanie kodu przez społeczność. Oznacza to jednak, że React stale się zmienia — pojawiają się nowe funkcje, modyfikowane są istniejące, a inne całkowicie usuwane.
Dlatego warto na bieżąco śledzić kolejne wersje Reacta. Pozwoli to odpowiednio wcześnie wprowadzać optymalizacje i zmiany w bazie kodu, zarówno z konieczności, jak i w celu poprawy wydajności.
Najlepszym źródłem informacji jest oficjalna dokumentacja Reacta, publikowana przez jego twórców. Równie istotne są społeczności Reactowe w mediach społecznościowych — to tam najszybciej pojawiają się dyskusje o nowościach i ich wpływie na pracę deweloperów.
Warto pamiętać, że aktualizacje obejmują nie tylko Reacta, ale również zewnętrzne biblioteki, które mogą wymagać dostosowania po zmianach w głównej bibliotece. Przykładem jest chociażby React Router, który często podąża za zmianami w API Reacta.
Dobre praktyki w React — podsumowanie
Stosując opisane powyżej dobre praktyki w pracy z Reactem, można tworzyć zarówno proste strony jednostronicowe, jak i rozbudowane serwisy internetowe zawierające tysiące podstron. Praktyki te pozwalają budować rozwiązania dostosowane do potrzeb informacyjnych i CMS-owych, a także optymalizować koszty implementacji i utrzymania aplikacji.
Co równie istotne — umożliwiają pracę mądrzejszą, a nie cięższą.
