Tailwind CSS v4.0 yayınlandı

 (tailwindcss.com)
1 puan yazan GN⁺ 2025-01-24 | 1 yorum | WhatsApp'ta paylaş
  • Tailwind CSS v4.0, framework’ün baştan yazıldığı bir sürüm; build performansını önemli ölçüde artırıyor ve ayar/özelleştirme akışını CSS merkezli hale getiriyor
  • Catalyst ölçütüne göre tam build, v3.4’teki 378 ms’den v4.0’da 100 ms’ye inerek 3,78 kat hızlandı; yeni CSS olmayan incremental build ise 35 ms’den 192 µs’ye düşerek 182 kat iyileşti
  • Kurulum, tek satırlık @import "tailwindcss" ve sıfır yapılandırma varsayılanlarıyla sadeleşti; Vite kullanıcıları PostCSS yerine @tailwindcss/vite kullanabiliyor
  • v4.0; cascade layers, @property, color-mix(), logical properties gibi modern CSS özelliklerinden yararlanıyor ve otomatik içerik algılama ile yerleşik @import işleme getiriyor
  • Container query’ler, 3D transform, genişletilmiş gradient API’si, @starting-style, not-*, field-sizing, color-scheme, inert gibi özellikler çekirdek işlevlere dahil edilerek ayrı eklenti bağımlılığı azaltılıyor

Baştan yazılmış yüksek performanslı motor

  • Tailwind CSS v4.0, yıllara dayanan mimari deneyime dayanarak framework’ün baştan yeniden yazıldığı bir sürüm
  • Kendi proje benchmark’larında tam rebuild 3,5 kattan fazla, incremental build 8 kattan fazla hızlandı
  • Catalyst ölçütüne göre medyan build süreleri şöyle
    • Tam build: v3.4 378 ms → v4.0 100 ms, 3,78 kat iyileşme
    • Yeni CSS içeren incremental rebuild: 44 ms → 5 ms, 8,8 kat iyileşme
    • Yeni CSS içermeyen incremental rebuild: 35 ms → 192 µs, 182 kat iyileşme
  • Yeni CSS derlemeyi gerektirmeyen incremental build’ler 100 kattan fazla hızlanarak mikrosaniye düzeyinde tamamlanıyor
    • Bir projede ne kadar uzun çalışırsanız, flex, col-span-2, font-bold gibi zaten kullanılmış sınıfları tekrar yazma olasılığınız o kadar artıyor; bu yüzden bu tür build’lerle sık karşılaşılıyor

Modern CSS platformundan yararlanma

  • v4.0, Tailwind CSS v3.0’dan bu yana gelişen web platformu özelliklerinden aktif biçimde yararlanıyor
  • Başlıca temel CSS özellikleri şunlar
    • Native cascade layers: Farklı stil kurallarının birbiriyle nasıl etkileşime girdiğini daha ayrıntılı denetler
    • Registered custom properties: Gradient animasyonlarını mümkün kılar ve büyük sayfalarda performansı önemli ölçüde artırır
    • color-mix(): CSS değişkenleri ve currentColor dahil tüm renk değerlerinin opaklığını ayarlayabilir
    • Logical properties: RTL desteğini basitleştirir ve üretilen CSS boyutunu azaltır
  • Bu özellikler Tailwind’in iç uygulamasını da sadeleştirerek hata yüzeyini azaltır ve bakımı kolaylaştırır

Kurulum ve build entegrasyonunun sadeleşmesi

  • Kurulum akışı, adımları ve boilerplate’i azaltacak şekilde düzenlendi
    • npm i tailwindcss @tailwindcss/postcss
    • PostCSS eklentisine @tailwindcss/postcss ekleme
    • CSS dosyasında @import "tailwindcss" kullanma
  • v4.0’da @tailwind direktifleri yerine tek satır CSS ile Tailwind’i içe aktarıp kullanabilirsiniz
  • Şablon dosyası yolları dahil hiçbir ayar yapmadan başlayabileceğiniz sıfır yapılandırma akışı sunar
  • Ayrı bir harici eklenti olmadan @import kurallarını bundle eder; vendor prefixing ve modern söz dizimi dönüşümü için içeride Lightning CSS kullanır
  • Vite kullanıcıları PostCSS yerine @tailwindcss/vite seçebilir
    • Tailwind CSS v4.0 PostCSS eklentisi olarak da hızlıdır, ancak Vite eklentisi kullanıldığında daha iyi performans elde edilebilir

