CSS Animasyonlarında Fazla Mesai: FSCSS ile Rahatlayın

CSS animasyonları güzel bir şey, buna itirazım yok. Doğru yerde kullanınca sayfaya küçük bir kıpırtı, biraz karakter katıyor. Ama iş sayı saydırmaya, adım adım ilerlemeye ya da bir listeyi döndürmeye gelince… işte o noktada elinizde tuttuğunuz sade CSS, bir anda memuriyet evrakına dönüşüyor.

Geçen ay Kadıköy’de çalışan bir ekiple konuşurken tam bu konu açıldı. Yüklenme yüzdesini saf CSS ile yapmak istemişler; 0’dan 100’e kadar tek tek keyframe yazmanın tam ortasında yüz ifadeleri değişmiş. Anlıyorum onları,. Ben de 2023 sonbaharında kendi yan projemde benzer bir şeye bulaşmıştım — küçük bir sayaç animasyonu derken dosya uzadı gitti, PR incelemesi ise resmen çileye döndü. Neyse, uzatmayayım. Mesele şu: tekrar eden animasyonları elle yazmak artık gereksiz yere ağır bir iş haline gelmiş durumda.

Evet, doğru duydunuz.

Neden Elle Yazılan Keyframe’ler Can Sıkıyor?

Bakın şimdi. Yüzde hesaplamak basit görünüyor (bizzat test ettim). Ama 1’den 100’e kadar giden bir sayaç animasyonu yazmaya oturunca ortaya çıkan şey CSS değil, resmen sabır testi oluyor — tek tek satırlar, aynı yapı, sadece sayı değişiyor… Bir süre sonra kodu okuyan insan değil, arkeolog oluyor (evet, doğru duydunuz)

İşin aslı şu ki problem sadece uzunluk değil. Böyle dosyalar bakımı zorlaştırıyor; bir gün “100 — kendi adıma konuşayım — yerine 500 olsun” deniyor, ertesi gün “adımlar 10’ar artsın” geliyor ve siz kendinizi aynı bloğu yeniden düzenlerken buluyorsunuz. Bunu geçen yıl Şişli’deki bir ürün demo toplantısında canlı canlı gördüm. Tasarımcı gayet sakin “bir de bunu yüzde yerine kelime listesiyle yapabilir miyiz?” deyiverdi. Ortam buz kesti.

Bunu biraz açayım.

Aslında, Gel gelelim bu tür işleri JavaScript’e kaçırmak da her zaman iyi fikir değil. Evet, JS güçlüdür. Ama DOM’u sık kurcalarsanız layout thrashing gibi performans canavarları kapıyı çalabiliyor. Problem başka yere taşınıyor; çözülmüyor, sadece başka odada devam ediyor.

Elle yazınca neler bozuluyor?

Bi saniye — Kod şişiyor. Review süresi uzuyor. Hata yapma ihtimali artıyor. Bir de üstüne ekip içinde “bu yüzde niye 37’de takılmış?” gibi sorular çıkıyor. Açık konuşayım — sırf animasyon için bu kadar manuel emek harcamak artık biraz eski usul kalıyor.

Mesela startup tarafında bu daha can yakıcı hissettiriyor çünkü ekip küçük; herkes hem feature çıkarıyor hem bug kapatıyor hem de CSS dosyasının dumanını siliyor (inanın bana) — valla güzel iş çıkarmışlar —. Neden önemli bu? Kurumsal tarafta ise mesele daha farklı: güvenlik incelemesi var, performans raporu var, erişilebilirlik kontrolü var… yani her ekstra satır ayrı bir yük olarak dönüyor önünüze.

Senaryo	Standart CSS	FSCSS yaklaşımı
Yükleme yüzdesi	Saatlerce keyframe yazma	Tek tanım + otomatik üretim
Aralık değişimi	Tüm bloğu elden geçirme	Sadece başlangıç/bitiş değerini güncelleme
Ekip içi bakım	Zor ve sıkıcı	Daha okunur ve kısa kaynak kodu
Performans kaygısı	JS eklenirse risk büyür	Saf CSS çıktısı alınır

FSCSS Ne Yapıyor da Bu Kadar Fark Yaratıyor?

FSCSS’in olayı aslında çok net: tekrarı azaltmak. Normalde Sass ya da Less daha geniş kapsamlı araçlar — değişkenler, mixin’ler, iç içe yapılar falan derken her işi çözmeye çalışırlar (evet, doğru duydunuz). FSCSS ise daha dar ama daha vurucu bir alanda oynuyor; keyframe üretimi üzerine odaklanıyor. Başka bir şeyle ilgilenmiyor.

Dürüst olmak gerekirse, Bana kalırsa bunun en güçlü yani zihinsel yükü azaltması. Şöyle düşünün: kod yazarken bir sürü küçük karar vermeniz gerekiyor ya, hani her satırda küçük bir “şimdi ne yapayım” anı yaşanıyor… işte o kararlardan biri ortadan kalkınca kafa gerçekten rahatlıyor. Evde faturaları tek tek elle hesaplamak yerine Excel formülü kullanmak gibi bir şey bu.

