Svelte'i neden seçtik: iki ürünün ortak arayüz kararı

Elimizde birbirinden çok farklı görünen iki ürün var: PsyBank, insanları terapistlerle buluşturan sakin ve güven odaklı bir platform; MatbaaStore ise onlarca varyantı, anlık fiyat hesabı ve yoğun form etkileşimi olan bir e-ticaret sitesi. İkisi ürün olarak çok farklı olsa da arayüz katmanında aynı sorunları çözüyorlar: hızlı yüklenen sayfalar, akıcı formlar, bakımı kolay bileşenler. Bu iki ürünü aynı ekip geliştirdiği için, ortak bir arayüz dili seçmek verimlilik açısından kritikti.

Bu yazıda neden React yerine Svelte'te karar kıldığımızı anlatacağız. Paket boyutu, geliştirme hızı ve çalışma zamanı performansını gerçek ölçümlerle karşılaştıracak; kararın getirdiği avantajların yanında göze aldığımız ödünleri de dürüstçe koyacağız. Amacımız "Svelte her zaman doğru seçimdir" demek değil; bizim bağlamımızda neden mantıklı olduğunu ve sizin bağlamınızda nasıl değerlendirebileceğinizi göstermek.

İki ürün, tek arayüz dili

İki ürünü ayrı teknoloji yığınlarıyla geliştirmek ilk bakışta esneklik gibi görünür; pratikte ise iki kat bakım, iki kat öğrenme eğrisi ve ekip içinde bilgi silolarına yol açar. Bir geliştirici PsyBank'tan MatbaaStore'a geçtiğinde sıfırdan başlamak zorunda kalmamalı. Bu yüzden ortak bir arayüz dilinde standartlaşmak istedik: aynı bileşen desenleri, aynı durum yönetimi mantığı, aynı yapı araçları.

Standartlaşma kararı, seçtiğimiz teknolojinin iki farklı yükü de kaldırabilmesini gerektiriyordu. Bir uçta PsyBank'ın büyük ölçüde içerik ve akış odaklı, hızlı ilk yükleme isteyen sayfaları; diğer uçta MatbaaStore'un ağır etkileşimli, sürekli güncellenen fiyat ve form ekranları. Aradığımız çerçeve hem statik ve hızlı, hem de gerektiğinde yoğun etkileşimli olabilmeliydi. Svelte ve SvelteKit ikilisi bu iki ucu tek modelde birleştirdiği için kısa listeye girdi.

Neden React değil? Derleyici ile çalışma zamanı farkı

React'i dışlamadık; onunla yıllarca çalıştık ve olgun ekosistemine saygımız var. Ama iki ürün için de belirleyici olan tek bir mimari fark vardı: React tarayıcıya bir çalışma zamanı kütüphanesi indirir ve arayüzü sanal DOM üzerinden yönetir. Svelte ise bir derleyicidir; bileşenlerinizi derleme anında düz, verimli JavaScript'e çevirir. Sonuçta tarayıcıya taşınan çalışma zamanı yükü çok daha küçük olur.

Bu fark iki yerde somutlaşıyor. Birincisi paket boyutu: taşımanız gereken bir çerçeve çalışma zamanı olmadığında, kullanıcıya inen JavaScript küçülür ve ilk etkileşime hazır olma süresi kısalır. İkincisi güncelleme modeli. Sanal DOM her değişimde ağacı karşılaştırır; Svelte ise derleme sırasında hangi verinin hangi DOM düğümünü etkilediğini zaten bildiği için, değişimde yalnızca ilgili düğümü günceller. Ara bir karşılaştırma adımı yoktur.

React işi tarayıcıda yapar, Svelte derleyicide. Kullanıcının cihazı ne kadar yavaşsa, bu işi önceden yapmış olmanın değeri o kadar artar. Biz de kullanıcının cihazını seçemediğimiz için, işi öne almayı tercih ettik.

Geliştirme hızı: daha az tören, daha çok iş

Performans önemliydi ama günlük geliştirme deneyimi de öyle. Svelte 5'in runes modeli reaktifliği çok az kod ile ifade etmemizi sağlıyor. Bir değerin değişmesine bağlı türetilmiş bir değer tanımlamak, memoizasyon kuralları ezberlemeden, doğrudan okunabilir bir ifadeye dönüşüyor. Bir bileşenin yaptığı iş, çevresindeki tören kodunun altında kaybolmuyor.

let adet = $state(500);
let birimFiyat = $state(1.20);

// Türetilmiş değer: adet ya da birim fiyat değişince kendiliğinden güncellenir
let toplam = $derived(adet * birimFiyat);

Bu sadeliğin pratik karşılığı, bileşenlerin daha kısa ve niyetin daha okunur olması. Yeni bir geliştirici koda baktığında "burada ne oluyor?" sorusunun cevabını daha çabuk buluyor. Stil ve şablonun aynı dosyada, bileşene özel (scoped) olarak durması da CSS'in başka yerlere sızmasını engelliyor; iki üründe de tutarlı bir görsel dil kurmayı kolaylaştırdı.

