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

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

Framework listesine bakarak başlamadım. Önce bu sitenin ne olacağına ve ne olmayacağına karar verdim.

Adımın, unvanımın ve birkaç bağlantının durduğu tek sayfalık bir portföy istemiyordum. Projelerimi ayrıntılı anlatabileceğim, teknik yazılar yayımlayabileceğim, kısa notlar tutabileceğim ve zamanla büyütebileceğim bir yer istiyordum. Bugün birkaç içerik var ama iki yıl sonra onlarca yazı, etiket ve birbirine bağlı Türkçe ve İngilizce sayfa olması gayet olası.

İhtiyaçlarım baştan belliydi. İçerik eklemek kolay olmalı, sayfalar hızlı açılmalı ve arama motorları tarafından rahatça okunabilmeliydi. Ziyaretçiye gerek yokken büyük bir JavaScript paketi gönderilmemeliydi. Türkçe ve İngilizce içerikleri aynı yapıda yönetebilmeliydim. Hazır bir tema tasarımımı sınırlamamalıydı. Birkaç yıl sonra projeye döndüğümde de kodu anlayabilmeliydim.

Astro’yu bu listeye bakarak seçtim.

İçeriğin uygulamadan daha önemli olması

Bu sitenin büyük bölümü okunan sayfalar. Bir proje yazısını açan kişi metni okumak, başlıklar arasında gezinmek ya da bir bağlantıya tıklamak istiyor. Bunun için tarayıcıda çalışan büyük bir uygulama katmanına gerek yok.

Astro sayfaları derleme sırasında HTML olarak üretiyor. Ne sunucu ne de tarayıcı her ziyarette sayfayı baştan kurmak zorunda kalıyor; ziyaretçi hazır bir belge alıyor. Sitenin çalışma biçimi yaptığı işle örtüşüyor.

Kişisel bir yayın alanı için bu önemli. JavaScript çalışmasa bile içerik okunabiliyor ve erişilebilir kalıyor. Arama motorları sayfanın metnine doğrudan ulaşabiliyor. Bir yazıyı okuyabilmek, istemci tarafındaki uygulamanın sorunsuz açılmasına bağlı olmuyor.

Varsayılan olarak az JavaScript

Birçok modern web çatısı basit bir sayfa için bile tarayıcıya uygulama kodu gönderiyor. Astro’da bir bileşen yalnızca HTML ve CSS üretebiliyor; etkileşim gerekmedikçe istemci tarafına JavaScript eklenmiyor.

Bu projede de böyle. 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 küçük ve birbirinden bağımsız betiklerle çalışıyor.

Bunun iki somut faydası var. İlk açılışta tarayıcının indirip yorumlaması gereken kod azalıyor. Bir etkileşimde sorun çıkarsa sayfanın geri kalanı çalışmaya devam ediyor. Performans için sonradan büyük bir temizlik yapmama gerek kalmıyor, çünkü gereksiz kodu baştan göndermiyorum.

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

Teknik bir yazı yazarken yönetim panelinde kutu doldurmak istemiyorum. Metnin sürüm kontrolünde durması, kodla birlikte değişebilmesi ve herhangi bir editörde açılabilmesi bana daha doğal geliyor.

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

Her içerik türünün beklediği alanlar da bir şemayla 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 ziyaretçinin karşısına çıkmadan, derleme sırasında yakalanıyor.

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

Sitenin İngilizce ve Türkçe sürümleri var, ama her içeriğin iki dilde aynı anda hazır olması gerçekçi değil. Türkçe karşılığı olan içeriklerde çeviriyi, olmayanlarda İngilizce metni gösterebilmeliydim.

Astro’nun dosya tabanlı sayfa yapısıyla bu kuralı açık ve anlaşılır biçimde kurabildim. İ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 boş kalmıyor, uygun İngilizce kayıt gösterilebiliyor.

Bunu büyük bir uluslararasılaştırma katmanına bağlanmadan, projenin ihtiyacına göre kurmak istedim. Dil seçici, sayfa adresleri, etiketler ve arama indeksleri aynı birkaç küçük yardımcıyla yönetiliyor.

