Tailwind CSS Neden Her Projeye Uygun Değil? Eleştirel Bir Bakış

Önce şeffaf olayım: bu makale Tailwind CSS'i bir araç olarak yok saymıyor. Tailwind'in neden bu kadar popüler olduğunu anlıyorum ve bazı senaryolarda hız kazandırdığını da kabul ediyorum. Ancak frontend ekosisteminde Tailwind, neredeyse tartışılmaz bir "doğru" haline geldi. Her yeni Next.js şablonu, her açık kaynak proje, her YouTube eğitimi Tailwind ile başlıyor. Bu sessiz mutabakata itiraz etmek istiyorum.

Tailwind'i neden kullanmama taraftarı olduğumu, somut teknik gerekçelerle ve gerçek kod örnekleriyle aktaracağım. Siz de aynı fikirde olmayabilirsiniz — bu yazının amacı zaten o tartışmayı başlatmak.

---

Tailwind Nedir ve Neden Bu Kadar Popüler?

Tailwind CSS, "utility-first" yaklaşımını benimseyen bir CSS framework'üdür. Geleneksel CSS'de component odaklı sınıflar yazarsınız (card, navbar, button). Tailwind'de ise her CSS özelliğinin karşılığı olan atomik sınıflar doğrudan HTML üzerinde kullanılır:

<!-- Geleneksel CSS yaklaşımı -->
<div class="card">
  <h2 class="card-title">Başlık</h2>
  <p class="card-body">İçerik</p>
</div>

<!-- Tailwind yaklaşımı -->
<div class="bg-white rounded-xl shadow-md p-6 flex flex-col gap-4">
  <h2 class="text-xl font-semibold text-gray-900 leading-tight">Başlık</h2>
  <p class="text-sm text-gray-600 leading-relaxed">İçerik</p>
</div>

Popülerliğinin arkasında gerçek sebepler var: dosyalar arası geçiş yapmadan stil yazabiliyorsunuz, CSS dosyası büyümüyor, tasarım token'larını (spacing, color, typography) merkezi olarak yönetebiliyorsunuz. Bu faydalar küçümsenecek şeyler değil.

Ama işte bu faydaların gizlediği bir bedel var.

---

Sorun 1: HTML Okunaksız Hale Geliyor

Tailwind'in en çok dile getirilen eleştirisi budur ve hâlâ geçerliliğini korumaktadır. Gerçek dünya bileşenlerinde class listeleri kolayca kontrolden çıkar:

<!-- Gerçek bir Tailwind butonu — bu "temiz" sayılır -->
<button class="inline-flex items-center justify-center rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:opacity-50 disabled:pointer-events-none ring-offset-background bg-primary text-primary-foreground hover:bg-primary/90 h-10 py-2 px-4">
  Gönder
</button>

Bu bir buton. Tek bir buton. 13 sınıf, tek satır, 280 karakter. Şimdi bu bileşenin yanına bir input, bir label ve bir form wrapper ekleyin — HTML dosyanız gerçek anlamda okunamaz hale gelir.

Buna karşı sık verilen yanıt şudur: "Zaten component'a çekiyorsunuz, React/Vue/Svelte ile tekrar etmiyorsunuz." Bu doğru, ama soruyu çözmüyor — sadece gizliyor. Component içinde hâlâ aynı karmaşıklık var; sadece onu izole ettiniz.

Karşılaştırın:

/* button.css */
.btn-primary {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  border-radius: 6px;
  font-size: 0.875rem;
  font-weight: 500;
  padding: 0.5rem 1rem;
  background-color: var(--color-primary);
  color: white;
  transition: background-color 0.2s;
}

.btn-primary:hover {
  background-color: var(--color-primary-dark);
}

.btn-primary:disabled {
  opacity: 0.5;
  pointer-events: none;
}

// Button.jsx
export function Button({ children, ...props }) {
  return (
    <button className="btn-primary" {...props}>
      {children}
    </button>
  )
}

İkinci yaklaşımda HTML temiz, CSS okunabilir, sorumluluklar ayrı. Bir tasarımcı CSS dosyasını açıp doğrudan değişiklik yapabilir. Bir backend geliştirici JSX'e baktığında neyin ne işe yaradığını anlayabilir.

---

Sorun 2: Aslında Hâlâ CSS Öğrenmek Zorundasınız

Tailwind'in pazarlama söylemlerinden biri, CSS'i soyutlayarak kolaylaştırdığıdır. Bu yanıltıcı. Tailwind'i iyi kullanmak için CSS'i zaten bilmeniz gerekiyor.