Otomatik içerik algılama ve yerleşik import

  • v3’te gerekli olan content dizisi ayarı, v4.0’daki otomatik algılama sezgisel kurallarıyla değiştirildi
  • .gitignore içindeki öğeler otomatik olarak yok sayılır; böylece bağımlılıklar veya versiyon kontrolünde olmayan üretilmiş dosyalar taranmaz
    • Örn: /node_modules, /coverage, /.next, /build
  • Görseller, videolar, .zip gibi binary uzantılar da otomatik olarak yok sayılır
  • Varsayılan olarak hariç tutulan kaynakları açıkça eklemek gerektiğinde CSS dosyası içinde @source direktifi kullanılabilir
    • @source "../node_modules/@my-company/ui-lib";
    • @source da aynı sezgisel kuralları kullandığından binary dosya tipleri, ayrıca uzantı belirtmeden hariç tutulur
  • v4.0’dan önce başka CSS dosyalarını @import ile inline etmek için postcss-import gibi ayrı bir eklenti gerekiyordu; artık yerleşik import desteği sayesinde başka araca gerek yok
    • Import sistemi Tailwind CSS’e özel olarak geliştirildi ve motorla sıkı entegre olduğundan daha hızlı çalışıyor

CSS-first yapılandırma ve theme variables

  • v4.0’daki büyük değişikliklerden biri, proje yapılandırmasının JavaScript yerine doğrudan CSS içinde yapılması
  • tailwind.config.js dosyası yerine, Tailwind’i import eden CSS dosyası içinde @theme kullanarak özelleştirme yapılabilir
    • Design token ayarları
    • Özel utility tanımlama
    • Özel variant tanımlama
  • @theme içinde tanımlanan design token’lar varsayılan olarak CSS değişkenleri olarak dışa açılır
    • Örn: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • Bu şekilde oluşturulan CSS değişkenleri runtime’da normal CSS olarak referans verilebilir
    • Inline style yeniden kullanımı
    • Animasyon işleme için Motion gibi kütüphanelere aktarma

Dinamik utility değerleri ve variant’lar

  • v4.0, birçok utility ve variant’ın belirli arbitrary değerleri ayar gerektirmeden almasını sağlayarak sadeleşti
  • Grid’de ayrı bir ayar olmadan istenen boyut kullanılabilir
    • Örn: grid grid-cols-15
  • Özel boolean data attribute’lar da önceden tanımlanmadan hedeflenebilir
    • Örn: data-current:opacity-100
  • px-*, mt-*, w-*, h-* gibi spacing utility’leri tek bir spacing scale değişkeninden dinamik olarak türetilir
    • Örn: --spacing: 0.25rem
    • w-17, calc(var(--spacing) * 17) biçiminde üretilir
  • v4.0 ile birlikte gelen yükseltme aracı, artık gerekli olmayan arbitrary value söz dizimini tespit ettiğinde çoğunlukla otomatik olarak sadeleştirir

Renk paleti ve container query’ler

  • Varsayılan renk paletinin tamamı rgb’den oklch’ye yükseltildi
    • sRGB renk uzayının sınırlarının ötesine geçerek daha geniş gamut’tan yararlanır ve renkleri daha canlı hale getirir
    • v3 ile renkler arasındaki denge korunmaya çalışıldığı için mevcut projeler yükseltilirken breaking change gibi hissedilmemeli
  • Container query desteği v4.0’da çekirdeğe alındı; @tailwindcss/container-queries eklentisine artık gerek yok
  • Yeni @max-* variant’ı ile max-width container query kullanılabilir
  • Normal breakpoint variant’larında olduğu gibi @min-* ve @max-* üst üste konularak container query aralığı tanımlanabilir

3D transform ve gradient API genişlemesi

  • v4.0, 3D transform için API ekliyor
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • Gradient işlevleri de genişletildi; özel CSS yazmadan daha çeşitli efektler oluşturulabilir
  • Linear gradient’ler açıları değer olarak alabilir
    • Örn: bg-linear-45
    • Mevcut bg-gradient-*, bg-linear-* olarak yeniden adlandırıldı
  • Gradient renk enterpolasyon modu modifier ile denetlenebilir
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • v4.0’da varsayılan enterpolasyon OKLAB’dir; başka renk uzayı modifier’ları da kullanılabilir
  • Yeni bg-conic-*, bg-radial-* utility’leriyle conic ve radial gradient oluşturulabilir
    • Mevcut from-*, via-*, to-* ile birlikte çalışır
    • Renk enterpolasyonu yöntemi ayarı modifier’ları ve gradient konumu gibi ayrıntılı kontroller için arbitrary value desteği içerir

