En CSS-animation er en ændring af et elements stil, som browseren afspiller over tid. Du kan skrive en på to måder: transition -egenskaben til tilstandsændringer, såsom hover, og animation -egenskaben med @keyframestil sekvenser, der kører af sig selv. Denne guide dækker begge dele. Men pointen bag er enklere end nogen af dem: Den egenskab, du vælger at animere, betyder mere end den syntaks, du vælger at skrive den i. Syntaks tager en eftermiddag at lære. Om animationen kører på compositor-tråden, eller om den tvinger browseren til at genberegne layoutet tres gange i sekundet, er det, der afgør, om interfacet stadig føles hurtigt på den hardware, dine brugere rent faktisk ejer, og det er her, det koster penge at vælge forkert.
Hos Imaginary Cloud vurderer vi animationsarbejde ud fra to elementer: Animation Timing, altså varighed og forsinkelse, der forvandler en øjeblikkelig stilændring til bevægelse, og Inner Components, altså pseudo-elementer og ekstra elementer, der gør det muligt for én komponent at udføre flere bevægelser på én gang. Tilsammen fortæller de dig, hvad en effekt vil koste at bygge og vedligeholde, og de går igen i alle afsnittene herunder.
Der er flere måder at skabe bevægelse på en webside. Du kan indsætte en færdiglavet GIF som et almindeligt billede; det er nemt, men du mister muligheden for at ændre animationen via kode. Du kan manipulere HTML-elementer med JavaScript, hvilket virker, men det kører på browserens hovedtråd og bliver køet op bag alt andet. Eller du kan definere flere stilarter for et element i CSS og lade browseren bevæge sig imellem dem over tid, hvilket er lettere at skrive og lettere for browseren at optimere.
Intet af dette er blot pynt. En indlæsningsanimation fortæller brugeren, at der stadig sker noget, hvorimod en blank, hvid side får dem til at spekulere på, om fanen er gået ned. Samme ventetid, forskellig oplevelse. Det er hele årsagen til, at det er værd at lave animationsarbejde ordentligt frem for slet ikke at gøre det.
CSS tilbyder to typer. transition -egenskaben håndterer hover-effekter og andre brugerinteraktioner. animation -egenskaben håndterer kontinuerlig bevægelse eller, som vi skal se, bevægelse med flere stadier.
Se Pen typer af animationer af Patrícia Silva (@patsilva_tese) på CodePen.
Uanset om de er simple eller komplekse, består enhver CSS-animation af to ting: animationstidsindstilling og indre komponenter. En animation uden tidsangivelse er slet ikke en animation, da den blot ændrer sig øjeblikkeligt. Og indre komponenter er din redning, for oftest er ét element ikke nok til at skabe den effekt, du rent faktisk ønsker. Lad os se på dem hver især.
For at få en jævn animation eller overgang skal du definere tidsgrænser. Både transition og animation egenskaberne giver dig varighed, altså hvor lang tid det tager at gå fra start til slut, hvilket angives af den første tidsenhed i deklarationen. Derefter følger forsinkelse, altså hvor længe elementet venter, før det starter, hvilket angives af den anden.
/* transition: property duration timing-function delay; */
transition: all 0.5s linear 0.2s;
/* animation: name duration timing-function delay iteration-count; */
animation: rotate 1s linear 0.2s infinite;Se Pen animation timing af Patrícia Silva (@patsilva_tese) på CodePen.
Den anden nøglefaktor, og vejen til alt sofistikeret, er indre komponenter. Hvis du kun har brug for et eller to ekstra elementer, er ::before og ::after pseudo-elementer klarer det. Din HTML forbliver præcis, som den var:
<ul>
<li><a href="#">home</a></li>
</ul>Og de to ekstra elementer defineres udelukkende i CSS:
a::before { content: ""; }
a::after { content: ""; }Stil dem som sædvanlig i dit stylesheet. Der er ingen grund til at definere dem i HTML'en overhovedet, da browseren tilføjer dem til hovedkomponenten for dig og lader markuppen forblive intakt. Den eneste forskel er content egenskaben, som tager en streng. Tænk på det som en beskrivelse af teksten inde i en div, bortset fra at du gør det fra CSS-siden. Her er hvordan a::before blev stylet, med en tom streng i content så den ikke skaber andet end det lille hjørne:
a::before {
content: "";
position: absolute;
bottom: 12px;
left: 12px;
width: 12px;
height: 12px;
border: 3px solid #FCD63F;
border-width: 0 0 3px 3px;
opacity: 0;
transition: all 0.3s;
}Og hover-tilstanden, som den skifter til:
a:hover::before {
opacity: 1;
bottom: -8px;
left: -8px;
}Har du brug for mere end to ekstra elementer? Så brug standard HTML-komponenter. Ændr strukturen, indsæt spans uden styling, stil dem, og anvend transitionen eller animationen. Flere komponenter er også berettigede, når du har forskellige typer bevægelser, der sker samtidigt, da hver komponent kun kan håndtere én animation eller transition ad gangen. Indlæsningseffekten herunder er netop det: en div med navnet container med fire spans indeni, hvor containeren har én animation, der får den til at vokse, og hver span har en anden, der får den til at rotere.
<div class="container">
<span></span>
<span></span>
<span></span>
<span></span>
</div>Det er også her, dit estimat kommer fra. En effekt, der ikke kræver interne komponenter, er en ændring i et stylesheet. En effekt, der kræver fire, er en ændring i markuppen, hvilket betyder gennemgang, test på tværs af browsere og en komponent, som nogen skal kunne forstå om et år.
Så hvordan implementerer du en overgang? Start med at definere en start- og slut-tilstand for hvert involveret element, inklusive ::before og ::after komponenterne. transition -egenskaben fortæller derefter disse komponenter, hvordan de skal opføre sig imellem disse tilstande. Den er en sammensætning af fire andre: transition-delay og transition-duration, det tidsrelaterede par, vi dækkede under Animation Timing, plus transition-property og transition-timing-function.
Se Pen transition property af Patrícia Silva (@patsilva_tese) på CodePen.
Lad os se på de to sidste.
Dette angiver, hvilke egenskaber der påvirkes. Sæt den til all og enhver egenskab, der ændrer sig mellem de to typografier, bliver inkluderet. Eller angiv en specifik egenskab, eller et sæt af dem, hvilket er hvad du ønsker, når forskellige egenskaber skal bevæge sig med forskellig hastighed. Lad os sige, at du ønsker, at baggrundsfarven skal ændre sig meget hurtigere end tekstfarven:
transition-property: background-color, color;
transition-duration: 0.2s, 1s;Timing-funktionen indstiller overgangens hastighed. Den har en menu med nøgleordsværdier samt to funktioner, der lader dig definere din egen kurve:
linear, konstant hastighed hele vejen igennem;ease-in, starter langsomt og bliver derefter hurtigere;ease-out, starter hurtigt og bliver derefter langsommere;ease-in-out, en blanding af de to: langsom, hurtigere, langsom igen;ease, en variation af den forrige og standardværdien for denne egenskab;steps(n), som springer mellem n diskrete tilstande i stedet for at interpolere, og er måden, hvorpå sprite-sheet- og skrivemaskineeffekter bygges;cubic-bezier(x1, y1, x2, y2), som definerer din egen accelerationskurve, når ingen af nøgleordene passer;linear(), en nyere tilføjelse, der simulerer fjedre, hop og andre komplekse easing-effekter ved at angive punkter langs kurven. Den har nu bred browserunderstøttelse, så du behøver ikke længere JavaScript for at lave en hoppe-effekt.Se Pen transition-timing-function mulige værdier af Patrícia Silva (@patsilva_tese) på CodePen.
I modsætning til transitions behøver animation -egenskaben ikke en liste over berørte egenskaber eller en eksplicit start- og slutstatus. Den frihed kommer fra keyframes. Keyframes definerer komponentens forskellige stadier under et navn, som du derefter giver til animation -egenskaben. Ved to stadier er from og to tilstrækkeligt. Når du ønsker flere, skal du bruge procenter, som i rotate -animationen fra indlæsningseffekten:
@keyframes rotate {
0% { transform: rotate(0deg); }
10% { transform: rotate(0deg); }
50% { transform: rotate(90deg); }
90% { transform: rotate(90deg); }
100% { transform: rotate(90deg); }
}Ligesom transitioner animation -egenskaben en sammensætning af andre. Du får animation-duration, animation-delay og animation-timing-function, som fungerer præcis ligesom deres modstykker i transition under Animation Timing. Derefter animation-name, hvor navnet på keyframen skal stå. Derefter animation-iteration-count, et specifikt tal eller infinite. Derefter animation-play-state, som tager imod running eller paused og lader dig fastfryse en animation fra en klasse eller et script. Og til sidst animation-direction og animation-fill-mode, begge herunder.
animation-fill-mode er den, der snyder folk. Den besvarer et spørgsmål, man først kommer i tanke om, når noget ser forkert ud: Hvad sker der med elementet uden for selve animationens køretid?
Se Pen animation-direction af Patrícia Silva (@patsilva_tese) på CodePen.
Næsten alle egenskaber, så længe de er angivet med enhedsværdier. Farver, højde og bredde, margener og polstring, opacitet, transform: alt sammen fint. Kantstil, position, float, background-image, font-family: har ingen effekt overhovedet. MDN-referencen over animerbare CSS-egenskaber indeholder den fulde liste.
Men animerbar er ikke det samme som billig. Når en browser gengiver en side, gennemgår den en række trin: Layout, som beregner, hvor hvert element er placeret, og hvor stort det er; Paint, som udfylder pixels; og Composite, som samler de malede lag på skærmen. Hvis du animerer noget, der udløser Layout, som f.eks. width, skal browseren også genberegne Paint og Composite for hver eneste frame. Det er grunden til, at egenskaber, der kun påvirker Composite-trinnet, transform og opacity, bør prioriteres. Googles web.dev-vejledning om CSS-overgange gennemgår, hvorfor transform er det smidige og batterivenlige valg.
Hvis du ved, at et element skal animeres, kan du give browseren et praj med will-change egenskab, så laget promoveres på forhånd. Brug den med måde: Hvis du promoverer alt, modvirker det formålet og bruger unødigt meget hukommelse.
Browserunderstøttelse er ikke længere en begrænsning. Overgange og animationer har været en del af Baseline sættet af bredt tilgængelige funktioner i årevis på tværs af alle større motorer. Det, dit valg af egenskab stadig afgør, er, hvor mange af de tre renderingstrin browseren skal gentage, tres gange i sekundet, på den enhed siden åbnes på.
Se Pen JjKbdeE af Patrícia Silva (@patsilva_tese) på CodePen.
Som nævnt, transform er en af de mest ressourcelette egenskaber at animere. Ressourcelet betyder ikke begrænset. Den giver dig masser at arbejde med:
translate(x, y), flytter et element x pixels horisontalt og y pixels vertikalt. Negative værdier flytter det til venstre eller op, positive værdier til højre eller ned.rotate(y), roterer et element y grader. Positive værdier giver med uret, negative mod uret. Som standard roterer det omkring elementets midte, hvilket du kan ændre med transform-origin -egenskaben.scale(x, y), ændrer størrelsen. To værdier ændrer bredden x gange og højden y gange. Én værdi ændrer begge med den faktor og bevarer elementets proportioner. Brug scaleX(x) og scaleY(y) for at målrette én akse. Over 1 gør det større, mellem 0 og 1 mindre.skew(x, y), forvrænger elementet x grader horisontalt og y grader vertikalt. Giv den én værdi, og kun X-aksen påvirkes, mens y sættes til 0. Som med skalering, målretter skewX() og skewY() hver akse individuelt.matrix(a, b, c, d, tx, ty), som kombinerer skalering, forvrængning og flytning i én erklæring, der tager seks værdier i den rækkefølge.Alle disse roterer omkring elementets midte, medmindre du ændrer transform-origin. Den tager én eller to procenter, eller et af nøgleordene top, bottom, right, left og center. Bemærk den amerikanske stavemåde af det sidste ord: Det er den, CSS-specifikationen definerer, og den eneste form, browseren accepterer.
Hvis du har kigget i koden til de tidligere animationer, har du måske bemærket, at vi ikke bruger transform hele vejen igennem. Det betyder ikke, at de samme animationer ikke kan bygges udelukkende med transformationer. Derfor har vi genskabt begge effekter ved kun at bruge transformfor at vise det. HTML-strukturen forbliver præcis, som den var.
Se Pen tidligere animationer ved brug af transform af Patrícia Silva (@patsilva_tese) den CodePen.
Her er udviklingen, der ændrer betydningen af, hvad en "CSS-animation" overhovedet er i 2026. En scroll-drevet animation knytter en @keyframes sekvens til scroll-positionen frem for til tidens gang. Den "reveal-on-scroll"-effekt, der før krævede IntersectionObserver, en scroll-lytter eller et bibliotek som GSAP, fylder nu tre linjer CSS, og den kører på compositor-tråden i stedet for hovedtråden.
@keyframes fade-in {
from { opacity: 0; }
to { opacity: 1; }
}
.card {
animation: fade-in linear;
animation-timeline: view();
}To funktioner driver den. scroll() knytter animationen til en scroll-containers samlede fremgang, hvilket er præcis, hvad du skal bruge til en læse-indikator. view() knytter den til et specifikt elements position i viewporten, hvilket er, hvad du skal bruge til en reveal-effekt. MDN's guide til scroll-drevne animationer dækker hele API'et.
En ærlig bemærkning om understøttelse. Chromium-browsere har haft dette aktiveret som standard siden Chrome 115 i juli 2023, og Safari tilføjede det i Safari 26 i september 2025. Medio 2026 kræver Firefox stadig et flag, så den globale understøttelse ligger på omkring 82 procent, og funktionen er endnu ikke en del af Baseline. Betragt det som en progressiv forbedring: skriv den afslørede tilstand som din standard, pak bevægelsen ind i @supports (animation-timeline: scroll()), så fejltilstanden blot er "ingen animation" i stedet for en ødelagt side. Pak den også ind i prefers-reduced-motion , da scroll-baseret bevægelse er særligt tilbøjelig til at skabe ubehag for brugere med vestibulære lidelser.
Et relateret par, der er værd at kende: @starting-style sammen med transition-behavior: allow-discrete gør det endelig muligt at animere et element ind og ud af display: none, hvilket er præcis, hvad du har brug for til dialogbokse, popovers og toasts, som tidligere krævede JavaScript.
Forestil dig browserens hovedtråd som en vej med ét spor. Layout, rendering og hver eneste linje af din applikations JavaScript står i kø her, så når en tung opgave optager sporet, må alt bagved vente. CSS-animationer kan, afhængigt af hvilke egenskaber du ændrer, benytte et ekstra spor kaldet compositor-tråden. Animationer på hovedtråden går i stå, når trafikken hober sig op. Dem på compositor-tråden fortsætter ufortrødent.
Konsekvensen er målbar. En browser har cirka 16 millisekunder til at generere hvert billede ved 60 billeder i sekundet, og endnu mindre når dens eget overhead medregnes. Overskrider du det budget, går billedet tabt, og et tabt billede er det, brugeren oplever som hakken. Hold animationer til transform og opacity og arbejdet fjernes helt fra den kritiske sti. Valget af egenskab er langt vigtigere for, om en animation holder sin billedfrekvens, end valget mellem CSS og JavaScript.
Dette er ikke abstrakt for os. Da vores front-end-team genopbyggede AppTweaks dashboard i React og TypeScript, var det at holde det tunge arbejde væk fra hovedtråden en stor del af årsagen til, at indlæsningstiden faldt med 80 procent. Det samme princip, der holder et dashboard responsivt, er det, der holder en animation flydende.
Det betyder også noget kommercielt, for oplevet hastighed er det, brugerne rent faktisk mærker. Responsivitet har nu sit eget Core Web Vital: Interaction to Next Paint (INP) erstattede First Input Delay som et rangeringssignal hos Google den 12. marts 2024, og det måler den fulde latenstid fra et brugerklik til det næste tegnede billede gennem hele besøget, ikke kun ved den første interaktion. Googles egen Search Central-meddelelse forklarer ændringen, og MDN har en letforståelig definition af INP. En animation, der blokerer hovedtråden, skader det tal direkte. En animation på compositor-tråden gør ikke.
JavaScript har stadig sin plads. Brug det, når en animation skal reagere på logik undervejs, eller når du har brug for den finere kontrol, som Web Animations API tilbyder. Til de fleste bevægelser i brugerfladen er CSS det hurtigere og billigere svar. Hvis du ønsker en uvildig vurdering af, hvor din brugerflade mister billeder, er det præcis, hvad en teknisk og UX-audit er til for.
Bevægelse er ikke neutralt. For brugere med vestibulære lidelser kan store eller gentagne bevægelser udløse kvalme og svimmelhed. Det er grunden til, at styresystemer tilbyder en indstilling til reduceret bevægelse, og hvorfor WCAG 2.1 har Animation fra interaktioner som et succeskriterium. At ignorere denne indstilling er en mangel på tilgængelighed. Hvis du har en kunde i den offentlige sektor eller en virksomhedskunde, er det også et spørgsmål om overholdelse af regler.
CSS læser indstillingen direkte via prefers-reduced-motion medieforespørgslen. Den sikreste standard er at beholde dine animationer, som de er, og neutralisere dem for alle, der har anmodet om mindre bevægelse:
@media (prefers-reduced-motion: reduce) {
*,
*::before,
*::after {
animation-duration: 0.01ms !important;
animation-iteration-count: 1 !important;
transition-duration: 0.01ms !important;
scroll-behavior: auto !important;
}
}Den næsten nul-sekunders varighed frem for none er bevidst. Det gør, at enhver animationend handler stadig kan aktiveres, så intet i din JavaScript bliver hængende og venter på en hændelse, der aldrig indtræffer. Og hvor bevægelse har en betydning frem for blot at være dekorativ – som f.eks. en indlæsningsindikator – bør du udskifte den med et statisk eller tonende alternativ i stedet for helt at fjerne feedbacken. Et mere rent mønster til nye projekter er at vælge den omvendte tilgang: definer den reducerede version som standard, og tilføj kun bevægelse inde i @media (prefers-reduced-motion: no-preference).
Animation bliver estimeret som finish, men betalt som ingeniørarbejde. Når man ser på omkostningerne gennem animationstiming og interne komponenter, fordeler de sig på tre områder, som er værd at definere, før arbejdet går i gang.
Det første er udviklingstid, og det er her, interne komponenter spiller en afgørende rolle. En overgang på et eksisterende element kræver blot få linjers kode og tager under en time inklusiv gennemgang. En keyframe-sekvens, der kræver fire interne komponenter, er en helt anden sag: ændringer i markup, gennemgang af disse, test på tværs af browsere og en komponent, som andre skal kunne overtage. Realistisk set tager det en dag frem for en time. Det er det forhold, man bør tage med i sit estimat.
Det andet er performance-risiko. En animation, der trigger layout-ændringer, føles ikke langsom på en hurtig maskine. Problemet opstår på en mellemstor mobiltelefon, hvor det samme budget på 16 millisekunder pr. frame skal overholdes med en brøkdel af processorkraften. Her vil en hakkende brugerflade blive opfattet som et langsomt website frem for blot en dårlig animation. At vælge transform frem for width koster intet i udviklingstid og eliminerer risikoen fuldstændigt. Vores genopbygning af AppTweak-dashboardet er beviset: De 80 procent, vi vandt, kom fra at holde arbejdet væk fra hovedtråden, ikke fra at tilføje mere.
Det tredje er vedligeholdelse. Enhver animation er en tilstand, din brugerflade kan ende i, og hver eneste af dem skal overleve det næste redesign. Timing og interne komponenter hjælper også her. En effekt bygget ud fra en klar timing-regel og et lille, navngivet sæt af interne komponenter er noget, en anden udvikler kan overtage, og som du kan ændre uden at skulle skille hele komponenten ad. Det er den samme disciplin, der gør et designsystem værdifuldt, og den samme grund til, at det kan betale sig at have en UI-udvikler, der ejer front-enden frem for et stylesheet, som ingen har ansvaret for.
Der er en lignende vurdering, når det kommer til værktøjer. Da vi migrerede FlippedNormals fra WordPress til en specialbygget platform på AWS, var beslutningen ikke baseret på, at "specialbygget er bedre" i abstrakt forstand; det handlede om, at den eksisterende stack begrænsede væksten, så migreringen betalte sig selv hjem gennem øget kapacitet og mere trafik. Animationsvalg fungerer på samme måde. Spørgsmålet er ikke, om bevægelse er det værd. Spørgsmålet er, hvilke interaktioner der retfærdiggør det strukturelle arbejde, og hvilke der fungerer glimrende med en simpel overgang på en compositor-only egenskab.
Til det meste arbejde med brugerflader, ja. CSS-animationer på transform og opacity kan håndteres af compositor-tråden og fortsætte med at køre, mens hovedtråden er optaget, hvorimod JavaScript-animationer kører på selve hovedtråden og konkurrerer med alt andet, der foregår der. JavaScript er stadig det rette værktøj, når en animation skal reagere på logik undervejs, eller når du har brug for den finere kontrol, som Web Animations API tilbyder.
transform og opacity, fordi de kun udløser Composite-trinnet i rendering-pipelinen. Animering af width, height, margin, padding eller top og left udløser Layout, hvilket tvinger Paint og Composite til at køre igen for hver frame. MDN's reference til animerbare egenskaber viser, hvad der er tilgængeligt.
En transition kører mellem to tilstande og kræver en udløser, typisk et hover eller en klasseændring. En animation kører af sig selv, kræver ingen udløser og kan definere lige så mange mellemtilstande, som du ønsker, via @keyframes procenter. Brug transition til tilstandsskift. Brug animation til en sekvens.
I de fleste browsere, ja. Scroll-drevne animationer bruger animation-timeline med scroll() eller view() til at knytte en keyframe-sekvens til scroll-positionen, udelukkende i CSS, som kører på compositor-tråden. Understøttelsen er bred, men ikke universel pr. midten af 2026 (Firefox stable er stadig bag et flag), så pak det ind i @supports og behandl det som progressiv forbedring. Se MDN-guiden til scroll-drevne animationer.
Det skyldes normalt, at den animerer en egenskab, der udløser layout, så browseren genberegner geometrien for hvert billede og overskrider sit budget på 16 millisekunder. Tjek først, hvilke egenskaber du animerer, og udskift dem derefter med den tilsvarende transform-egenskab, hvor det er muligt: translate() i stedet for top og left, scale() i stedet for width og height.
Respekter prefers-reduced-motion: reduce medieforespørgsel, som rapporterer den indstilling for reduceret bevægelse, brugeren allerede har valgt på operativsystemniveau. Forkort varighederne til tæt på nul i stedet for at fjerne animationerne helt, så enhver kode, der lytter efter animationend stadig udløses. Og hvor bevægelse har en betydning, såsom feedback ved indlæsning, bør den erstattes med et statisk alternativ frem for slet ikke at vise noget.
Det kan det. En animation på hovedtråden konkurrerer med hændelseshåndtering, hvilket skader Interaction to Next Paint, den Core Web Vital for svartider, som erstattede First Input Delay i marts 2024. Ved at holde animationer på compositoren med transform og opacity holdes det arbejde væk fra den kritiske sti.
Ikke på den samme egenskab. Hvert element kan have én overgang eller animation pr. egenskab, hvilket er præcis grunden til, at avancerede effekter bygges af indre komponenter: ::before og ::after til et eller to ekstra elementer, yderligere spans eller divs når du har brug for mere, hvor hver især bærer sin egen bevægelse.
Så få som muligt for at udtrykke bevægelsen. Den roter animationen i indlæsningseffekten ovenfor bruger fem, og tre af dem eksisterer for at holde en position frem for at bevæge sig imellem dem. Ved at fastholde en tilstand ved 10% og 90% skabes en pause. Tilføjelse af keyframes, der ikke ændrer en værdi, tilføjer intet overhovedet.
At lave animationer med CSS, og med transform i særdeleshed, bør være dit standardvalg. Få styr på animationstider og indre komponenter, og vælg derefter egenskaber, der holder arbejdet i compositor-laget. Det er netop det valg, der adskiller en brugerflade, der kører med 60 billeder i sekundet, fra en, der hakker på den hardware, de fleste af dine brugere har – og det koster intet ekstra i udviklingsfasen at gøre det rigtigt. Vær varsom med at overbruge bevægelse, respekter indstillingen for reduceret bevægelse, og husk det vigtigste punkt af det hele: hvilken egenskab du animerer, betyder mere end antallet af animationer, du skriver.
Hvis du overvejer at optimere din front-end-performance, eller ønsker en second opinion på, hvor en brugerflade mister billeder, tager vores web- og mobiludviklingsteam gerne et kig på det. Du kan se hvordan vi har grebet lignende projekter an eller starte en dialog.
Webudvikler med en særlig kærlighed til front-end. Mor til katte. Jeg forsøger at hjælpe med at redde planeten i min fritid ved at dele miljøvenlige alternativer.
Alexandra Mendes er Senior Growth Specialist hos Imaginary Cloud med 3+ års erfaring med at skrive om softwareudvikling, AI og digital transformation. Efter at have gennemført et frontend-udviklingskursus fik Alexandra nogle praktiske kodningsevner og arbejder nu tæt sammen med tekniske teams. Alexandra brænder for, hvordan nye teknologier former erhvervslivet og samfundet, og hun nyder at omdanne komplekse emner til klart og nyttigt indhold for beslutningstagere.
People who read this post, also found these interesting:
.webp)