flex ne işe yarar? items-center ile justify-center arasındaki fark nedir? z-10 yeterli mi yoksa z-50 mi gerekiyor? overflow-hidden neden elipsis için tek başına yetmiyor? min-w-0 neden flex child'a eklemek gerekiyor?

Bunların hepsini bilmeden Tailwind'i etkili kullanamazsınız. Peki bu soruların cevaplarını biliyorsanız, CSS yazmak zaten o kadar da zor değil demektir. Tailwind bu öğrenme yükünü kaldırmıyor — üstüne bir de kendi sözdizimini öğrenmek zorunda kalıyorsunuz.

Yeni başlayan bir geliştirici için durum daha da kötü: CSS'i öğrenmek yerine Tailwind sınıflarını ezberliyor, ama flex-col neden işe yaradığını anlamıyor. Bu, soyutlamanın doğru yönde çalışmaması demektir.

---

Sorun 3: Tasarım Tutarlılığı Yanıltıcı Bir Güvence Veriyor

Tailwind'in tailwind.config.js dosyası ile merkezi bir tasarım sistemi kurabileceğiniz söylenir. Spacing, renk paleti, tipografi — hepsi tek yerden yönetilir. Bu kulağa harika geliyor, ama pratikte ne oluyor?

// tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: '#3B82F6',
        // Ama bir süre sonra...
      }
    }
  }
}

Zamanla şunları görmeye başlarsınız:

<!-- Onaylı primary renk -->
<div class="bg-primary">...</div>

<!-- Birisi aceleyle ekledi -->
<div class="bg-blue-500">...</div>

<!-- Başka biri "neredeyse aynı" dedi -->
<div style="background: #3B82F6">...</div>

<!-- Özel değer, neden var kim bilir -->
<div class="bg-[#3b84f8]">...</div>

Tailwind'in arbitrary value sözdizimi (bg-[#3b84f8], w-[327px], mt-[13px]) tam anlamıyla kaçış kapısıdır. Tasarım token sistemini tek satırda çiğnemenizi sağlar. Ve bu kötüye kullanım çok hızlı yayılır çünkü sürtünme sıfırdır — sadece köşeli parantez açıyorsunuz.

CSS custom property'leri ve CSS Modules ile kurulmuş bir sistemde bu tür bir sapma çok daha görünürdür ve code review'da kolayca yakalanır.

---

Sorun 4: Responsive ve State Varyantları Cehennemi

Tailwind, responsive tasarımı ve hover/focus/active gibi state'leri prefix sözdizimi ile yönetir:

<div class="
  w-full
  sm:w-1/2
  md:w-1/3
  lg:w-1/4
  xl:w-1/5
  bg-white
  hover:bg-gray-50
  focus:bg-gray-100
  dark:bg-gray-800
  dark:hover:bg-gray-700
  dark:focus:bg-gray-600
  group-hover:opacity-100
  transition-all
  duration-200
  ease-in-out
">

Bu bir div. Responsive, dark mode ve group-hover destekli, geçişli bir div. 15 sınıf. Gerçek projelerde bundan çok daha karmaşık durumlarla karşılaşırsınız.

CSS'te aynı şey:

.panel {
  width: 100%;
  background: white;
  transition: all 0.2s ease-in-out;
}

