Son birkaç yılınızı meta-frameworklar arasında mekik dokuyarak geçirdiyseniz, SvelteKit 2 size tuhaf bir rahatlama ve şüphe karışımı gibi gelecektir. Rahatlama, çünkü karmaşıklığı artırmak yerine gerçekten azaltıyor. Şüphe, çünkü her an bir aksilik çıkacakmış gibi bekliyorsunuz. Ama öyle bir şey olmuyor. Svelte 5 ile eşleştiğinde, bu yığın 2026'da tam kapsamlı (full-stack) bir uygulama yayınlamanın en üretken yollarından biridir ve rakamlar geliştirici deneyimini desteklemektedir. Paket boyutları (bundles), Svelte 4'ün ürettiğinden yaklaşık %35 daha küçüktür. Yönlendirme (routing), sunucu fonksiyonları ve kimlik doğrulama (authentication) desenlerinin tamamı, birbirine yama yapılmış eklentiler değil, birinci sınıf vatandaşlardır.

Runeler reaktiviteyi açık hale getirir

En büyük zihinsel değişim Svelte 5'in runelerinden kaynaklanıyor. Svelte'in önceki sürümleri, bağımlılıkları takip etmek için $: etiketini ve çok sayıda derleyici sihrini kullanıyordu. Çalışıyordu ancak bir şeyler bozulduğunda, görünmez kabloları hata ayıklamaya (debugging) çalışıyordunuz. Runeler bu sihri açık fonksiyonlarla değiştiriyor. Derleyiciye tam olarak neyi takip etmesi gerektiğini söylüyorsunuz ve o da dinliyor.

Bilmeniz gerekenler şunlardır:

  • $state reaktif değişkenleri yönetir. Herhangi bir değeri $state() içine alırsanız, derleyici onu izlemesi gerektiğini bilir.
  • $derived diğer state'lerden değerler hesaplar. Filtrelenmiş bir listeye veya biçimlendirilmiş bir toplama mı ihtiyacınız var? $derived kullanın. $effect'ten temel farkı, $derived'ın eylemler için değil, değerler için olmasıdır.
  • $effect yan etkileri (side effects) çalıştırır. Belge başlığı güncellemeleri, manuel DOM ölçümleri veya temizlenmesi gereken zamanlayıcılar gibi düşünebilirsiniz. DOM onaylandıktan sonra çalışır; bir yaşam döngüsü kancasına (lifecycle hook) benzer ancak belirli reaktif bağımlılıklara bağlıdır.
  • $props, bileşenlerde veri almak için kullanılan eski export let deseninin yerini alır. Daha nettir ve TypeScript ile daha iyi etkileşim kurar.

Bu model pratikte karşılığını veriyor. Derleyici yalnızca işaretlediğiniz şeyleri takip ettiği için, ölü kod (dead code) ölü kalmaya devam eder. Bir değişkenin neden bir güncellemeyi tetiklediğini merak etmeyi bırakır ve kendi açık talimatlarınıza güvenmeye başlarsınız.

Yapılandırma ile değil, klasörlerle yönlendirme

SvelteKit, yönlendirme için dosya sisteminizi kullanır. Bakımı yapılacak ayrı bir yönlendirici (router) dosyası yoktur. Bir dizine +page.svelte dosyası bırakın ve o dizin canlı bir rota (route) haline gelsin.

Paylaşılan UI, bu rotaları +layout.svelte aracılığıyla sarmalar. Kök dizine bir tane koyarsanız, her alt rota bunu miras alır. Ağacın daha derinlerine bir tane koyarsanız, yalnızca o bölüm sarmalayıcıyı alır.

Sunucu tarafı mantığı +page.server.ts içinde yaşar. Bu, sayfanız oluşturulmadan önce çalışır; dolayısıyla veritabanı sorgulama, bir çerezi (cookie) doğrulama veya kimliği doğrulanmamış bir kullanıcıyı reddetme işlemleri burada yapılır. Tipler, load fonksiyonunuzdan sayfa bileşeninize otomatik olarak akar; bu da manuel arayüzler (interfaces) yazmadan verilerinizin tiplendirilmiş olduğu anlamına gelir.

