Bakın şimdi, JavaScript dünyasında hâlâ yıllardır aynı alışkanlıklarla kod yazan çok kişi var. Hani “çalışıyorsa dokunma” yaklaşımı vardır ya… bazı yerlerde tamam, idare eder. Ama bazı ufak gibi görünen API seçimleri var ki, hem güvenliği hem de okunabilirliği bayağı etkiliyor. Bu yazıda o eski refleksleri biraz kenara bırakıp modern yerleşik API’lere bakacağız (evet, doğru duydunuz)
Ben bu konuyu ilk kez geçen ay, 2026 Şubat başında İstanbul’daki bir editör toplantısında yeniden fark ettim. Bir ekip arkadaşım hasOwnProperty ile uğraşırken null-prototype bir nesnede patladı; küçük bir detay yüzünden yarım saat gitti (evet, doğru duydunuz). Aynı hafta kendi test ortamımda da benzerini yaşadım. Sorun aslında basit: eski yöntemler bazen sessizce güven veriyor, ama arkadan çelme takıyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
Neden Eski Alışkanlıklar Can Sıkıyor?
İşin aslı şu ki, eski yöntemlerin çoğu kötü oldukları için değil; kırılgan oldukları için problem çıkarıyor. Mesela hasOwnProperty… kulağa masum geliyor. Ama obje üzerinde ezilmiş olabilir — daha da kötüsü, Object.create(null) ile oluşturulmuş nesnelerde,. Prototipsiz yapılarda, hiç çalışmaz. Siz ne dersiniz? Kağıt üstünde tamam görünen şey, pratikte hop diye düşüyor.
Bunu kurumsal bir projede çok net gördüm. 2024 sonbaharında Ankara’da çalışan bir ekipte JSON tabanlı konfigürasyon katmanını incelerken, inherited property yüzünden yanlış alanlar filtreleniyordu; kimse bunu ilk bakışta fark etmedi çünkü hata vermiyordu, sadece yanlış veri geçiyordu (şaşırtıcı ama gerçek). Sessiz hata. Tam da bu işte.
Doğrusu, Gel gelelim mesele sadece güvenlik değil. Okunabilirlik de var. Yeni gelen geliştiriciye “burada niye spread artı sort yaptık?” diye açıklama yapmak yerine doğrudan toSorted() demek çok daha net duruyor. Kod biraz İngilizce cümle gibi aktığında insanın kafası da rahat ediyor. Bu kadar basit.
Object.hasOwn(): Küçük Ama Temiz Bir Kurtarıcı
Object.hasOwn() bence bu listenin en az konuşulan ama en işe yarar parçalarından biri. Eski usul obj.hasOwnProperty("key") artık fazlasıyla riskli hissettiriyor; özellikle dış kaynaktan gelen objelerde veya prototipsiz yapılarda. Açık konuşayım — bu değişiklik bana ilk çıktığında “tamam güzelmiş ama ne kadar lazım olur ki?” dedirtmişti. Yanılmışım.
Bak şimdi, Sonra kendi küçük Node.js projemde denedim. Config okurken null-prototype nesneler kullanıyordum ve eski yöntem anında duvara tosladı; Object.hasOwn(config, "theme") ise tertemiz çalıştı. Böyle olunca insanın fikri değişiyor. Evet, aynen öyle.
Kullanım mantığı
const config = Object.create(null);
config.theme = "dark";
console.log(Object.hasOwn(config, "theme")); // true
console.log(Object.hasOwn(config, "version")); // falseBuradaki güzellik şu: yöntemi objenin üstünden çağırmıyorsunuz, doğrudan Object üzerinden çağırıyorsunuz. Yani obje kendini “ben zaten bunu destekliyorum” diye pazarlayamıyor. Küçük ama önemli bir fark.
| Yöntem | Sorun | Daha iyi alternatif |
|---|---|---|
obj.hasOwnProperty() |
Ezilirse bozulur | Object.hasOwn(obj, key) |
"key" in obj |
Miras alınmış alanları da sayar | Object.hasOwn() |
obj.propertyIsEnumerable() |
Daha dolambaçlıdır | Kullanım amacına göre ayrı düşünülmeli |
Dizileri Mutasyonsuz Yönetmek Daha Rahat: toSorted(), toReversed(), with()
Burası benim favori kısım olabilir. Çünkü React tarafında çalışan herkes bunun değerini hemen hissederdi sanırım. Diziyi sıralamak için önce kopya alıp sonra sort yapmak uzun süredir standart gibiydi — “spread yapayım ki orijinal bozulmasın.” E hani neden? Artık buna gerek kalmadan işi çözen yerleşik metotlar var. Bu konuyla ilgili Sahneye Çıkan Sessiz Geliştirici: Thabang’ın İlk Notu yazımıza da göz atmanızı tavsiye ederim.
Bir dakika — bununla bitmedi. Bu konuyla ilgili WhatsApp’ta Kendi Yerel Yapay Zekânı Kurmak: Node.js ve Ollama yazımıza da göz atmanızı tavsiye ederim.
Garip gelecek ama, toSorted() diziyi değiştirmeden sıralıyor. Aynı mantıkla toReversed() ters çeviriyor, with() tek bir index’i güncelliyor ve üstelik hepsi mutasyonu aradan neredeyse tamamen çıkarıyor. Bu özellikle state yönetiminde büyük rahatlık sağlıyor; yanlışlıkla mevcut diziyi bozup UI’ı garip bir hale getirme ihtimali azalıyor çünkü.
Küçük startup vs kurumsal ekip
Küçük bir startup’ta bu tip metotların faydası hızdan geliyor. Takımda iki kişi varsa bile kodu okuyan herkes ne olduğunu hemen anlıyor. Kurumsal tarafta ise asıl kazanç bakım kolaylığı ve hata azaltma tarafında çıkıyor — farklı ekiplerden gelen insanlar aynı kalıbı görünce ekstra açıklama istemiyor, doğrudan ilerliyor.
Bana sorarsanız burada hafif bir hayal kırıklığı da yok değil: her tarayıcı sürümü hâlâ aynı seviyede destek vermiyor olabilir. Polyfill konusu bazen can sıkabiliyor. Ama iş modern uygulamalara geldiğinde tablo fena sayılmaz.
Kod örneğiyle bakalım
const players = [
{ name: "Arjun", score: 450 },
{ name: "Priya", score: 820 },
{ name: "Rahul", score: 610 }
];
const leaderboard = players.toSorted((a, b) => b.score — a.score);
console.log(leaderboard[0].name); // Priya
console.log(players[0].name); // Arjun
const original = [1, 2, 3, 4];
const reversed = original.toReversed();
console.log(reversed); // [4,3,2,1]
console.log(original); // [1,2,3,4]Nerede Gerçekten İşe Yarıyor?
E-ticaret tarafını düşünün mesela (yanlış duymadınız). Ürün listesi sıralanacak ama orijinal listeyi de filtreleme adımlarında korumanız gerekiyor. Eskiden bunun için sürekli ara kopya üretirdiniz (ki bu çoğu kişinin gözünden kaçıyor). Şimdi tek satırla hallediyorsunuz. Bu kadar. Daha fazla bilgi için CSS Animasyonlarında Doğrulama: 2026 İçin Teknik Rehber yazımıza bakabilirsiniz.
with() ise özellikle form düzenleme ekranlarında bayağı tatlı çalışıyor. Kullanıcı üçüncü alanı değiştirdiğinde pek çok diziyi map’leyip dolaşmak yerine direkt o elemanı yenileyebiliyorsunuz. Ufak görünür ama performans kadar zihinsel yükü de azaltır. Siz hiç denediniz mi? Cidden.
Object.hasOwn(): Güvenli özellik kontrolü sağlar.toSorted(): Orijinali bozmadan sıralama yapar.toReversed(): Kopyayı ters çevirir.with(): Belirli index’i mutasyonsuz günceller.
Peki Her Şey Güllük Gülistanlık mı?
Kendi deneyimimden konuşuyorum, Açık konuşayım, hayır. Bu yeni API’lerin güzel tarafı çok net ama ekosistem desteği her zaman pürüzsüz olmayabiliyor. Eski proje bakıyorsanız veya gömülü sistemlerde çalışıyorsanız tarayıcı ve Node sürümünü kontrol etmek şart. Ben bunu Mart ayında İzmir’de küçük bir müşteri projesinde yaşadım; lokal makinede çalışan kod production’da farklı davranınca sebebi tam olarak sürüm uyumsuzluğuydu. Saatlerce baktık.
Modern API kullanmak moda olsun diye yapılacak iş değil; hata riskini azaltıyorsa anlamlıdır, yoksa sırf yeni diye her şeyi değiştirmek gerekmiyor.
Neyse uzatmayayım. Doğru yaklaşım şu bence: yeni projelerde modern API’leri varsayılan kabul edin, eski projelerde ise kilit noktaları tek tek taşıyın. Hepsini aynı anda söküp atmaya çalışmak genelde gereksiz stres yaratıyor. Tecrübeyle sabittir. Artemis II’nin Dönüşü: Ay Çevresinden Eve Gelen Yolculuk yazımızda da bu konuya değinmiştik. 128 GB DDR5 RAM Neden Uçtu: Raflarda Kalan Fatura yazımızda da bu konuya değinmiştik.
Editör Masasından Kısa Notlar
Editör masasında bu konuyu ilk derinlemesine incelediğimde aklıma hemen iki şey geldi: biri güvenlik, öbürü bakım maliyeti. Teknik içerikte çoğu zaman insanlar “bu ne kadar havalı” kısmına odaklanıyor. Ama ben sahada şunu öğrendim — havalı olan şey bazen ertesi gün sizi yorar. Maalesef.
Aynı konuda Haziran 2025’te Kadıköy’de görüştüğüm bir frontend geliştiricisi bana şunu söylemişti: “Dizi mutate eden helper’lardan kurtulduktan sonra bug sayımız gözle görülür düştü.” Rakam vermedi tabii, ama kod incelemelerinde çıkan tartışmalar azaldıysa orada gerçek kazanç vardır. Bence yeterince açık.
sort() sonrası state kopyalama görüyorsanız, önce birkaç kritik akışı modern API’ye taşıyın; hepsini topluca çevirmek zorunda değilsiniz.
Sıkça Sorulan Sorular
`Object.hasOwn()` neden `hasOwnProperty` yerine tercih ediliyor?
Aslında, `Object.hasOwn()`, objenin kendi özelliğini güvenli şekilde kontrol eder ve prototip zincirinden ya da override edilmiş metodlardan etkilenmez. En çok da dış kaynaklı veriyle çalışırken daha sağlamdır. Null-prototype nesnelerde de sorunsuz çalışır.
`toSorted()` ile normal `sort()` arasında ne fark var?
`sort()` diziyi yerinde değiştirir yani mutasyon yapar. `toSorted()` ise yeni bir dizi döndürür ve orijinali olduğu gibi bırakır. State yönetimi olan uygulamalarda bu fark bayağı önemlidir.
`with()` hangi durumlarda kullanılır?
Dizide yalnızca tek bir elemanı değiştirmek istediğinizde kullanılır. Örneğin form alanları ya da liste içindeki belirli kayıtlar için temiz ve kısa bir çözüm verir. Mutasyon yapmadığı için yan etkileri azaltır.
Bu modern API’ler her projede kullanılmalı mı?
Tam otomatik olarak evet demek doğru olmaz. Proje hedefi,tarayıcı desteği,Node sürümü ve polyfill ihtiyacı birlikte değerlendirmek lazım. Yeni projelerde oldukça mantıklı durur;eski projelerde ise parça parça geçiş daha sağlıklı olur.
Kaynaksız Konuşmayalım:
Kaynaklar ve İleri Okuma）
？
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