.panel:hover { background: #f9fafb; }
.panel:focus { background: #f3f4f6; }

@media (min-width: 640px)  { .panel { width: 50%; } }
@media (min-width: 768px)  { .panel { width: 33.333%; } }
@media (min-width: 1024px) { .panel { width: 25%; } }
@media (min-width: 1280px) { .panel { width: 20%; } }

@media (prefers-color-scheme: dark) {
  .panel { background: #1f2937; }
  .panel:hover { background: #374151; }
}

CSS versiyonu daha uzun, ama her şey kendi yerinde. Medya sorguları bir arada, dark mode bir arada, hover state bir arada. Zihinsel model dağılmıyor.

---

Sorun 5: "Gerçek CSS" Yazmayı Unutturur

Bu daha çok uzun vadeli bir kariyer ve ekip dinamiği sorunudur. Tailwind ile uzun süre çalışan geliştiriciler CSS'e dönmekte zorlanıyor. flex-col yazıyor ama flex-direction: column'u hatırlamıyor. tracking-wide biliyor ama letter-spacing'i bilmiyor.

Tailwind kullanan bir projeden vanilla CSS veya CSS Modules kullanan bir projeye geçtiğinizde sarsıcı bir alışkanlık boşluğuyla karşılaşabilirsiniz. Üstüne bir de şu gerçeği ekleyin: Tailwind, CSS standardının üzerine oturur ve CSS standartları değişmeye devam eder. Container queries, @layer, :has(), subgrid — bunlar giderek daha önemli hale geliyor. Tailwind bu özellikleri er ya da geç destekliyor, ama öğrenme önce CSS özelliğini değil Tailwind sözdizimini öğrenmek şeklinde oluyor.

---

Sorun 6: Takım Çalışmasında Yük Dağılımı

Frontend ve backend geliştiricilerin birlikte çalıştığı ekiplerde ya da tasarımcıların doğrudan kod ürettiği ortamlarda Tailwind bir engel haline gelebilir.

Bir backend geliştirici bir şablona ufak bir stil değişikliği yapmak istediğinde, CSS ile bunu anlayabilir. Tailwind ile önce hangi sınıfın neyi ifade ettiğini çözmesi gerekir. space-y-4 nedir? ring-offset-2 ne işe yarar? prose sınıfı neden tüm stilleri değiştirdi?

Tasarımcılar için durum daha da sancılıdır. Figma'dan CSS'e geçiş nispeten düz bir çizgidir. Figma'dan Tailwind sınıflarına geçiş için ya bir eklenti ya da Tailwind'i bilen birinin aracılık etmesi gerekir.

---

Peki Alternatifler Neler?

Tailwind'e hayır dediğinizde elimiz boş kalmıyor. Olgun ve iyi düşünülmüş alternatifler mevcut:

CSS Modules, React ve Next.js ekosisteminde kutudan çıktığı gibi desteklenir. Her component kendi .module.css dosyasına sahiptir, sınıf isimleri otomatik olarak scoped olur, global çakışma yaşanmaz:

// Button.module.css
.button { ... }
.button:hover { ... }

// Button.jsx
import styles from './Button.module.css'
export function Button({ children }) {
  return <button className={styles.button}>{children}</button>
}

CSS custom properties ile tasarım token sistemi kurmak Tailwind'e göre daha az araç bağımlısıdır:

:root {
  --color-primary: #3b82f6;
  --spacing-md: 1rem;
  --radius-lg: 0.75rem;
}

.card {
  padding: var(--spacing-md);
  border-radius: var(--radius-lg);
  background: white;
}

Vanilla Extract veya Linaria gibi zero-runtime CSS-in-JS çözümleri, CSS'i TypeScript içinde yazmanızı sağlarken build time'da gerçek CSS üretir. Tailwind'in type güvenliği olmasa da makul bir alternatif sunarlar.

Open Props ise CSS custom property tabanlı bir tasarım token kütüphanesidir. Tailwind'in renk ve spacing sistemi gibi çalışır ama native CSS üzerinde, hiçbir derleme adımı olmadan.

---

Ne Zaman Tailwind Mantıklı Olabilir?

Şeffaflık adına bunu da söylemek gerekiyor: bazı bağlamlar Tailwind için gerçekten uygun.

Hızlı prototipleme aşamasında CSS dosyaları açmadan doğrudan HTML'de görsel çıktı almanın verdiği hız değerlidir. Tek başına çalışan bir geliştirici, küçük bir SaaS side project kurarken Tailwind'in getirdiği tasarım token sistemini ve hızı tercih edebilir.

Tailwind ekosisteminde hazır UI kütüphaneleri (shadcn/ui, Headless UI, Radix ile birlikte) gerçekten kaliteli ve Tailwind olmadan bu bileşenleri kullanmak daha çok efor gerektirir.

Ama bunlar belirli, sınırlı senaryolardır. "Her Next.js projesine varsayılan olarak Tailwind" yaklaşımı bu senaryolardan çok daha geniş bir alanı kapsıyor — ve bu varsayılan benim karşı çıktığım şey.

---

Sonuç: Araç Değil, Varsayılan Olmasına İtiraz

Tailwind CSS kötü bir araç değil. Ama her araç gibi, doğru problem için doğru bağlamda kullanılmalı.

Benim itirazım Tailwind'e değil, Tailwind'in düşünülmeden seçilen varsayılan haline gelmesine. HTML'yi sınıf listesine boğan, CSS öğrenme sürecini bypass eden, takım çalışmasını zorlaştıran ve uzun vadede bakım maliyetini artıran bu yaklaşımın, her projede "zaten herkes kullanıyor" gerekçesiyle seçilmesine.

Bir sonraki projenizde şu soruyu kendinize sorun: Tailwind'i kullanmayı seçiyor musunuz, yoksa sadece varsayılan olduğu için mi kullanıyorsunuz? Eğer cevap ikincisiyse, CSS Modules ve custom property tabanlı bir tasarım token sistemiyle başlamayı deneyin. Sonuçlardan memnun kalacağınızı düşünüyorum.