Kullandığı üç temel fikir:

• Değer dizileri: Bir dizi sayıyı ya da değeri isim altında topluyorsunuz.
• Döngü sözdizimi: Bu diziyi doğrudan keyframes içinde geziyorsunuz.
• Otomatik oranlama: Yüzde hesabını derleyici sizin yerinize yapıyor.

Dışarıdan bakınca küçük bir detay gibi duruyor. Ama pratikte bayağı fark ediyor — özellikle sürekli değişen metrikleri görselleştiren arayüzlerde, mesela ilerleme göstergeleri, sayaçlar ya da sıralı kart animasyonları gibi bileşenlerde, elle müdahale etmeden temiz çıktı almak ciddi bir rahatlık veriyor.

Benim gözümde FSCSS’in en büyük artısı “az kodla çok iş” değil; asıl mesele bakım maliyetini düşürmesi. Bugün size ufak görünen tekrarlar, altı ay sonra teknik borca dönüşüyor.

Peki Gerçekte Nasıl Çalışıyor?

Klasik yöntemde şöyle bir yapı kurarsınız: yüzde yüzde giderek içerik basarsınız ya da transform değerlerini sıraya koyarsınız. Uzun olur. Hem de gereksiz uzun.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Daha fazla bilgi için Bybit API Python Rehberi: Emirler ve Pozisyonlar yazımıza bakabilirsiniz.

@keyframes countUp {
0% { content: "0%"; }
1% { content: "1%"; }
/*... */
100% { content: "100%"; }
}

FSCSS tarafında ise mantık çok daha kısa ve düzenli akıyor:

@arr numlist [count(100)];
@keyframes countUp {
f-each: numlist (1% to 100%) {
content: "$value%";
}
}

Neyse, dürüst olmak gerekirse, Bunu görünce insanın aklına şu soru geliyor: “E tamam da neden bunu baştan beri böyle yapmıyoruz?” Çünkü CSS’nin tarihi başka yoldan geldi tabii — önce statik tasarım vardı, sonra hareket geldi, şimdi ise o hareketin kendisini programlanabilir hale getirmeye çalışıyoruz.

Açık konuşayım. Burada büyü yok. Derleyici sadece sizin adınıza döngüyü açıp gerçek CSS’e çeviriyor. Tarayıcı yine düz CSS görüyor; fark kulis tarafında yaşanıyor, başka bir yerde değil.

Küçük takım için ne anlama geliyor?

Burada, bi saniye — Küçük ekipte en büyük kazanç hız mı? Evet, ama sadece o değil. Kodun anlaşılır kalması da hayati çünkü kimsenin büyük çoğunluk sistemi ezbere bilmeye zamanı yok — bugün sen yazarsın, yarın başkası dokunur. Bu gerçeği değiştirmek mümkün değil. Daha fazla bilgi için Chrome CDP ile AI Ajanına Tarayıcı Gücü Vermek: Pratik Kurulum yazımıza bakabilirsiniz.

Bakın, dürüst olmak gerekirse, Birkaç kişilik bir startup’ta bu tarz araçların faydası oldukça bariz hissettiriyor. Daha az tekrar demek daha az hata demek. Ama dürüst olayım — ilk öğrenme eğrisi çok düz de değil, yokmuş gibi davranmayalım. Yeni söz dizimine alışmak gerekiyor ve bu biraz zaman alıyor.

Kurumsal tarafta durum nasıl?

Büyük yapılarda avantaj başka yerden geliyor: standartlaşma ve denetlenebilirlik. Animasyon mantığını tek noktada tutup çıktı üretmek kolay,. Build sürecine yeni bir aşama eklediğiniz için pipeline düzeni bozulmasın diye dikkat etmek gerekiyor — özellikle release zinciri hassassa bu mesele ciddiye alınmalı. Bu konuyla ilgili Gin ile Trafiği Sıraya Dizmek: Room Paketi Ne Sunuyor? yazımıza da göz atmanızı tavsiye ederim.

Garip gelecek ama, Bence burada can alıcı soru şu: ekip bunu gerçekten sürdürecek mi? Kağıt üzerinde süper görünüyor olabilir, ama her geliştiricinin bunu anlaması bekleniyorsa hayal kırıklığı çıkabilir. Evet, söyleyeyim — bazen beklediğiniz kadar pürüzsüz olmuyor.

Nerede İşe Yarar, Nerede Fazla Kaçar?

Ana kullanım alanı belli aslında. Sayı sayan bileşenler, durum gösteren çizgiler, ardışık vurgular, sıralı görsel geçişler… Kısacası tekrar eden bir pattern varsa FSCSS parlıyor.

Ama her şey için mucize beklemeyin derim. Eğer projenizde iki tane basit hover efekti varsa sırf yeni araç diye bunu sisteme sokmak fazla gelebilir. Araç seçerken kolaylık kadar ekosistem desteğine de bakmak lazım — yalnız kalan teknoloji zamanla unutuluyor. Acı ama gerçek bu.