Ham API uç noktaları (endpoints) +server.ts dosyalarına gider. Bunlar standart HTTP işleyicilerini —GET, POST, PUT, DELETE— dışa aktarır, böylece sayfalarınızla birlikte bir REST arka ucu (back end) oluşturmak doğal hissettirir.

Az bilinen bir özellik: grup rotaları. Bir klasör adını (auth) gibi parantez içine alarak, URL'ye yeni bir segment eklemeden paylaşılan bir düzen (layout) oluşturursunuz. Bu, aynı sade arayüze ihtiyaç duyan ancak /auth/login yerine /login ve /signup adreslerinde yaşayan giriş ve kayıt sayfaları için mükemmeldir.

Veri, güvenlik ve kademeli geliştirme (progressive enhancement)

Modern frameworklar full-stack hakkında konuşmayı sever ancak birçoğu kimlik doğrulama kontrollerini veya form mantığını nereye koyacağınız konusunda sizi cevapsız bırakır. SvelteKit size net kancalar (hooks) sunar.

Veri çekme için +page.server.ts kullanın. Oradaki load fonksiyonu yalnızca sunucuda çalışır, böylece veritabanı kimlik bilgileriniz tarayıcıya asla sızmaz. SvelteKit, load dönüş değerlerinizden tipler üretir, böylece frontend tarafınız tutarlı kalır.

Tüm uygulamayı kısıtlamak (gate) için hooks.server.ts kullanın. Bu, her istekte çalışır; bu da oturumları doğrulamak, JWT süresinin dolup dolmadığını kontrol etmek veya gelen olaylara kullanıcı bağlamını (context) eklemek için doğru yer olmasını sağlar.

Mutasyonlar için form eylemlerini (form actions) kullanın. Ayrı bir API uç noktası bağlamak ve JSON işlemek yerine, +page.server.ts içinde bir eylem tanımlarsınız. Buradaki güzellik kademeli geliştirmedir (progressive enhancement). Eğer JavaScript yüklenemezse —veya bir kullanıcı tarafından devre dışı bırakılmışsa— form yine de sunucu eylemine gönderilir ve sayfa sonuçla birlikte yeniden oluşturulur. Eğer JavaScript mevcutsa, SvelteKit tam bir yeniden yükleme yapmadan deneyimi geliştirir. Aynı koddan hem dayanıklılık hem de şıklık elde edersiniz.

Unutulmaması gereken bir kural: matematiksel işlemleri $effect içinde değil, $derived içinde yapın. Değerleri hesaplamak için $effect kullanmak, izlenmesi zor güncelleme döngülerini tetikleyebilir. $effect'i gerçek yan etkiler için saklayın ve hesaplanmış durumunuzun (computed state) kontrolünü $derived'a bırakın.

SvelteKit ve Next.js Karşılaştırması

Her iki framework de üretim seviyesindeki uygulamaları yayına alabilir, ancak aralarındaki ödünler gerçektir.

Paket boyutu SvelteKit lehinedir. Svelte, bileşenleri vanilla JavaScript'e derlediği ve Virtual DOM'u tamamen atladığı için çalışma zamanı ayak izi (runtime footprint) küçük kalır. Next.js ise React'in reconciliation motorunu beraberinde taşır.

Reaktivite de farklılık gösterir. SvelteKit, runes yapılarını derleme zamanında (compile time) çözer. Tarayıcıya düz güncellemeler iletilir. Next.js ise React'in çalışma zamanı (runtime) hook'larına ve reconciliation işlemine dayanır; bu da istemci tarafında daha fazla iş yapılması anlamına gelir.

SvelteKit ile adaptasyon süreci (onboarding) daha kolaydır. Zihinsel model daha basittir. Yeniden render'lardan (re-renders) kaçınmak için useEffect bağımlılık dizileriyle veya memoization bulmacalarıyla uğraşmak zorunda kalmazsınız. TypeScript entegrasyonuna da değinmek gerekir. Her iki framework de...