Yeni variant’lar ve utility’ler

  • Yeni starting variant’ı CSS @starting-style desteği sunar
    • Bir öğe ilk kez gösterildiğinde özellik transition’ı oluşturabilir
    • Sayfada beliren öğeleri JavaScript olmadan animasyonlu hale getirebilir
    • Tarayıcı desteği henüz çoğu ekip için yeterli olmayabilir, ancak yaklaşıyor
  • Yeni not-* variant’ı CSS :not() pseudo-class’ını destekler
    • Örn: not-hover:opacity-75
    • Media query ve @supports query’leri de olumsuzlanabilir
  • v4.0’da şu utility ve variant’lar da eklendi
    • inset-shadow-*, inset-ring-*: Tek bir öğede en fazla 4 box shadow katmanı üst üste bindirilebilir
    • field-sizing: JavaScript olmadan textarea’nın otomatik boyutlandırılmasını destekler
    • color-scheme: Dark mode’da açık renk scrollbar’ı kaldırabilir
    • font-stretch: Farklı genişlikleri destekleyen variable font’ları ayarlar
    • inert: inert özelliğiyle işaretlenmiş etkileşimsiz öğeleri stillendirir
    • nth-*: nth ailesi stillendirmeyi destekler
    • in-*: group sınıfı olmadan group-* benzeri çalışır
    • :popover-open: Mevcut open variant’ı ile açık popover’ları da hedefler
    • descendant variant: Tüm alt öğeleri stillendirir

Başlama ve yükseltme yolu

İlgili okumalar

