Bu Siteyi Geliştirirken Neden Astro'yu Seçtim?

Önce nasıl bir site istediğimi düşündüm

Teknoloji seçimine framework listesinden başlamadım. Önce bu sitenin ne olacağını, daha önemlisi ne olmayacağını belirledim.

Burası yalnızca adımın, unvanımın ve birkaç bağlantının bulunduğu tek sayfalık bir portföy değil. Projelerimi ayrıntılı biçimde anlatabileceğim, teknik yazılar yayımlayabileceğim, kısa notlar tutabileceğim ve zamanla büyütebileceğim kişisel bir geliştirici merkezi. Bugün birkaç içerik olsa da iki yıl sonra onlarca yazının, etiketin ve birbirine bağlı Türkçe–İngilizce sayfanın bulunması gayet olası.

Bu nedenle temel ihtiyaçlarım baştan belliydi:

• İçerik eklemek kolay olmalıydı.
• Sayfalar hızlı açılmalı ve arama motorları tarafından rahatça okunabilmeliydi.
• Ziyaretçiye, ihtiyaç olmadığı hâlde büyük bir JavaScript paketi gönderilmemeliydi.
• Türkçe ve İngilizce içerikler aynı yapıda yönetilebilmeliydi.
• Tasarım sistemini hazır bir tema sınırlandırmamalıydı.
• Proje birkaç yıl sonra geri döndüğümde de anlaşılır kalmalıydı.

Astro kararı bu ihtiyaçların sonucunda ortaya çıktı.

İçeriğin uygulamadan daha önemli olması

Bu sitenin büyük bölümü okunan sayfalardan oluşuyor. Bir proje yazısını açan ziyaretçi metni okumak, başlıklar arasında gezinmek veya ilgili bağlantıya ulaşmak istiyor. Bunun için tarayıcıda çalışan geniş bir uygulama katmanına ihtiyaç yok.

Astro, sayfaları derleme sırasında HTML olarak üretiyor. Sunucu ya da tarayıcı, her ziyaret için sayfayı baştan kurmak zorunda kalmıyor. Ziyaretçi hazır bir belge alıyor; bu da sitenin çalışma biçimini gerçek ihtiyacıyla aynı hizaya getiriyor.

Bu yaklaşım özellikle kişisel bir yayın alanı için değerli. İçerik, JavaScript çalışmasa bile anlamlı ve erişilebilir kalıyor. Arama motorları sayfanın asıl metnine doğrudan ulaşabiliyor. Ayrıca bir yazının okunabilmesi, istemci tarafındaki uygulamanın başarıyla açılmasına bağlı olmuyor.

Varsayılan olarak az JavaScript

Birçok modern web çatısı, basit bir sayfayı göstermek için bile tarayıcıya uygulama kodu gönderiyor. Astro’da ise bunun tersi geçerli: bir bileşen yalnızca HTML ve CSS üretebilir; etkileşime gerçekten ihtiyaç duyulmadıkça istemci tarafı JavaScript eklenmez.

Bu projede de tam olarak böyle davranıyorum. Sayfaların gövdesi statik HTML olarak geliyor. Tema seçimi, mobil menü, komut paletiyle arama, kod kopyalama düğmesi, içindekiler alanı ve okuma ilerleme çubuğu ise küçük ve birbirinden bağımsız betiklerle çalışıyor.

Bu ayrımın iki somut faydası var:

1. İlk açılışta tarayıcının indirip yorumlaması gereken kod azalıyor.
2. Bir etkileşimde sorun çıktığında sayfanın geri kalanı çalışmaya devam ediyor.

Kısacası performans için sonradan büyük bir temizlik yapmak yerine, gereksiz kodu en başta hiç göndermemiş oluyorum.

Markdown ve MDX ile doğal bir yayın akışı

Teknik içerik yazarken bir yönetim panelinde kutular doldurmak istemiyorum. Metnin sürüm kontrolünde durması, kodla birlikte değişebilmesi ve herhangi bir metin editöründe açılabilmesi benim için daha doğal.

Astro’nun içerik koleksiyonları sayesinde yazılar, notlar ve projeler ayrı klasörlerde Markdown veya MDX dosyaları olarak tutuluyor. Yeni bir içerik eklemek, doğru klasöre yeni bir dosya koymak kadar basit. MDX gerektiğinde bilgi kutusu ya da görsel gibi tekrar kullanılabilir bileşenleri yazının içine eklememe de izin veriyor.

Buradaki önemli nokta yalnızca dosya kullanmak değil. Her içerik türünün beklediği alanlar bir şema ile tanımlı. Örneğin bir proje başlık, açıklama, bağlam ve etiket bilgisi olmadan yanlışlıkla yayına giremiyor. Hatalı bir alan, site çalışırken ziyaretçinin karşısına çıkmak yerine derleme sırasında fark ediliyor.

Çoklu dil yapısını açık biçimde kurabilmek

Sitenin İngilizce ve Türkçe sürümleri var. Her içeriğin iki dilde aynı anda hazır olması ise gerçekçi değil. Bu nedenle Türkçe karşılığı bulunan içeriklerde çeviriyi göstermeli, bulunmayanlarda İngilizce metni kullanabilmeliydim.

Astro’nun dosya tabanlı sayfa yapısı bu kuralı görünür ve anlaşılır biçimde kurmama izin verdi. İngilizce sayfalar ana yolları, Türkçe sayfalar /tr önekini kullanıyor. Birbirinin çevirisi olan dosyalar ortak bir anahtarla eşleşiyor. Türkçe içerik henüz yoksa liste tamamen boş kalmıyor; uygun İngilizce kayıt gösterilebiliyor.

