Baseline: Daha Az JavaScript Göndermenin Sırrı

Baseline: Daha Az JavaScript Göndermenin Sırrı

jQuery’nin o güzel günlerini hatırlıyor musunuz? 90KB’lık bir dosyayı projeye atıyordunuz, bir anda `$(document).ready()` her şeyi ipeksi pürüzsüz yapıyordu. Sonra akıllandık, bundle’ları böldük, jQuery’yi React, Vue ve her küçük iş için ayrı ayrı toplanmış mini kütüphanelerle dolu bir dolaba dönüştürdük.

Ama benim sürekli kendimi yakaladığım bir şey var: hedeflediğim tarayıcı, aynı işi ücretsiz yapan bir API’ye sahipken 20KB’lik bir tarih biçimlendirme kütüphanesine uzanıyorum. Hem de hiçbir ağ isteği yokken. Versiyon yükseltmesi yokken. Gelecekte bakım yükü yokken.

İşte tam burada devreye **Baseline** giriyor.

Daha önce duymadıysanız, Baseline W3C destekli bir girişim. Bize web geliştirmedeki en sinir bozucu soruya tek kelimelik, evrensel bir yanıt veriyor: “Bu özelliği ne zaman güvenle kullanabilirim?” Cevap çoğu zaman: **bugün**. Baseline, web platformunun hâlihazırda neleri yapabildiğini görmenize yardımcı olarak gönderdiğiniz JavaScript miktarını ciddi şekilde azaltabilir. Nasıl mı? Gelin bakalım.

Baseline Aslında Nedir?

Baseline, tüm büyük tarayıcılar arasında ortak bir tarayıcı desteği anlayışıdır: Chrome, Edge, Firefox, Safari ve Opera. “Tarayıcıların %97’sinde çalışıyor” matrisini kontrol etmek yerine Baseline, bir özelliğin **available** (mevcut tarayıcılarda çalışıyor) ya da **newly available** (en son sürümlerde yeni yerleşti) olduğunu söyler. Amaç, tahmin yürütmeyi ortadan kaldırmak.

Bunu “caniuse, ama daha anlaşılır bir kararla” gibi düşünün. Bir özellik Baseline olduğunda, ortak ekosistemdeki her tarayıcının onu desteklediği anlamına gelir. Bu sizin yeşil ışığınızdır.