SvelteKit tarafında ise iki ürünün farklı ihtiyaçlarını tek çatı altında karşılayabildik. İçerik ağırlıklı sayfaları derleme anında statik üretiyoruz; böylece sunucuya hiç uğramadan, bir CDN'den ışık hızında açılıyorlar. Yoğun etkileşim gereken tek bir akışta ise istemci tarafını devreye alıyoruz. Aynı çerçeve içinde sayfa başına bu kararı verebilmek, iki ürünün farklı doğasını uzlaştıran şey oldu.

İlerlemeli geliştirme: her şey JavaScript'e bağlı olmasın

Modern arayüz çerçevelerinin sessiz bir bedeli var: sayfa, JavaScript yüklenip çalışana kadar boş ya da işlevsiz kalabiliyor. Yavaş bir bağlantıda ya da bir hata anında kullanıcı hiçbir şey yapamaz hâlde bekler. SvelteKit'in bize verdiği en değerli şeylerden biri, arayüzü ilerlemeli geliştirme ilkesiyle kurabilmek oldu: sayfalar önce HTML olarak üretilip gelir, JavaScript ise deneyimi zenginleştiren bir katman olarak sonradan devreye girer.

Bu, iki üründe farklı işe yaradı. PsyBank'ın içerik sayfalarında JavaScript'e neredeyse hiç ihtiyaç yok; sayfalar statik HTML olarak, sunucuya bile uğramadan açılıyor ve arama motorlarının da eksiksiz gördüğü, hızlı ve erişilebilir belgeler oluyor. Etkileşimin yoğun olduğu tek akışta ise istemci tarafını bilinçli olarak devreye alıyoruz. Bu ayrımı sayfa düzeyinde verebilmek, "her şeyi istemcide çalıştır" ya da "hiçbir şeyi çalıştırma" ikilemini ortadan kaldırdı.

Formlar bu yaklaşımın en somut kazancı. İstemci ağırlıklı klasik bir uygulamada form, JavaScript çalışmadan hiç gönderilemez. SvelteKit'in form modelinde ise gönderim önce sunucu tarafında düzgün çalışacak şekilde kurulur; JavaScript mevcutsa deneyim akıcılaşır, değilse form yine de işini görür. Bir baskı siparişi ya da bir randevu talebi gibi kritik akışlarda "JavaScript yüklenemedi" diye kaybedilen bir işlem, doğrudan kaybedilen bir müşteridir.

Ölçtüğümüz sonuçlar ve göze aldığımız ödünler

Kararı hisle değil sayıyla verdik. Aynı temsili sayfayı iki yaklaşımla kurup karşılaştırdığımızda gördüğümüz eğilimler şunlar oldu:

• Paket boyutu: Çalışma zamanı kütüphanesi taşımadığımız için kullanıcıya inen JavaScript belirgin şekilde küçüldü. Küçük paket, özellikle mobil bağlantılarda daha hızlı ilk yükleme demek.
• İlk yükleme: Statik üretim ve küçük paket birleşince, sayfanın etkileşime hazır olma süresi kısaldı. PsyBank gibi ilk izlenimin güven kurduğu bir üründe bu doğrudan iş değeri.
• Bakım yükü: Daha az tören kodu, daha az bağımlılık ve bileşene özel stil sayesinde, aynı ekip iki ürünü birden daha rahat taşıyor.

Dürüst olmak gerekirse ödünler de vardı. Svelte'in ekosistemi React kadar geniş değil; hazır bir bileşen kütüphanesi ararken bazen kendimiz yazmak zorunda kaldık. İş piyasasında Svelte bilen geliştirici havuzu da daha küçük. Ama bizim için bu ödünler kabul edilebilirdi: küçük ve deneyimli bir ekiple, uzun ömürlü iki ürünü geliştiriyoruz; ekosistem genişliğinden çok, kod tabanının sade ve hızlı kalması önceliğimizdi.

Sonuç

Svelte'i "moda olduğu için" değil, iki ürünün ortak ihtiyaçlarına en iyi cevabı verdiği için seçtik: küçük paketler, hızlı ilk yükleme, sade bir reaktiflik modeli ve statikten etkileşimliye kadar tek çatı altında esneklik. Karar sizin bağlamınızda farklı çıkabilir — geniş bir ekibiniz ve React ekosistemine bağımlı bir yığınınız varsa geçiş maliyeti anlamlı olmayabilir. Ama bir teknoloji seçerken sorulacak doğru soru "hangisi daha popüler?" değil, "hangisi benim iki ürünümün ortak yükünü en sade şekilde taşır?" sorusudur. Bizim cevabımız Svelte oldu.