Bunu büyük bir uluslararasılaştırma katmanına bağımlı olmadan, projenin ihtiyacına göre tasarlamak önemliydi. Dil seçici, sayfa adresleri, etiketler ve arama indeksleri aynı küçük yardımcılar üzerinden yönetiliyor.

Tasarım üzerinde tam kontrol

Hazır blog sistemleri hızlı başlangıç sağlar, fakat bir süre sonra sitenin dili kullanılan temanın diline benzemeye başlayabilir. Ben daha sakin, editoryal ve kendine ait bir görünüm istedim. Ana sayfanın bir CV kopyası gibi görünmemesi; yazı, proje ve not bölümlerinin farklı ritimlere sahip olması önemliydi.

Astro bileşenleri bu konuda yeterince yapı sunarken tasarımı belirlemiyor. Sayfa iskeletlerini, tipografiyi ve tekrar kullanılan parçaları bileşenlere ayırabiliyorum; buna rağmen ortaya çıkan şey özel bir şablonun sınırları içinde kalmıyor. Tailwind CSS ve CSS değişkenleriyle renk, boşluk ve tipografi kararları tek merkezden yönetiliyor.

Sonuçta bileşen tabanlı geliştirmenin düzenini korurken, klasik bir tema sisteminin görsel yükünü almamış oluyorum.

TypeScript ve derleme zamanı güveni

Kişisel projelerde “nasıl olsa küçük” diyerek bazı kontrolleri ertelemek kolay. Fakat uzun süre yaşamasını istediğim bir sitede küçük hataların zamanla birikmesini istemedim.

Astro’nun TypeScript desteği bileşen özelliklerini, veri dosyalarını ve yardımcı fonksiyonları aynı tip sistemi içinde tutuyor. İçerik şemaları da buna eklenince yanlış bir alan adı, eksik bir çeviri bilgisi veya beklenmeyen veri biçimi daha site yayımlanmadan yakalanabiliyor.

Projede tip kontrolü, biçim denetimi, testler, üretim derlemesi ve bağlantı kontrolü tek bir doğrulama akışında çalışıyor. Astro’nun derleme odaklı yapısı bu kontrollerle iyi örtüşüyor: sorunları kullanıcı sayfayı açtıktan sonra değil, mümkün olduğunca yayın öncesinde görmek istiyorum.

Neden doğrudan React ya da Next.js değil?

React ve Next.js kötü seçenekler olduğu için Astro’yu seçmedim. Kullanıcı oturumu, yoğun form akışı, sık değişen kişisel veriler veya tarayıcıda sürekli güncellenen bir arayüz olsaydı bu araçlar daha güçlü adaylar olabilirdi.

Fakat bu projede sayfaların çoğu yayımlandıktan sonra aynı kalan içeriklerden oluşuyor. Tam kapsamlı bir istemci uygulaması kurmak, çözdüğüm problemden daha büyük bir çalışma zamanı katmanı getirecekti. Astro ihtiyaç duyarsam React, Vue veya başka bir arayüz bileşenini yalnızca gerekli bölümde çalıştırmama izin veriyor. Şu an buna ihtiyacım yok; ama ileride etkileşimli bir araç eklersem bütün siteyi yeniden kurmak zorunda da değilim.

Bu esneklik benim için önemliydi: bugünün sade ihtiyacını gereksiz yere büyütmeden, yarının olası ihtiyaçlarına kapıyı açık bırakıyor.

Elbette bazı karşılıkları var

Astro her proje için otomatik olarak doğru tercih değil. Çok büyük ekiplerde hazır bir React bileşen ekosistemiyle ilerlemek daha verimli olabilir. Tamamen dinamik bir ürün panelinde statik üretim temel avantajını kaybedebilir. Ayrıca Astro’nun topluluğu güçlü olsa da daha eski çatılarda bulunan her kütüphanenin birebir karşılığı burada bulunmayabilir.

Bu site içinse bu sınırlamalar belirleyici değil. İçerik depo içinde yaşıyor, değişiklikler yayınlama öncesinde derlenebiliyor ve etkileşim alanları oldukça küçük. Yani Astro’nun güçlü olduğu yerlerle projenin ağırlık merkezi örtüşüyor.

Sonuç

Astro seçimi tek bir performans puanına ya da güncel bir teknoloji eğilimine dayanmıyor. Kararın temelinde sitenin doğası var: burası önce içerik sunan, zaman içinde büyüyecek, iki dilde çalışan ve bakımı tek kişi tarafından sürdürülecek bir yayın alanı.

Astro sayesinde sayfalar hazır HTML olarak üretiliyor, yalnızca gereken etkileşimler JavaScript alıyor, içerikler Markdown ve MDX ile yönetiliyor, veri yapısı derleme sırasında doğrulanıyor. Böylece teknik altyapı ziyaretçinin önüne geçmiyor; sessizce içeriğe hizmet ediyor.

Benim için doğru framework, en fazla özelliği sunan değil, projenin asıl işini en az sürtünmeyle yapmasını sağlayan framework. Bu site özelinde Astro’yu seçmemin nedeni tam olarak bu.

Bu projeden çıkardığım dersler

• Framework seçimine araçlardan değil, ürünün nasıl kullanılacağından başlamak gerekiyor.
• İçerik ağırlıklı bir sitede az JavaScript yalnızca hız değil, daha az hata yüzeyi de sağlıyor.
• Markdown dosyaları basit görünse de şema doğrulamasıyla güvenilir bir içerik sistemine dönüşebiliyor.
• Statik üretim, etkileşimden vazgeçmek anlamına gelmiyor; etkileşimi gerektiği yere koymayı sağlıyor.
• Geleceğe hazırlıklı olmak, bugünün projesini gereksiz yere karmaşıklaştırmak zorunda değil.