Önce Utility First, Sonra Bileşen

• CSS'de tailwindcss gibi Utility-First yaklaşımı genellikle HTML'ye sınıfları bir bir dizmek olarak düşünülür.

• Oysa bu yalnızca dışarıdan görünen tarafıdır; Utility-First'ın özünde, bileşenlerin ne zaman kurulacağına dair zamanlama meselesi vardır.

• CSS'nin ortaya çıktığı ilk dönemlerde öne çıkan yaklaşımlar bakım kabuslarına neden oldu.

• OOCSS akımı, bu sorunu bileşenler kurarak çözmeye çalıştı. Yeniden kullanılabilirlik arttı ama bileşen kapsamını belirlemedeki zorlukla karşılaştı.

• Bileşenler yeniden kullanım için olsa da, gelecekte neyin yeniden kullanılacağını bilinememesi gibi bir sorun vardır.

• Atomic CSS akımı, her özelliğe yalnızca bir sınıf atayarak bu sorunu çözmeye çalıştı. Geliştirme başlangıçta hızlandı ancak bakım yapılabilirlik problemi yine geri döndü.

• Tek Doğru Kaynak (Single Source of Truth) çok kolay bozuluyor — tüm projede "bul ve değiştir" işlemine bağımlı hale geliyor (harici şablonlara bağımlılık ise zahmetli ve sınırlıdır).

• Utility-First, Atomic yaklaşımın aksine bileşeni sahiplenir. Ayrıca OOCSS'ten farklı olarak utility'lerle başlar. Bileşenler, gerçekten gerektiğinde inşa edilir.

• "Ne yapmalıyız?" sorusu, "Bunu ne zaman bileşene dönüştürmeliyiz?" sorusuna dönüşür.

• Kısacası Utility-First, her iki yaklaşımı da birleştirip evrimleştirmiş bir model olarak görülmelidir.

• Bu nedenle Utility-First yönteminde bileşenlerin daha fazla öne çıkarılması gerekir. “Bileşenleri sadece kabul ediyoruz” yerine, “Bileşenleri gerçekten gerekli hâle geldikleri ana kadar erteleriz ve böylece yeniden kullanılabilirliği en üst düzeye çıkarırız” denmelidir.

[nemorize]

Keyifle okudum.

[mytory]

Teşekkürler :)