En iyi kısmı? Baseline muhtemelen zaten kullandığınız yerlerde içinde. MDN uyumluluk tablolarına gidin, bir özellik arayın, hemen yanında bir Baseline rozeti göreceksiniz. Ya da bugün hazır olanların listesine bakmak için [web.dev/baseline](https://web.dev/baseline) adresine göz atın.

Bunun Bundle Boyutuyla Ne İlgisi Var?

“Bunun için bir kütüphaneye ihtiyacın var” ile “browser bunu zaten yapıyor” arasındaki fark her geçen yıl kapanıyor. Tarayıcılar, eskiden polyfill gerektiren API’leri ekliyor; helper kütüphaneleri, yardımcı fonksiyonlar derken rafta ne varsa. Hâlâ zaman dilimi hesabı için `moment-timezone` ya da `_.debounce()` için `lodash` gönderiyorsanız, platformun zaten sunduğu bir şey için ödüyorsunuz: hem byte olarak hem karmaşıklık olarak.

Size pratik üç örnek göstereyim. Baseline’ın nasıl gereksiz yükü kestirebileceğini göreceksiniz.

Senaryo 1: 50KB’lık Bağımlılık Olmadan Tarih Biçimlendirme

Bir projede, sadece dashboard’daki birkaç tarihi biçimlendirmek için `date-fns` import etmiştik. Tüm uygulama statik bir dashboard’dı. “Aug 9, 2026” gibi metinler üretmek için 16KB’lık yerelleştirilmiş tarih fonksiyonları gönderiyorduk.

İşte küçük bir deney: şu an tarayıcı konsolunuzu açın ve şunu yazın:

```js
new Intl.DateTimeFormat('en-US', { dateStyle: 'full' }).format(new Date())
```

Bu kadar. **Import yok, npm install yok, versiyon sabitleme yok.** `Intl` nesnesi yıllardır Baseline bir özellik. Yerel ayara özel biçimlendirmeyi, saat dilimlerini, hatta `Intl.RelativeTimeFormat` ile date-fns tarzı göreceli zamanı bile hallediyor.

Tüm bundle’dan kurtulmak mı istiyorsunuz? date-fns fonksiyonlarını native karşılıklarıyla eşleştirin:

- `format` → `Intl.DateTimeFormat`
- `formatDistance` → `Intl.RelativeTimeFormat`
- `parseISO` → `Date.parse()` (veya dikkatli bir şekilde `new Date()`)
- `zonedTimeToUtc` → `timeZone` seçeneğiyle `Intl`

Evet, uç durumlar var; ama projelerin %90’ı için native `Intl` API’si işi görüyor. Üstelik Baseline available olduğu için her modern tarayıcı hallediyor.

Senaryo 2: Lodash'i DOM ile Değiştirmek

Bazı kod tabanlarında hâlâ `lodash.debounce` görüyorum. Bir fonksiyonu çalışmadan önce biraz bekletmek için 5 kilobayt. Oysa tarayıcıda bu yerleşik:

```js
function debounce(fn, delay) {
let timer;
return (...args) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), delay);
};
}
```

Ya da benim gibi biraz üşengeçseniz, çoğu durumda event listener içinde basit bir `setTimeout` yeterli olur. `_.throttle` için de, `_.clamp` için de, `_.range` için de geçerli: hepsi birkaç satır saf JavaScript.

Ama iş daha da derin. Hiç `_.forEach` kullandınız mı? Array prototype’ında `forEach`, `map`, `filter`, `reduce` var; hepsi Baseline. `_.get` ile iç içe geçmiş özelliklere güvenli erişim mi? 2020’den beri Optional Chaining Baseline bir özellik. `_.unique`? O sadece `Set`.

DOM’un kendisi de bir hazine: `classList.toggle()`, `_.toggleClass` yerine geçiyor; `Element.matches()`, `_.is()` selector mantığını karşılıyor; native `IntersectionObserver` ise koca scroll-spy kütüphanelerinin yerini alıyor. Bir dahaki sefere bağımlılık eklemek üzereyken kendinize sorun: “Bu, `document.querySelectorAll`’ın bana zaten verdiklerinin süslü bir sarmalayıcısı mı?”

Senaryo 3: axios Olmadan HTTP İstekleri

Axios güzel bir kütüphane; ama 2026’da native `fetch` API’si Baseline ve neredeyse her kullanım durumunu karşılıyor. Streaming mi? `fetch`, `response.body.getReader()` ile streaming destekliyor. Kimlik doğrulama mı? Küçük bir sarmalayıcıyla header’lar, credentials ve interceptor’lar ayarlayabilirsiniz. İptal etme mi? O da `AbortController`, ayrıca Baseline.

Küçük bir proje için axios’u tamamen 20 satırlık bir helper ile değiştirdim:

```js
async function request(url, options = {}) {
const res = await fetch(url, {
headers: { 'Content-Type': 'application/json', ...options.headers },
signal: options.signal ?? (options.timeout && AbortSignal.timeout(options.timeout)),
...options,
});
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}
```

npm yok, node_modules şişkinliği yok, circular dependency uyarıları yok. Sadece hızlı, native ve güvenilir.

Bağımlılıklarınızı Baseline ile Nasıl Denetlersiniz?

Tamam, ikna oldunuz. Peki şimdi ne olacak? İşte bu öğleden sonra uygulayabileceğiniz pratik bir süreç.

1. Runtime Bağımlılıklarınızı Listeleyin

`npm ls --production` çalıştırın veya `package.json`’a bakın. Framework’ünüz ve state management kütüphaneniz dışında kalan her şeyi işaretleyin. O küçük yardımcı kütüphaneler ilk hedeflerdir.

2. Her Birini Baseline ile Karşılaştırın

Listenizdeki her kütüphane için iki soru sorun:

- Bu ne sorunu çözüyor?
- Bunu, Baseline available bir web API’siyle çözebilir miyim?

MDN’de özelliği arayın. Yeşil “Baseline available” rozetini görürseniz, tamamdır. “Newly available” yazıyorsa ve sadece modern tarayıcıları hedefliyorsanız, yine de değerlendirmek gerekir. Kırmızı “Limited” görüyorsanız, kütüphaneyi şimdilik tutun.

Hızlı bir ipucu: Chrome, Safari veya Firefox’ta geliştirici araçlarını açın ve API’yi doğrudan test edin. Bir flag olmadan çalışıyorsa, orası iyiye işarettir.

3. Kodunuzda İzleri Arayın

`import * as _ from 'lodash'`, `from 'date-fns'`, `from 'axios'` veya `from 'jquery'` gibi kalıpları arayın. Sonra bu fonksiyonların gerçekten ne sıklıkla kullanıldığına bakın. Bazen 200 metotluk bir kütüphaneden sadece üç metot kullandığınızı fark ediyorsunuz. Bu net bir fırsattır.

4. Değiştirin ve Karşılaştırın

Migrasyonu her seferinde bir kütüphane yapın. Ayrı bir PR açın ki bundle boyutu değişimini ölçebilin. Build aracınızın boyut raporunu kullanın ya da devtools’ta dosya boyutuna bakın. Öncesinde ve sonrasında Lighthouse çalıştırmanızı öneririm. “JavaScript execution time” değerinin düştüğünü görmek harika bir duygu.

Daha Az JavaScript Göndermenin İnsani Tarafı

Küçük bundle’ın verdiği kendini beğenmiş mutluluğun dışında neden umursuyoruz? Çünkü JavaScript, tarayıcılara gönderdiğimiz en pahalı kaynak. Her byte indirilmeli, parse edilmeli, derlenmeli ve çalıştırılmalı. Kurtardığınız her API, kötü bir 3G bağlantısıyla ucuz bir Android telefonda birinin sayfayı daha hızlı açması demek. Herkesin elinde fiber bağlantılı bir MacBook Pro yok.

Daha az JavaScript göndermek aynı zamanda sizin için daha az zihinsel yük demek. Her bağımlılık potansiyel bir güvenlik açığı, potansiyel bir migrasyon baş ağrısı ve maintainer’ı emekliye ayrıldığında potansiyel bir sürpriz kaynağıdır. Native API’ler tarayıcı satıcıları tarafından korunur; bu da yıllarca güncellenecek, belgelenecek ve destekleneceği anlamına gelir.

Daha derin bir faydası da var: web platformunu gerçekten anlamaya başlarsınız. `Intl`, `URL`, `Promise`, `Map`, Optional Chaining ve `fetch` kullandıkça daha iyi bir web geliştiricisi olursunuz. Sadece soyutlamaları tüketen biri değil, ahşabın dokusunu bilen bir marangoz olursunuz.

Sınırlamalar Var mı? Evet. Aşırıya Kaçmayın.

Baseline sihirli bir değnek değil. Bazı gelişmiş API’ler hâlâ her yerde Baseline available olacak kadar yeni değil. Örneğin Popover API veya View Transitions API “newly available” ama henüz tüm tarayıcılarda tam olarak yerleşmedi. Geniş bir kitleye hitap eden halka açık bir site yapıyorsanız, beklemek ya da zarif bir fallback sağlamak isteyebilirsiniz.

Ayrıca bir kütüphaneyi atmak her zaman daha az kod yazmak anlamına gelmez. Bazen aynı davranışı elde etmek için biraz daha fazla vanilla JS yazmanız gerekir. Ama kendi yazdığınız birkaç satır, tam olarak anlamadığınız dev bir yardımcı kütüphaneden daha bakımı kolaydır.

Ve son olarak, “native API fanatiği” olmayın. Bir kütüphane üretkenliğinizi tamamen değiştiriyor ve hayatınızı kolaylaştırıyorsa kullanın. Baseline’ın amacı sizi süslü kütüphaneler kullandığınız için utandırmak değil. Amacı bilinçli tercihler yapmanıza yardımcı olmak. Yeter ki 2015’ten beri Baseline olan `crypto.getRandomValues()` varken `safe-password-generator` göndermeyin.

Bonus: Baseline'dan Nasıl Haberdar Kalırım?

Web platformu hızla gelişiyor. Neyin Baseline available olduğunu takip etmek için iki şey yapıyorum:

1. Ayda bir [web.dev/baseline](https://web.dev/baseline) adresindeki **Web Platform Features** panosuna bakıyorum.
2. MDN’deki **Baseline News** bölümünü okuyorum; her ay yeni available olan özellikleri listeliyor.

Bir de WebDX topluluk grubunun GitHub deposunu takip edebilirsiniz: [github.com/web-platform-dx/baseline](https://github.com/web-platform-dx/baseline). Sihir orada oluyor.

Sıkça Sorulan Sorular

"Baseline available" tam olarak ne demek?

Bir özelliğin tüm büyük tarayıcıların—Chrome, Edge, Firefox, Safari ve Opera—güncel ve yakın sürümlerinde desteklendiği anlamına gelir. Bu tarayıcılar için polyfill ya da fallback olmadan kullanabilirsiniz.

Baseline, "caniuse.com" ile aynı şey mi?

Hayır, ama ilişkililer. Caniuse, eski sürümler de dahil olmak üzere ayrıntılı uyumluluk tabloları verir. Baseline ise bu veriyi basit bir “hazır ya da değil” etiketine indirger. Aynı zamanda bilginin bağlama duyarlı olmasını sağlar—bir şey Chrome 120’de çalışıyor olabilir ama Safari 12’de çalışmaz.

Ya hâlâ IE11 gibi eski bir tarayıcıyı desteklemem gerekiyorsa?

IE11 öldü; ondan önce de zaten bir istisnaydı. Baseline, IE11 gibi eski tarayıcıları açıkça kapsam dışı bırakır. Bu tür kadim ortamları desteklemek zorundaysanız, tek tek tabloları kontrol etmeniz ve seçtiğiniz API’ler için polyfill eklemeniz gerekebilir. Ama 2026’da kendinize sormalısınız: neden hâlâ IE11 destekliyorsunuz? Eski teknolojide ısrar eden kullanıcılarınız aslında, sizin de bu bedeli ödemenize sebep oluyor.

Takımımı Baseline kullanmaya nasıl ikna ederim?

Onlara rakamları gösterin. Bir bağımlılık seçin; bundle boyutu ve bakım maliyetini tahmin edin; sonra native karşılığını kısa bir prototipte gösterin. Ben önceki işimde `lodash` için bunu yaptım. Lead’im iki satır vanilla JS karşılığında 5KB’lık bir yardımcıyı silen diff’i görünce ikna oldu. Ya da bu yazıyı gösterin. 😉

Sonuç

Baseline sadece bir uyumluluk aracı değil; aynı zamanda bir zihniyet değişimi. “Bunun için hangi kütüphaneyi kullanmalıyım?” demek yerine “Tarayıcı bunu benim için zaten yapabilir mi?” demeye başlıyorsunuz. Bu değişimi yaptığınız anda JavaScript şişkinliği erimeye başlıyor.

Kullanıcılarınız daha hızlı bir site kazanıyor. Gelecekteki siz daha temiz bir kod tabanı kazanıyor. Ve web, herkes için bir nebze daha hafifliyor.

Şimdi gidin, devtools’unuzu açın, projenizin bundle’ına bakın ve neleri kesebileceğinizi görün. Tarayıcınız muhtemelen cevabı çoktan bekliyor.