/** @type {import('tailwindcss').Config} */
module.exports = {
theme: {
extend: {
keyframes: {
gradient: {
'0%, 100%': { 'background-position': '0% 50%' },
'50%': { 'background-position': '100% 50%' },
},
},
animation: {
gradient: 'gradient 8s ease infinite',
},
},
},
}
// Utilizare în HTML/JSX:
// <div class="bg-gradient-to-r from-blue-500 via-purple-500 to-pink-500 bg-[length:400%_400%] animate-gradient">
// Conținutul tău aici
// </div>Am văzut recent un proiect unde cineva a tras Framer Motion doar ca să facă un gradient să se miște pe fundalul unui landing page. Mi s-a părut un overkill total. Am pățit și eu la început să instalez librării pentru orice mică animație, dar acum, după vreo 10 ani de spart ecrane, prefer să țin lucrurile cât mai „lean”. Dacă poți să rezolvi o problemă cu 5 linii de CSS, de ce să adaugi o dependență în plus în package.json?
La un proiect cu vreo 12k vizitatori unici, am observat că timpul de interactivitate (TTI) creștea aiurea din cauza scripturilor de animație care rulau pe main thread. Am decis să curăț tot ce înseamnă JS pentru UI-ul static și am trecut pe CSS pur. Rezultatul? Am economisit cam 25% la timpul de execuție al scripturilor la load. Nu e mult pentru un desktop de gaming, dar pe un telefon mid-range se simte imediat diferența de fluiditate.
Logica din spatele gradientului mișcător
Ideea e simplă și veche de când lumea: faci gradientul mult mai mare decât containerul în care stă și apoi îl muți dintr-o parte în alta. Dacă fundalul are exact aceeași dimensiune ca elementul, n-ai unde să-l muți, deci nu vezi nicio mișcare. Eu de obicei îl pun la 200% sau chiar 400% din lățimea elementului.
Folosind Tailwind, avem două variante. Ori scriem clase arbitrare (care devin urâte repede), ori extindem configurația. Eu prefer varianta a doua pentru că e mult mai ușor de întreținut. Dacă ai nevoie să schimbi viteza animației peste 6 luni, nu vrei să cauți prin 50 de fișiere .tsx după animate-[gradient_3s_linear_infinite].
Configurarea în Tailwind
Trebuie să adaugi două chestii în tailwind.config.js: un set de keyframes și animația propriu-zisă. Keyframes-urile vor muta background-position de la stânga la dreapta (0% la 100%). E important să înțelegi că animația asta nu consumă aproape deloc resurse pentru că browserul știe să optimizeze schimbările de poziție ale fundalului.
După ce ai setat asta, în HTML pur și simplu aplici clasa de animație și te asiguri că ai un background-size generos. Fără un bg-[length:400%_400%], animația ta o să stea pe loc și o să te întrebi de ce nu merge. Am pierdut vreo 20 de minute prima dată când am încercat asta pentru că uitasem exact detaliul ăsta banal.
Trade-off-uri și performanță
Merge perfect pentru hero sections, butoane cu „stclipici” sau skeleton loaders mai răsărite. E „smooth as butter” la 60fps pentru că majoritatea browserelor moderne deleagă treaba asta către GPU.
Totuși, există și o parte mai puțin roz. Dacă ai 40 de elemente pe pagină care fac asta simultan, s-ar putea să vezi un mic spike în consumul de baterie pe mobile. Alt minus e că ești limitat la animații liniare sau simple. Dacă ai nevoie de interacțiuni complexe, unde gradientul trebuie să urmărească mouse-ul cu un easing elastic, atunci da, poate Framer Motion sau un mic script de JS are sens. Dar pentru un simplu fundal care „trăiește”, CSS-ul e rege.
Eu folosesc tehnica asta de fiecare dată când vreau să dau puțină viață unui UI fără să stric scorul de Lighthouse. Voi cum procedați? Preferați controlul total din JS sau încercați să împingeți cât mai multă logică vizuală în CSS?