# JavaScript ve TypeScript geliştiricisi — web'i ve mobili aynı API'den besliyorum

> Web ve mobili aynı API'den beslemek: React Native ile mağazaya çıkan uygulamalar, TypeScript'le taşınan sözleşme ve değişen araç zinciri.

- Teknolojiler: TypeScript, React, React Native, Expo, Vite, Tailwind CSS, Node.js
- Deneyim: 2008'den bu yana
- Yazı: 39
- Proje: 6
- Güncelleme: 2026-09-02
- Kaynak: https://www.muhammetsafak.com.tr/uzmanlik/javascript/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
## JavaScript & TypeScript ekosisteminde ben

Bu ekosistemdeki kimliğim tek cümleyle şu: ürünün arka ucunu yazan ve o ürünün
web ile mobil yüzeyini aynı sözleşmeye oturtan kişi. Tasarım sistemi kurmuyorum;
API ile konuşan arayüzü kuruyorum. JavaScript ve TypeScript bu sayfada bir
tercih değil, ürünün kullanıcıya değdiği katmanın dili.

Arayüz mimarisinin sistem tarafına değen kısımlarını — sunucu tarafında render
kararları, önbellek stratejisi — [sade.dev](https://sade.dev) tarafında
yazıyorum.

### Bu ekosistemde ne teslim ediyorum

Ortak noktaları hepsinin aynı sözleşmeye bağlanması; tasarım sistemi kurmuyorum, API ile konuşan arayüzü kuruyorum.

- **Üç katman, tek sözleşme** — Aynı özellik REST API, web arayüzü ve mobil uygulama olarak birden çıkıyor. Ayrımı katı tutuyorum: web ile mobil birbiriyle hiç konuşmuyor, yalnızca ortak API üzerinden haberleşiyor.
- **Mobil istemci** — React Native ve Expo ile aynı ürünün iOS ve Android karşılığı. Mağazaya gönderme süreci de bu işin parçası.
- **Tip katmanı** — TypeScript API'den arayüze tek sözleşme taşıyor. Sözleşmeyi iki uçta ayrı ayrı yazmak, sözleşmenin olmaması demek.
- **Derleme ve stil hattı** — Geliştirme sunucusunu saniyelere indiren derleme hattı ve utility-first stil katmanı. Araç zinciri değişiyor, bu iki katmanın işi aynı kalıyor.

### Zor kısım kod değil, sözleşme

Arayüz tarafında karşılaştığım hataların çoğu arayüz hatası gibi görünüp sözleşme hatası çıkıyor. Bir alanın adı, bir tarihin biçimi ya da bir hata kodunun anlamı katmanlar arasında ayrıştığında sonuç, hepsi ayrı görünen ama aynı kökten gelen bir hata kümesi oluyor. Bu yüzden işe arayüzün nasıl görüneceğinden değil, arka ucun ne söz verdiğinden başlıyorum.

### Tek bir kütüphaneye bağlı değilim

Üçü de aynı sorunun farklı cevabı; hangisinin açılacağına ürünün ihtiyacı karar veriyor.

- **Vue tarafı** — Uzun süre burada çalıştım: bileşen tabanlı arayüz mimarisi, yönlendirme ve durum yönetimi. Kaybolmuş bir yatırım değil — iki yaklaşımı karşılaştırabildiğim yer orası.
- **React tarafı** — Ağırlık merkezinin buraya kayması mobil ihtiyaçla oldu; aynı zihinsel modelin web ve mobilde birlikte durması işleri kolaylaştırdı.
- **Sunucu tarafı framework'ten çıkan arayüz** — Modern bir arayüzü sunucu tarafı framework'ün içinden çıkaran ve tarayıcıya inen kodu azaltan yaklaşımlar.

### Bir aracı neye göre değiştiriyorum

Bu ekosistemde en uzun süredir izlediğim şey araçların değişmesi — jQuery ile AJAX'tan Gulp'a, Webpack'e, Vite'a. Karar her seferinde aynı sıradan geçti.

1. **Ödenen bedel her zaman yapılandırma** — Her geçişte ödediğim şey aynıydı: yapılandırma. Aracın kendisi değil, onu çalışır hâle getiren ayar yükü pahalı olan.
2. **Geri dönüş bedelden büyük olmalı** — Yeni bir aracı, ödediğim yapılandırma bedelinden fazlasını geri veriyorsa alıyorum. Vermiyorsa eski araç yerinde kalıyor.
3. **"Daha modern" bir gerekçe değil** — Aracın yaşı bir ölçü değil. Ölçü, o aracın bu üründe hangi somut işi ucuzlattığı.
4. **Build süresi de bir kalem** — Aynı ölçüyü derleyici tarafında da uyguluyorum: build süresi bir maliyet kalemi, bir ayrıntı değil.

### Mobil tarafta kendi kurallarını dayatanlar

Web'deki React deneyiminin transfer olacağı beklentim kısmen doğru çıktı: bileşen düşüncesi aynı, geri kalanı değil.

- **Gezinme mimarisi** — Ekran mimarisiyle birlikte kurulan gezinme; web'deki router alışkanlığı buraya olduğu gibi taşınmıyor.
- **Liste render performansı** — Uzun listelerde render performansı, mobil tarafta ayrı ayrı üzerinde çalıştığım başlıklardan biri.
- **OTA ile sürüm yönetimi** — Güncellemenin mağaza turuna girmeden dağıtılabilmesi, sürüm yönetimini kendi başına bir konu hâline getiriyor.
- **Mağaza teslimi** — Gönderim sürecinin kendisi de bu işin parçası — ve uygulamanın kodundan bağımsız bir zanaat.

### Neyi yapmıyorum

Erişilebilirlik denetimi, tasarım sistemi kurma ve ileri düzey animasyon işleri benim uzmanlık alanım değil; bunu söylemem gerektiğinde söylüyorum. Arayüz mimarisinin sistem tarafına değen kısımlarını — SSR kararları, önbellek stratejisi — yazdığım yer ise sade.dev.

## Sık sorulanlar

### JavaScript'i kaç yıldır yazıyorsun?

2008'den bu yana, 18 yıldır — PHP ile aynı yıl. İkisi aynı işin iki yüzüydü: sunucuda PHP, tarayıcıda önce jQuery, sonra Vue ve React.

### Frontend geliştirici misin?

Tam olarak değil. Ben ürünün arka ucunu yazan ve o ürünün web ile mobil yüzeyini de aynı sözleşmeye oturtan taraftayım. Tasarım sistemini sıfırdan kuran kişi değilim; API'yle konuşan arayüzü kuran kişiyim.

### Vue mu React mi?

İkisini de yazdım. Vue tarafında bileşen mimarisi, router ve durum yönetimi (Vuex, sonra Pinia) üzerine; React tarafında hooks, concurrent render ve React 19 ile gelen form actions üzerine yazdım. Bugün mobil işler React Native'i zorunlu kıldığı için ağırlık React tarafında.

### Mobil uygulama da yapıyor musun?

Evet, React Native ve Expo ile. Kayıtlı projelerden ikisinin mobil istemcisi böyle yazıldı; biri App Store ve Google Play'de yayında. OTA güncelleme, gezinme mimarisi ve liste render performansı üzerine ayrı yazılarım var.

### TypeScript kullanıyor musun?

Evet, ve gerekçesi tek bir yerde toplanıyor: API'den arayüze uçtan uca tip güvenliği. Sözleşmeyi iki uçta ayrı ayrı yazmak, sözleşmenin olmaması demek.

### Bu alanda kaç yazın var?

Bu sitede JavaScript ekosistemi etiketli 39 yazı ve 6 proje kayıtlı; en eskisi jQuery ile AJAX, en yenisi TypeScript'in yeni derleyicisi.

### Araç zinciri sürekli değişmiyor mu?

Değişiyor ve ben de o zinciri Gulp'tan Webpack'e, Webpack'ten Vite'a taşıdım. Ama her geçişte ödediğim şey aynıydı: yapılandırma. Bir aracın yerine yenisini koymak, ancak ödediğiniz yapılandırma bedelinden fazlasını geri veriyorsa doğru karar.