Tasarım üzerinde tam kontrol

Hazır blog sistemleriyle hızlı başlanıyor ama bir süre sonra site kullanılan temaya benzemeye başlayabiliyor. Ben daha sakin, editoryal ve bana ait bir görünüm istedim. Ana sayfanın bir CV kopyası gibi durmasını istemedim; yazı, proje ve not bölümlerinin her birinin kendi ritmi olsun istedim.

Astro bileşenleri yeterince yapı sunuyor ama tasarımı dayatmıyor. Sayfa iskeletlerini, tipografiyi ve tekrar kullanılan parçaları bileşenlere ayırabiliyorum, ortaya çıkan şey yine de bir şablonun sınırları içinde kalmıyor. Renk, boşluk ve tipografi kararlarını Tailwind CSS ve CSS değişkenleriyle tek bir yerden yönetiyorum.

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” deyip bazı kontrolleri ertelemek kolay. Uzun süre yaşamasını istediğim bir sitede küçük hataların 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 eklenince yanlış bir alan adı, eksik bir çeviri bilgisi ya da beklenmeyen bir veri biçimi site yayımlanmadan yakalanabiliyor.

Tip kontrolü, biçim denetimi, testler, üretim derlemesi ve bağlantı kontrolü tek bir doğrulama akışında çalışıyor. Astro’nun derlemeye dayalı yapısı bu kontrollerle iyi örtüşüyor, çünkü sorunları mümkün olduğunca yayından önce görmek istiyorum.

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

React ve Next.js’i kötü bulduğum için tercih etmemiş değilim. Kullanıcı oturumu, yoğun form akışları, sık değişen kişisel veriler ya da tarayıcıda sürekli güncellenen bir arayüz olsaydı daha güçlü adaylar olabilirlerdi.

Bu projede ise sayfaların çoğu yayımlandıktan sonra değişmeyen içerikler. Tam kapsamlı bir istemci uygulaması, çözmeye çalıştığım sorundan daha büyük bir çalışma zamanı katmanı getirecekti. Astro, gerekirse React, Vue ya da başka bir arayüz bileşenini yalnızca ihtiyaç duyulan 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 baştan kurmam gerekmeyecek.

Bugünün sade ihtiyacını büyütmeden ileride gelebilecek ihtiyaçlara yer bırakması benim için önemliydi.

Elbette bazı karşılıkları var

Astro her proje için 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 üretimin avantajı büyük ölçüde kaybolur. Astro’nun topluluğu güçlü olsa da daha eski çatılardaki her kütüphanenin birebir karşılığı bulunmayabilir.

Bu site için bu sınırlamalar belirleyici değil. İçerik depoda duruyor, değişiklikler yayından önce derlenebiliyor ve etkileşimli alanlar oldukça küçük. Astro’nun iyi olduğu şeyler, bu projenin en çok ihtiyaç duyduğu şeylerle örtüşüyor.

Sonuç

Astro’yu bir performans puanına ya da güncel bir eğilime bakarak seçmedim. Kararı sitenin kendisi belirledi: önce içerik sunan, zamanla büyüyecek, iki dilde çalışan ve bakımını tek bir kişinin yaptığı bir yayın alanı.

Sayfalar hazır HTML olarak üretiliyor, JavaScript yalnızca gereken etkileşimlere ekleniyor, içerikler Markdown ve MDX ile yönetiliyor ve veri yapısı derleme sırasında doğrulanıyor. Altyapı ziyaretçinin karşısına çıkmıyor.

Bence doğru framework, projenin asıl işini en az sürtünmeyle yapmasını sağlayan framework; en çok özelliği sunan değil. Bu site için o framework Astro oldu.

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 hızın yanında daha az hata yüzeyi de demek.
• 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çmeyi gerektirmiyor; etkileşimi yalnızca gereken yere koymayı kolaylaştırıyor.
• Geleceğe hazırlıklı olmak için bugünün projesini karmaşıklaştırmak gerekmiyor.