• İyi senaryo: Sayaçlar, progress bar’lar, liste bazlı geçişler — bunu es geçmeyin
• Zayıf senaryo: Çok basit birkaç animasyonlu buton efekti (bu kritik)
• Dikkat edilmesi gereken: Build zincirine ekstra karmaşıklık eklemek — bunu es geçmeyin
• Tatlı nokta: Tekrarlı anahtar karelerin otomasyonu

En Büyük Kazanç Bakım Süresinde Kendini Gösteriyor

Vakit geçtikçe fayda daha iyi anlaşılıyor.

Bir proje ilk gün hızlı görünür. Esas sınav üçüncü ayda başlıyor — kodun içine dönüp baktığınızda ne kadar az satır varsa o kadar mutlu oluyorsunuz. FSCSS’in hikayesi bana tam da bunu hatırlattı. Claude Code’u Kandırmadan GPT-5 Codex’e Yönlendirmek yazımızda da bu konuya değinmiştik.

Bir gün İzmir’de freelance çalışan bir arkadaşım bana ekran görüntüsü attı; toplamda yaklaşık yüz küsur satırlık keyframe bloğunu altıya indirip mantığı dışarı almıştı. “Bunu neden önce keşfetmedim?” dedi. Haklıydı. Çünkü tekrar eden işler genelde ilk başta masum görünür, ama ölçek büyüyünce sessizce can sıkmaya başlar.

Bir de şu var: performans kazanımı doğrudan ölçülmese bile geliştirme deneyimi iyileşiyorsa bu zaten önemli. Geliştiricinin kafasını yormayan araçlar çoğu (söylemesi ayıp) zaman ürüne dolaylı katkı veriyor — hızlı iterasyon sağlıyor, daha az hata çıkarıyor. Ve açık söyleyeyim… bazen yeterince iyi olan şey tam da bu.

Dengeyi Kaçırmadan Kullanmak Gerekiyor

Dur bir saniye, önce şunu söyleyeyim: her yeni aracı projeye atlamak iyi fikir değil.

Bu tarz ön-işleyiciler kulağa hoş geliyor, ama dependency sayısını artırıyor. Derleme süresi uzayabiliyor. Takımdaki herkes aynı konfora sahip olmayabiliyor. İşte tam burada karar verme becerisi devreye giriyor.

Benim önerim şu olurdu: önce gerçekten tekrarlı ve zahmetli kısımlarda deneyin. Sonra build süreci rahat mı bakın. En son ekipten iki kişiyle birlikte okunabilirliği test edin (kendi tecrübem). Yoksa “araç güzel” diye alınmış ama rafta tozlanan uygulamalara dönüşebilir…

Kriter	Cevap evetse FSCSS mantıklı mı?	Neden?
Sık tekrarlanan keyframe var mı?	Evet	Zaman kazandırır.
Ekip yeni söz dizimine açık mı?	Evet / Kısmen	Sürdürülebilirlik artar.
Sadece birkaç basit efekt mi var?	Büyük ihtimalle hayır	Aşırı mühendislik olabilir.
Paket boyutu kritik mi?	Dikkat gerekir	Çıktı şişebilir ama gzip yardımcı olur.

Sıkça Sorulan SorularFSCSS, özellikle CSS keyframe üretimini kolaylaştırmaya odaklanan bir ön-işleyici yaklaşımıdır. Tekrarlı animasyonlarda elle yazma işini azaltmayı hedefler. Sass’ın genel amaçlı yapısından daha dar, daha niş bir alanda çalışır.

FSCSS JavaScript yerine geçer mi?

Her zaman hayır. Basit sayma, listeleme ya da sıralı görsel geçişlerde saf CSS çıktısı sağladığı için JS ihtiyacını azaltabilir ; ama uygulamanın tamamını JS’siz hale getirmez. Karmaşık etkileşimlerde hâlâ JavaScript gerekebilir.

FSCSS performansı düşürür mü?

Kaynak kod tarafında build adımı eklediği için geliştirme akışına ufak bir maliyet getirir. Ama tarayıcıya çıkan sonuç düz CSS olduğu için çalışma anında ekstra JS yükü bindirmez. Doğru kullanımda performans açısından idare eder seviyededir.

Kimler kullanmalı?

Tekrarlı animasyonlarla uğraşan frontend ekipleri, ürün panelleri yapan startup’lar ve bakım maliyetini düşürmek isteyen takımlar için uygun olabilir. Çok küçük projelerde ise öğrenme maliyetine değmeyebilir.

Kaynaklar ve İleri Okuma

FSCSS GitHub deposu (resmi proje araması)

MDN @keyframes Dokümantasyonu

Chrome CDP ile AI Ajanına Tarayıcı Gücü Vermek: Pratik Kurulum

Apache Arrow Neden Önemli : Veri Taşımanın Gizli Vergisi