1 yorum

 
GN⁺ 2025-01-24
Hacker News yorumları

  • Bir zamanlar Tailwind’in çeşitli kusurlarını ve modern “saf” web yaklaşımlarıyla fiili uyumsuzluğunu sert biçimde eleştirmiştim, ancak v4’teki büyük ilerleme çok sevindirici
    Tailwind temasına yerel CSS değişkenleri olarak erişilebilmesi ve dokümantasyonda harici bir stil sayfasında yerel değişkenlerle yazılmış bir düğme bileşeni örneğinin bile bulunması muazzam bir değişim
    Yalnızca CSS ile yapılandırılabilmesi de harika; artık Tailwind, makul mimarileri yutan JavaScript tarzı “viral” bir framework değil, herhangi bir projeye eklenebilecek bir utility gibi hissettiriyor
    Son birkaç yıldaki eleştiriler etkili olduysa da, kendileri iyi bir sonuca ulaştıysa da, Tailwind lehine/aleyhine tartışmaların önemli bir kısmı artık daha az ilgili görünüyor; bu çok iyi bir şey. Artık ürün geliştirmeye odaklanabiliriz

    • Pratikte kullanımı konusunda hâlâ eleştirelim, ama Tailwind’in yapay zeka tarafından üretilen iş akışlarına bu kadar iyi uyması şaşırtıcı
      Her şeyi sistematik biçimde ifade edebildiği için gerçekten iyi çalışıyor ve bunda son derece yararlı bir şey var
    • Tailwind lehine/aleyhine tartışmaların artık ilgisiz olduğu görüşüne katılmak zor; bir tasarımcı/tasarım mühendisi olarak iki sorun görüyorum
      Birincisi, JavaScript/Tailwind mühendisleri tasarım tartışmalarını ele geçirdi. “Utility-first”, “kullanılmayan kodu kaldırma”, “tip güvenli CSS” yerine tasarım sistemlerine; örneğin tipografide Perfect Fifth mi yoksa Perfect Fourth mü kullanılacağı gibi konulara daha fazla odaklanıyorum
      İkincisi, Tailwind gerçek üretim sürecine katılmayı zorlaştırıyor. Tasarım kararları flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)] gibi anlaşılması güç React bileşeni ifadelerinin içine gömülüyor
      JavaScript mühendisi için anlaşılabilir olabilir, ancak sistematik tasarım için bir engel oluşturuyor. CSS ile hassas matematiksel ilişkiler ifade etmek yerine, daha kolay olan inline style kullanılmış oluyor
    • Tailwind CSS’in yalnızca renk paletini istiyorum

  • CSS eskisine göre çok daha kolay kullanılır hale geldi ve çoğu tarayıcı da artık tutarlı davranıyor
    Build adımı gerektirmediği ve markup’ı aşırı kodla kirletmediği için öğrenmeye değer
    HTML içinde doğrudan style özniteliğini de kullanabilirsiniz; eskiden ilgi alanlarının ayrılması için bundan kaçınılırdı. Bu yüzden benzer bir yaklaşımı neden yeniden getirmek istediklerini merak ediyorum. Sanki sadece birkaç karakter azaltmak içinmiş gibi geliyor
    style özniteliği, kodu kafanızda dönüştürmenizi de gerektirmediğinden aksine daha sezgisel görünüyor. Cazibesini pek anlayamıyorum

    • style özniteliğiyle yapılamayan epey şey var. Örneğin sözde sınıflar :hover, :focus, sözde öğeler ::before, ::after, medya sorguları, keyframe’ler ve animasyonlar
      Büyük projelerde geliştirici deneyimi de iyi değil
      Öte yandan yakında standart olacak @scope, stilleri yakın bir yere yerleştirmek için iyi bir ek özellik: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Günümüzde Tailwind, CSS sınıfları yerine bir soyutlama katmanı görevi gören bileşen soyutlama sistemiyle sıkça birlikte kullanılıyor
      Bileşen soyutlaması, anlam ile stili daha güçlü biçimde ayırır. Her iki durumda da “hero” soyutlamasını bulmanız gerekir, ancak bileşen dünyasında yalnızca stil değil, HTML etiket adı bile soyutlanır
      Her iki şekilde de “stil ayrıntıları”, sayfa kaynak dosyası olan “içerikten” ayrılmıştır. İlgi alanlarının ayrılması, yani içerik ile sunumun daha iyi ayrılması için build adımına katlanılabilir
    • Cazibesi, CSS sınıf adı vermek zorunda kalmamanızda, HTML ile yan yana olduğu için okunmasının kolay olmasında ve adlandırma biçiminin standartlaşarak her yerde aynı kuralları kullanmasında yatıyor
      Ayrı dosyalar yönetme ve kullanılmayan bileşenleri kaldırma ihtiyacı da azalıyor
      style etiketiyle yapılamayan medya sorgularını kullanabiliyorsunuz ve başka yerlerde kullanılan sınıfları bozma riskiniz de olmuyor. CSS’in global scope’u avantajlı olsa da risklidir
    • Bu, React ile güçlü bağın fazlasıyla kanıksanmasının sonucu
      Stillerin tasarım sistemine değil, bileşenlere ait olduğu düşünülüyor. JavaScript öncelikli mühendislik ekosisteminin, modern CSS’in ve sistematik tasarımın gücünü bilen tasarım odaklı şirketlere daha çok ihtiyacı var
    • Büyük projelerde uğraşılması gereken dosya sayısına bakınca Tailwind oldukça cazip görünüyor
      Klasik .css yaklaşımı garip adlar, tekrarlar ve çakışma olasılığı doğuruyor. css modules da bir seçenek olabilir, ama bileşen/sayfa başına dosya sayısını fiilen ikiye katlıyor
      sass veya less, css modules ile klasik .css yaklaşımının sorunlarını bir araya getiriyormuş gibi hissettiriyor
      Tailwind’i özünde seviyor ya da sevmiyor değilim; başta ondan hiç hoşlanmamıştım, ancak bileşenler ve sayfalardan oluşan 200’den fazla dosyalı bir projede değerini hissediyorum

  • Tailwind’e ilk tepkim “uğraştırıcı” olduğuydu. CSS’i zaten biliyordum; şimdi CSS’i yeniden öğrenmem gerekiyormuş gibi hissettirdi.
    Bu, bir ebeveynin çocuğuna matematik ödevinde yardım etmeye çalışırken okulda öğretilen yöntemin eskisinden tamamen farklı olduğunu görmesine benziyor: kendi çözüm yöntemi hâlâ doğru ama kabul görmüyor, çocuk da iki sistemi bağdaştırmaya çalışırken sinirleniyor.
    Ekipte iyi çalıştığı ve iyi ölçeklendiği için “kullanmak gerek” havasını anlıyorum, bunu deneyimledim de.
    Yine de sınıfları veya etiketleri hedefleyen sıradan stil sayfalarını hâlâ daha çok seviyorum. Özellikle CSS artık iç içe seçicileri desteklediği için bu daha da geçerli.
    Stil sayfası yönetimi sorunu var; Remix/React Router’daki gibi rota düzeyinde CSS dosyaları tanımlayıp uygulama yaklaşımını seviyorum. Bu yetmezse veya dinamik stiller .css dosyasında fazla karmaşık hâle gelirse style={{...}} de her zaman mümkün.
    CSS güçlü, esnek ve ölçeklenebilir; bu yüzden Tailwind bir iyileştirme değil, bir kısıtlama gibi geliyor. Neden bu kadar popüler kalmaya devam ettiğini pek bilmiyorum ama 3-4 yıl sonra herkesin yine başka bir şeye geçmiş olacağını düşünüyorum.

    • Başta CSS’i yeniden öğreniyormuşum gibi hissetmek can sıkıcıydı ve eskiden ben de aynı argümanı savunurdum.
      Ama Tailwind kullanan açık kaynak projelere katkı verdikçe alıştım ve şimdi farklı hissediyorum.
      Tailwind özünde style={{…}} için bir kestirme yazım gibi. .css dosyasıyla veya stil nesnesiyle birkaç satır gerektiren şeyi tek bir utility yaklaşık 15 karakterle bitiriyor.
      “visual text replacement css” gibi şeyler arama ya da CSS cheat sheet’lerine, 8 yıl önceki CSS-Tricks yazılarına bakma sürem ciddi ölçüde azaldı. Bunun yerine sürekli Tailwind dokümantasyonuna bakıp istediğim işi yapan utility class’ı hızla buluyorum.
      Şaşırtıcı derecede çok şey zihinsel önbelleğe yerleşiyor ve layout işi için gereken tüm CSS’i ezberlemeye çalışmaktan çok daha iyi hissettiriyor.
    • Bence bunun nedeni artık bileşenin tamamının tek dosya içinde yer alması.
      Ayrı olarak CSS’e dokunmaya gerek kalmıyor; stil, uygulandığı öğenin hemen üzerinde olduğu için ikisini karşılaştırmak gerekmiyor.
      Bunu yalnızca css özelliğiyle yapmak da mümkün aslında; ama sorun şu ki herkes bunun yanlış yöntem olduğunu öğrenerek geldi. Ayrıca birden çok utility içeren bir string listesi, saf CSS nesnesi kullanmaktan daha kolay olabiliyor.
    • Kısıtlamalar mümkün olan karmaşıklığı azaltır; Tailwind’in kazanmasının nedeni de bu.
      Devasa ve karmaşık bir sistemin üzerine konmuş birleştirilebilir, standartlaştırılmış modüler bir sarmalayıcı olduğu için büyük bir ilerleme.
    • Çocuğumla matematik öğreniyorum; benim öğrendiğimden farklı değil ve hâlâ hızlıca çözebiliyorum.
      Buna karşılık sosyal medyada çarpma ile bölmeyi birbirine karıştırıp tek bir doğru cevap var diyen gönderiler var. Tailwind o kadar kötü değil ama yaşlı biri olarak bana o yöne daha yakın görünüyor.

  • Tailwind’i seviyorum. Son 4 yılda 3 projede kullandım; sezgiseldi, dokümantasyonu iyiydi ve basitti.
    Projedeki stillenmiş her div için isim vermek zorunda olduğumuz emotion ve styled-components günlerini özlemiyorum.
    Tailwind’de container sadece bir div ve birkaç class’tan ibaret. İsimlendirme tartışmaları azalıyor; isim bulmaya harcanan zihinsel enerji ve inceleme zamanı da azalıyor.

    • Her styled div için isim düşünmek gerektiği sorununun sıkça dile getirilmesine biraz şaşırıyorum.
      Bir şeye isim verirken 1 saniyeden fazla düşündüğümü neredeyse hiç hatırlamıyorum. Gerçekten bazı insanlar için takıldıkları nokta bu mu? Hakikaten orada kilitlenme yaratacak kadar mı merak ediyorum.
    • “Birkaç class” diyorsanız çok iyi bir ürün sorumlusuyla çalışıyor olmalısınız.
      Benim karşılaştığım kişiler mümkün olan her ayrıntıyı durmadan belirtirdi. Web formunu kendi kişisel HGTV tadilatları gibi ele alırlardı.
      Tailwind’i bir kez denediğimde class’lar markup’tan en az bir basamak daha fazla hâle geldi ve kısa sürede okunması zorlaştı.
    • Birkaç projede denedim ama sevmedim. Büyük projelerde hızla dağınıklaşıyor ve yeni Bootstrap gibi hissettiriyor.
      Şu anda CSS-in-JS iş akışından memnunum. LLM yardımıyla eski usul CSS yazma yöntemi. LLM’e bir görsel gösterip bileşen istediğinizde uygun isimler verilmiş hâlde doğrudan çıkıyor.
    • Seçme şansım varsa React’ten kaçınmamın başlıca nedenlerinden biri bu.
      React’te styling pek iyi değil; Tailwind kullansanız bile sadece nispeten daha az kötü bir seçenek.
      Bir frontend framework’ü ve build adımı kullanacaksanız, kullanım amacına göre Svelte ve Astro iyi. Sıradan CSS ile stil verebilirsiniz; bileşenleri küçük tutarsanız class isimlerini neredeyse hiç kullanmanız gerekmez.
      Öğeler için seçici kullanıp framework’ün build sırasında stilleri scope’lamasını sağlayabilirsiniz.

  • Kendi sitemde Tailwind’i denedim ve oldukça sevdim; ama nedeni yaygın söylenenlerden biraz farklı olabilir.
    Tailwind’in gerçek değeri, bir öğeyi etkileyen tüm stilleri tek bir yerde okuyabilmek.
    Class isimleri uzayabilir ama tarayıcı geliştirici araçlarını her seferinde açmaktan veya bir ya da daha fazla stil sayfasında aşağı yukarı dolaşmaktan uzun tek bir satırı okumak çok daha hızlı.
    Sonradan o koda döndüğümde başka bir öğeyi değiştireceğim diye endişelenmeden güvenle düzenleme yapabiliyorum.
    CSS’in cascade yapısı hâlâ yararlı, ama genelde stili tek bir öğeyle sınırlamak istiyorum. Geri kalanında CSS’e dönüyorum; fakat gerçekte yazdığım CSS çok az. Çünkü çoğu zaman sadece boşlukları ayarlamak istiyorum.

    • Tailwind’in iyi ve rahat olmasının nedeni bence tam da bu.
      “X’i nasıl yaparım?” sorusunun 30 dakikalık bir araştırma işine değil, hızlı bir dokümantasyon aramasına dönüşmesi de hoşuma gidiyor.
    • Bir öğeye uygulanmış tüm stilleri gösteren araçlar IDE’lerde de var. Örneğin IntelliJ’deki “Show Applied Styles for Tag” ya da Chrome geliştirici araçları da bunu okunaklı biçimde gösteriyor.
      Bu HN yazısındaki Tailwind parçaları bunlarla karşılaştırınca epey korkutucu görünüyor.
    • Bir ölçüde katılıyorum ama aynı sorun devam ediyor.
      Bir dive text-xl eklediğinizde ve içinde iç içe geçmiş div ile span varsa hepsi text-xl’ı miras alır; bu yüzden iç içe öğelerde text-xl’a neyin yol açtığını görmek için sonunda yine öğe hiyerarşisinde yukarı çıkmanız gerekir.
      Yine de genel olarak biraz daha kolay.

  • “Derleme süresinin kısalması”, “artık @tailwind yönergesi yok”, “JavaScript yapılandırması yok”, “modern web için tasarlandı” gibi ifadeler kulağa şöyle geliyor:
    CSS artık bizim elle yaptığımız her şeyi yapabiliyor, ama yine de bize hâlâ ihtiyaç varmış gibi davranmaya devam edelim havası var

    • Nefret edecekseniz bile en azından bunun ne olduğunu ve insanların neden kullandığını anlamaya çalışmalısınız
    • Tailwind’in satış vaadi en başından beri “neredeyse inline CSS, ama style özniteliğinden daha az zahmetli ve optimize etmesi çok daha kolay”dı
    • Eskiden normal CSS ile yapılamadığı için Tailwind’e ihtiyaç duyulan şey neydi, merak ediyorum
      Tailwind neredeyse CSS ile bire bir eşleşmiyor mu?
    • Bunu gerçekten böyle mi anladınız, emin değilim
      Tailwind’i sevmemenizi anlarım, ama saman adam kurup saldırmak yerine Tailwind’in hangi yönünü sevmediğinizi söylemek daha iyi olur bence
      Başkasının açık kaynak projesini ve onu faydalı bulan insanları küçümsemek de hoş değil

  • CSS’i iyi bilenlere sormak istiyorum. Ben pek bilmiyorum
    Kişisel Phoenix projemi 1.7’ye yükseltiyorum ve Phoenix artık varsayılan olarak Tailwind kullandığı için Bootstrap yerine onu denemek istedim
    Şimdiye kadar Bootstrap sürümü “fena değil” görünüyordu, ama Tailwind sürümü darmadağın görünüyor
    Tasarımcı olmaya çalışmadan iyi görünen varsayılanlar elde etmenin en kolay yolu nedir? Yoksa sadece Bootstrap’i geri kurup geçmeli miyim?

    • Bu durumda Bootstrap’i geri kurardım
      Tailwind, tasarımı kontrol etmek istediğinizde size araçlar verir, ama sonuçta tasarımı sizin kontrol etmeniz gerekir
      Sadece güzel görünsün ve Bootstrap hissi versin diyorsanız doğru seçenek Bootstrap’tir
      Teoride Tailwind’in üstünde Bootstrap’i yeniden uygulayan projeler var; Bootstrap benzeri bir başlangıç noktasıyla Tailwind’in gücünü birlikte verebilirler. Ama pratikte sadece Bootstrap kullanmaktan daha iyi çalıştığını görmedim
    • Bu amaç için DaisyUI kullanıyorum. Örnek demo site burada: https://nwk-landing-kit.netlify.app
      DaisyUI dokümanları burada: https://daisyui.com
    • Bootstrap benzeri bileşenler arıyorsanız ücretsiz olarak https://flowbite.com/ denenebilir
      Tailwind’in ücretli bileşenleri de var; sadece kopyalayıp yapıştırıyorsunuz. Alışınca Flowbite bileşenlerini yavaş yavaş değiştirebilmek güzel
    • Parayı kimin ödediğine bağlı
      İş güvenceniz varsa ve bir şeyleri kurcalamak istiyorsanız Tailwind ile oynayabilirsiniz. Trendlere duyarlı ve sesi çok çıkan insanlar genelde Tailwind’i seviyor gibi
      Ama kendi projenizse, kendi paranızla yapıyorsanız ya da bir son teslim tarihiniz varsa, zaten bildiğiniz Bootstrap’i kullanıp UI üzerinde yıpratma savaşına girmek yerine işi bitirmeye odaklanmanız daha iyi
    • Tailwind ile Bootstrap’i karşılaştırmak daha çok elma ile elmalı turta karşılaştırmaya benziyor
      Tailwind, bileşenler oluşturmak için üst üste koymanız gereken sınıfları sağlar
      UI bileşen kaynaklarıyla birlikte kullanırsanız daha kolay olur. Eskiden TailwindUI kullanmıştım ama ücretliydi; iyi ücretsiz alternatifler de vardır muhtemelen

  • “Tailwind mi değil mi” sohbetlerinde net bir kalıp var. Tailwind her anıldığında tekrarlanıyor
    30 dakikadan fazla doğru düzgün kullanmamış, kısa bir deneme yapmış ya da sadece dokümanlara göz atmış insanlar var. Bunlar Tailwind’den hoşlanmıyor ve “saf CSS” gibi şeyleri tercih ediyor
    Öte yandan gerçek projelerde, birden fazla kişiden oluşan ekiplerde kullanmış insanlar var. Bunlar değerini anlıyor, ödünleşimleri kabul ediyor ve seviyor
    Birinci gruptan ikinci gruba geçen çok kişi gördüm, ama ikinciden birinciye dönen neredeyse hiç görmedim
    Tailwind’in başarılı olmasının nedeni bu. Saflık yanlılarının gözünde güzel olmayabilir, ama bir şeyler inşa edenlerin ve pragmatistlerin gözünde gerçekten harika

    • Bence ben bu iki gruba da pek uymuyorum
      Tailwind’e karşı değilim, ama henüz kullanmamış olmamın nedeni Web Components veya React Styled Components gibi diğer seçeneklerden neden daha iyi bir yaklaşım olduğunu pek görememem
      En büyük sorun, Tailwind’in HTML’i çok sayıda utility class ile kalabalıklaştırıp okunmasını ve bakımını zorlaştırması
      Devasa bir global CSS dosyasından ve klasik etiket adına dayalı CSS’ten daha iyi olduğunu biliyorum, ama bileşene scoped CSS’i global ad alanını kirletmeden kullanmanın yolları zaten var. Web Components ve Styled Components bunun örnekleri
      İkisi de stilleri doğrudan bileşene, daha genel olarak belirli bir HTML etiketi grubuna bağlar; böylece hangi stilin nereye uygulandığını görmek kolaylaşır
      Global class adlarına da gerek kalmaz; istenmeyen yan etkiler veya çakışmalar konusunda endişe de azalır. Bir bileşeni kaldırınca ilgili stiller de birlikte kaldırılır, bu yüzden kullanılmayan CSS’in kalması konusunda endişelenmeniz gerekmez. Shadow DOM sayesinde bir bileşenin stilinin başka bir bileşeni istemeden etkileme riski de yoktur
      Sunuma yönelik stilleri doğrudan markup’a karıştırmadan HTML’i kısa ve okunabilir tutmayı önemsiyorum. Tailwind’de olduğu gibi tüm stiller class özniteliğine girince tek satırda uzun class listeleri oluşuyor; gerçek class adlarını da birlikte yazmak gerekiyorsa HTML dağınık hale geliyor
      Hangi stillerin uygulandığını bir bakışta anlamak zorlaşıyor, düzgün girintilemek de güçleşiyor. Eskiden HTML’deki inline style özniteliğinden uzaklaşmamızın birçok nedenini hatırlatıyor
      Tailwind’den nefret etmiyorum, ama okunabilirlik, bakım yapılabilirlik ve ilgilerin ayrılması açısından Web Components veya Styled Components’a göre net bir üstünlüğünü göremiyorum; hâlâ yanıtlanmamış ciddi endişelerim var
      Dokümanları okudum ama kullanmadım; diğer seçenekler yerine neden Tailwind’i seçeceğimi anlamakta zorlanıyorum. Sıradan HTML’in ortasında aşırı fazla class olması, benim için ikisini de okumayı zorlaştırıyor

  • Tailwind’i faydalı şekilde kullanan ve üretken olan insanlar olduğunu kabul ediyorum, ancak Tailwind artık her yerde olduğu için temiz ama sıradan görünen bir görünüm her yerde karşımıza çıkıyor

    • Bu, Tailwind ile TailwindUI/shadcn gibi şeyleri birbirine karıştırmak demek
      Genel olarak Tailwind, stiller üzerinde normal CSS’ten daha büyük bir etki yaratmaz. Birkaç istisna var. Gölge gibi şeyler biraz daha standartlaşmış durumda; indigo renk paleti de son dönemde dışarıyı bir miktar etkiledi
    • Tailwind makul varsayılanlar sunar, ama tasarım üzerinde büyük bir etkisi yoktur
      İnsanlar sadece siteleri belirli bir şekilde tasarlamaya eğilimli. Özellikle ShadCn ile birlikte kullanıldığında böyle
    • Hatta bu bana iyi bir şey gibi geliyor. Tailwind’in seçenekleri iyi tasarlanmış ve iyi çalışıyor
      Bunu, web sitesi yazı tipi olarak Inter’in yeni Helvetica gibi kullanılmasına benzetiyorum. Çok kişi kullanıyorsa ve iyi görünüyorsa, kullanmamak için neden olsun ki?
    • Eskiden Bootstrap için de benzer şeyler duyardım, ama benim yaptığım Bootstrap siteleri birbirine benzemiyordu
      Bootstrap, Tailwind’den çok daha önce çok sayıda utility class sunarak epey zaman kazandırıyordu ve belirli bir görünümü dayatmıyordu
      İstediğiniz sınıfları çağırmanız yeterliydi. Elbette Sass kaynak dosyalarını indirmediyseniz durum farklı, ama bu aptalca bir tercih olurdu
    • Bu konudaki görüşüm şu: iyi UI framework’leri, yani Tailwind ile bileşen kombinasyonları, hâlâ nadir
      Bu yüzden projelerin büyük çoğunluğu çok az sayıdaki framework’ü kullanıyor. Kaliteli 4-5 UI projesi daha ortaya çıksa, özellikle stil yönleri daha farklı olsa, çeşitlilik artar
      Tasarım da birçok yaratıcı iş gibi, şaşırtıcı derecede az sayıda insanın akışı belirlediği bir alan gibi görünüyor
      Keşke daha çok insan bunun farkında olsa. Yetenekli insanların “Ben yapsam da kimse dinlemez” diye düşünüp üretmediği durumlar olabilir
      Ama bu insanların bir kısmı denese, web’in büyük bir bölümüne yeni UI’lar açabileceklerini düşünüyorum

  • Tailwind, inline style’ların avantajlarının; yani bir şeyi adlandırmadan stillendirmenin, string’lerin evrenselliğinin ve string’lerin sınırlarının bir kanıtı
    Bundan sonra gelecek şeyi merakla bekliyorum; o zamana kadar da gönülsüzce Tailwind kullanacağım